Azure0
Contributor
Contributor

vmx86.sys causes Win7 BSOD

Jump to solution

I use VMware® Workstation 7.0.1 build-227600.

Once, when I start the application, windows died...

Not always been so, just at times.

This is the analysis that windbg made, if you need it, I can send you the dmp file.

Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 7600.16617.x86fre.win7_gdr.100618-1621

*******************************************************************************

  • *

  • Bugcheck Analysis *

  • *

*******************************************************************************

LOCKED_PAGES_TRACKER_CORRUPTION (d9)

Arguments:

Arg1: 00000001, The MDL is being inserted twice on the same process list.

Arg2: 87f1ffc8, Address of internal lock tracking structure.

Arg3: 87e5a2a8, Address of memory descriptor list.

Arg4: 000006c0, Number of pages locked for the current process.

Debugging Details:

-


      • WARNING: Unable to verify timestamp for vmx86.sys

      • ERROR: Module load completed but symbols could not be loaded for vmx86.sys

ADDITIONAL_DEBUG_TEXT:

Use '!findthebuild' command to search for the target build information.

If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

MODULE_NAME: vmx86

FAULTING_MODULE: 83e43000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4b5a8dee

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xD9

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 83ebbe23 to 83f1fd10

STACK_TEXT:

WARNING: Stack unwind information not available. Following frames may be wrong.

a75a48dc 83ebbe23 000000d9 00000001 87f1ffc8 nt+0xdcd10

a75a4910 83ebbce6 87f1ffc8 9aa18936 00000040 nt+0x78e23

a75a49d0 9aa14912 87e5a2a8 00000001 00000002 nt+0x78ce6

a75a4a18 9aa18936 00040000 89826b00 00000000 vmx86+0x3912

a75a4a40 9aa18cec 86cc5778 89826b00 00000000 vmx86+0x7936

a75a4a7c 9aa118d4 86cc5778 88424e98 3dfbfe30 vmx86+0x7cec

a75a4ac4 9aa123d1 87c9dde0 86cc5778 00000168 vmx86+0x8d4

a75a4aec 841726c3 87dbd228 b5134f68 880b4f80 vmx86+0x13d1

a75a4b10 83e7f473 00000000 b5134f68 87dbd228 nt+0x32f6c3

a75a4b24 84080f6e 880b4f80 b5134f68 b5134fd8 nt+0x3c473

a75a4b44 8409dd5f 87dbd228 880b4f80 00000000 nt+0x23df6e

a75a4be0 840a053a 87dbd228 b5134f68 00000000 nt+0x25ad5f

a75a4c14 84a9e829 000002d0 00000000 00000000 nt+0x25d53a

a75a4d04 83e8644a 000002d0 00000000 00000000 Hookport+0x4829

a75a4d34 76fc64f4 badb0d00 0012ee10 00000000 nt+0x4344a

a75a4d38 badb0d00 0012ee10 00000000 00000000 0x76fc64f4

a75a4d3c 0012ee10 00000000 00000000 00000000 0xbadb0d00

a75a4d40 00000000 00000000 00000000 00000000 0x12ee10

STACK_COMMAND: kb

FOLLOWUP_IP:

vmx86+3912

9aa14912 ?? ???

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: vmx86+3912

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: vmx86.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

-


0 Kudos
1 Solution

Accepted Solutions
ksc
VMware Employee
VMware Employee

Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 7600.16617.x86fre.win7_gdr.100618-1621

*******************************************************************************

  • *

  • Bugcheck Analysis *

  • *

*******************************************************************************

LOCKED_PAGES_TRACKER_CORRUPTION (d9)

Arguments:

Arg1: 00000001, The MDL is being inserted twice on the same process list.

Arg2: 87f1ffc8, Address of internal lock tracking structure.

Arg3: 87e5a2a8, Address of memory descriptor list.

Arg4: 000006c0, Number of pages locked for the current process.

This verification step is only performed when Driver Verifier's checks are active. (Or on a checked build, but your dump says "Free" so that's not happening here). VMware's driver (vmx86.sys) is incompatible with these checks. You will need to either disable Driver Verifier or specifically exclude VMware's driver from Driver Verifier.

(More detail: the MDL verification check here requires a unique MDL for each page of memory we pin. MDLs are fine to use for this purpose for I/O when very little memory is actually pinned for I/O. But MDLs don't scale very well when pinning 70% of host memory, as Windows doesn't have enough kernel memory for enough MDLs to track that much memory. So we use a more efficient data structure than Windows' linked list - which is perfectly correct but which causes Driver Verifier to freak out. If we used MDLs, we could keep Driver Verifier happy but you could only pin ~10% of host memory, and 10% is too little to run a VM with any expectations of performance.)

View solution in original post

0 Kudos
3 Replies
continuum
Immortal
Immortal

7.0.1 is old - please try to reproduce it with 7.1.1




_________________________

VMX-parameters- WS FAQ -[ MOAcd|http://sanbarrow.com/moa241.html] - VMDK-Handbook

You also find me in the support crew of PHD Virtual Backup

Do you need support with a recovery problem ? - send a message via skype "sanbarrow"
0 Kudos
ksc
VMware Employee
VMware Employee

Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 7600.16617.x86fre.win7_gdr.100618-1621

*******************************************************************************

  • *

  • Bugcheck Analysis *

  • *

*******************************************************************************

LOCKED_PAGES_TRACKER_CORRUPTION (d9)

Arguments:

Arg1: 00000001, The MDL is being inserted twice on the same process list.

Arg2: 87f1ffc8, Address of internal lock tracking structure.

Arg3: 87e5a2a8, Address of memory descriptor list.

Arg4: 000006c0, Number of pages locked for the current process.

This verification step is only performed when Driver Verifier's checks are active. (Or on a checked build, but your dump says "Free" so that's not happening here). VMware's driver (vmx86.sys) is incompatible with these checks. You will need to either disable Driver Verifier or specifically exclude VMware's driver from Driver Verifier.

(More detail: the MDL verification check here requires a unique MDL for each page of memory we pin. MDLs are fine to use for this purpose for I/O when very little memory is actually pinned for I/O. But MDLs don't scale very well when pinning 70% of host memory, as Windows doesn't have enough kernel memory for enough MDLs to track that much memory. So we use a more efficient data structure than Windows' linked list - which is perfectly correct but which causes Driver Verifier to freak out. If we used MDLs, we could keep Driver Verifier happy but you could only pin ~10% of host memory, and 10% is too little to run a VM with any expectations of performance.)

View solution in original post

0 Kudos
Azure0
Contributor
Contributor

Thanks a lot.

Now I know why it crashed:)

0 Kudos