This isn’t happening in my code. My code isn’t even installed on this
machine, and I am no longer a Microsoft developer, and was never a VMware
developer. The assertion failure is occurring in Microsoft code, although
the call stack leads me to believe that the VMware driver may be the root
cause of the assertion.
I am posting to ask if 1) anyone has encountered (and solved?) this, and if
2) any Microsoft or VMware people want to look into this. Once this problem
occurs, the the assertion failure occurs many times (if ignored and the
machine is allowed to run), which makes the machine unusable until it is
rebooted. I consider this unacceptable behavior, and I would like the
aggregate system of Microsoft+VMware to solve it.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, January 19, 2006 1:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Assertion failure in systime.c, VMware?
VMWare and MS VPC develop very much other patterns of race conditions
then the physical machine.
So, if the bug is a race, testing with VMWare is maybe the very helpful
thing.
I would even suggest to test all newly-released software-only (not
hardware
drivers) stuff on these VMs. In the last 24 hours, I have caught the race
reproducible on VMWare only, and not on the hardware (surely it will
manifest on the hardware too, but with, say, 1% probability after a lengthly
operation, so, virtual machine was a great help there).
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Arlie Davis”
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 19, 2006 8:55 PM
Subject: [ntdev] Assertion failure in systime.c, VMware?
> Is anyone from VMware on this list? I’m encountering this assertion on a
> machine that has VMware Workstation 5.5 installed. I’m seeing this on a
> checked XP professional build after the machine woke up from standby.
>
>
> Assertion failed: ExpKernelResolutionCount != 0
> Source File: d:\xpsprtm\base\ntos\ex\systime.c, line 1827
>
> The call stack is:
>
> ChildEBP RetAddr Args to Child
> f6c28a30 80ac64b6 0002625a 80102424 00000000 nt!DbgBreakPoint
> f6c28d20 80ac64f8 80c52188 80c52164 00000723 nt!RtlAssert2+0x104
> f6c28d3c 80c5221a 80c52188 80c52164 00000723 nt!RtlAssert+0x18
> f6c28d60 b8ea9453 00000000 00000000 00000000 nt!ExSetTimerResolution+0x6e
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> f6c28d7c b8eae425 00000000 00000004 85c10020 vmx86+0x3453
> f6c28d90 b8ea7493 00000000 00000000 00000000 vmx86+0x8425
> f6c28dac 80bdb538 00000000 00000000 00000000 vmx86+0x1493
> f6c28ddc 80ae5402 b8ea7468 00000000 00000000
nt!PspSystemThreadStartup+0x34
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> where vmx86.sys is “VMware Kernel Drive”, version 5.5.0.19175.
>
> – arlie
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stonestreetone.com
To unsubscribe send a blank email to xxxxx@lists.osr.com