Verifier shutdown watchdog
If Windows 7 is taking a long time to shutdown, and you are running with driver verifier turned on, you may come across the following message in kernel debugger to your rescue – Driver Verifier detected that this system didn’t finish shutting down in more than 20 minutes. To display information about the thread that [...]
x64 calling convention
Many of you are probably already familiar with the x64 calling convention1 2 in 64-bit Windows – where generally speaking first four parameters3 are passed in registers RCX, RDX, R8 and R9 with 32 bytes of spill area reserved
Kernel Debugging on ESXi 4.0
I got a new Dell T5500 desktop machine a while back and the first thing to do was to open it up and see what was in there of course. And looking at the dual quad-core Xeons and the 6GB memory, I quickly realized I had to find something daunting enough for this machine. It [...]
A tale of two asserts
There are two popular ways to assert in drivers. One can use the the regular ASSERT macro (int 3) or the relatively newer NT_ASSERT macro (int 2C). Since ASSERT calls RtlAssert, when the debugger breaks in, code would be several frames off of where the ASSERT was. If you use NT_ASSERT however, the debugger would [...]
Improving driver diagnostics
TRoy, a good friend and ex-colleague of mine, presented at Microsoft Global Escalation Conference 2009 about how programmers can help improve driver diagnostics and “support support” when hard to reproduce problems are reported and all you have is a memory dump. He shows several techniques complete with short examples of each and how each technique [...]
Verifier bugcheck (0xc4) subclass 0xf6
Windows 7 driver verifier can do a DRIVER_VERIFIER_DETECTED_VIOLATION (0xC4) bugcheck with parameter 1 (violation type) set to 0xf6. The top of stack may look something like the following nt!KeBugCheckEx+0x1e nt!VerifierBugCheckIfAppropriate+0×32 nt!VfCheckUserHandle+0x15f nt!ObReferenceObjectByHandleWithTag+0×136 nt!ObReferenceObjectByHandle+0×21 nt!ObpLookupObjectName+0x9a nt!ObOpenObjectByName+0×159 This new subclass of violation, comes as part of Security Checks1 settings which is new to Windows 7 Driver Verifier. [...]
Loading ...