Click the
!analyze -v to get started. It will display a description of the bugcheck code along with the 4 arguments. In this case, it was bugcheck 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION), and subcode (Arg1) is 0x62, which it describes as, "
A driver has forgotten to free its pool allocations prior to unloading." This is a very obvious bug, in that the driver was called to unload itself from memory - expected during a shutdown - and Windows told it to let go of all the memory it allocated. It did, save for 2 allocations (described in Arg4). Driver Verifier detected this and crashed the system as a result.
The name of the driver responsible is in Arg2. Just do
dc fffffa800a80afe0 (address saved in Arg2) to get the text:
Code:
7: kd> dc fffffa800a80afe0
fffffa80`0a80afe0 00420056 0078006f 00460053 0073002e V.B.o.x.S.F...s.
fffffa80`0a80aff0 00730079 ffff0000 00000000 00000000 y.s.............
fffffa80`0a80b000 ???????? ???????? ???????? ???????? ????????????????
fffffa80`0a80b010 ???????? ???????? ???????? ???????? ????????????????
fffffa80`0a80b020 ???????? ???????? ???????? ???????? ????????????????
fffffa80`0a80b030 ???????? ???????? ???????? ???????? ????????????????
fffffa80`0a80b040 ???????? ???????? ???????? ???????? ????????????????
fffffa80`0a80b050 ???????? ???????? ???????? ???????? ????????????????
Or, you know, you could just read the rest of the
analyze -v output to get the name, as well as being a DML hyperlink that you can click to get full details on the driver image:
Code:
Debugging Details:
------------------
TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2
OVERLAPPED_MODULE: Address regions for 'dfs' and 'cdrom.sys' overlap
BUGCHECK_STR: 0xc4_62
IMAGE_NAME: VBoxSF.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 50d050f2
MODULE_NAME: VBoxSF
FAULTING_MODULE: fffff88004400000 VBoxSF
VERIFIER_DRIVER_ENTRY: dt nt!_MI_VERIFIER_DRIVER_ENTRY fffffa800a80aa50
Symbol nt!_MI_VERIFIER_DRIVER_ENTRY not found.
DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP
PROCESS_NAME: System
CURRENT_IRQL: 2
LAST_CONTROL_TRANSFER: from fffff8000351d3dc to fffff80003096fc0
STACK_TEXT:
fffff880`009a9448 fffff800`0351d3dc : 00000000`000000c4 00000000`00000062 fffffa80`0a80afe0 fffffa80`0a80aa50 : nt!KeBugCheckEx
fffff880`009a9450 fffff800`0352c54a : 00000000`00000001 00000000`00000000 fffff880`04400000 00000000`00000001 : nt!VerifierBugCheckIfAppropriate+0x3c
fffff880`009a9490 fffff800`03180940 : 00000000`00000000 00000000`00000000 fffff880`020a4180 00000000`00000000 : nt!VfPoolCheckForLeaks+0x4a
fffff880`009a94d0 fffff800`0344635e : fffffa80`0a80af20 00000000`00000000 00000000`00000000 00000000`ffffffff : nt!VfTargetDriversRemove+0x160
fffff880`009a9570 fffff800`0346adb3 : 00000000`00000000 00000000`000e0082 00000000`00000000 00000000`00000001 : nt!VfDriverUnloadImage+0x2e
fffff880`009a95a0 fffff800`0346b22d : 00000000`00000000 fffffa80`0a80af20 00000000`00000000 fffff980`0531cf00 : nt!MiUnloadSystemImage+0x283
fffff880`009a9610 fffff800`0350c7a1 : 00000000`00000000 00000000`00000000 fffffa80`0975f4b0 fffff800`03355f5a : nt!MmUnloadSystemImage+0x4d
fffff880`009a9650 fffff800`030a01d4 : 00000000`00000000 00000000`00000000 fffffa80`0975f4b0 00000000`20200000 : nt!IopDeleteDriver+0x41
fffff880`009a9680 fffff800`0347b421 : 00000000`00000000 fffffa80`0a80de70 fffffa80`0a944000 00000000`00000000 : nt!ObfDereferenceObject+0xd4
fffff880`009a96e0 fffff800`035c12c6 : fffffa80`0a9f2b10 fffffa80`0a9f2b10 fffffa80`0a9f2a80 fffff980`0000001c : nt!IopLoadDriver+0xb61
fffff880`009a99b0 fffff800`035c2482 : fffff800`c0000001 fffff980`05028fc0 00000000`00000000 fffff8a0`005aef00 : nt!IopInitializeSystemDrivers+0x1d6
fffff880`009a9a40 fffff800`035c54b5 : 00000000`00000007 00000000`00000010 ffffffff`8000002c fffff800`00818ae0 : nt!IoInitSystem+0x9b2
fffff880`009a9b40 fffff800`03515c49 : 00000000`00000000 fffffa80`096f9640 00000000`00000080 fffffa80`096f9b30 : nt!Phase1InitializationDiscard+0x1275
fffff880`009a9d10 fffff800`0332de5a : 00000000`00000000 00000000`00000080 00000000`00000000 fffff800`03087d19 : nt!Phase1Initialization+0x9
fffff880`009a9d40 fffff800`03087d26 : fffff800`03209e80 fffffa80`096f9640 fffff800`03217cc0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`009a9d80 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16
STACK_COMMAND: kb
FOLLOWUP_NAME: MachineOwner
FAILURE_BUCKET_ID: X64_0xc4_62_VRF_LEAKED_POOL_IMAGE_VBoxSF.sys
BUCKET_ID: X64_0xc4_62_VRF_LEAKED_POOL_IMAGE_VBoxSF.sys
Followup: MachineOwner
---------
7: kd> lmvm VBoxSF
start end module name
fffff880`04400000 fffff880`0444f000 VBoxSF T (no symbols)
Loaded symbol image file: VBoxSF.sys
Image path: \SystemRoot\system32\drivers\VBoxSF.sys
Image name: VBoxSF.sys
Timestamp: Tue Dec 18 06:18:10 2012 (50D050F2)
CheckSum: 0004C0CD
ImageSize: 0004F000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
That's all there is to it! Fortunately, because you had Driver Verifier on, this ended up being an easy discovery. However, often without DV, and sometimes even with DV, the results aren't as spot-on as we'd like, and usually one needs to do further investigation to get down to the root cause. I'm hoping that isn't the case here, and that the VBox driver really is responsible (very much likely).