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
-
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.)
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
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.)
Thanks a lot.
Now I know why it crashed:)