Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\x\Desktop\Dump\092111-44273-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`04e49000 PsLoadedModuleList = 0xfffff800`0508e670
Debug session time: Wed Sep 21 07:15:02.214 2011 (UTC + 3:00)
System Uptime: 1 days 0:09:10.167
Loading Kernel Symbols
...............................................................
................................................................
...................................................
Loading User Symbols
Loading unloaded module list
...............
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 19, {21, fffffa801514e000, 3850, 0}
Probably caused by : volsnap.sys ( volsnap!VspFreeBitMap+3d )
Followup: MachineOwner
---------
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 0000000000000021, the data following the pool block being freed is corrupt. Typically this means the consumer (call stack ) has overrun the block.
Arg2: fffffa801514e000, The pool pointer being freed.
Arg3: 0000000000003850, The number of bytes allocated for the pool block.
Arg4: 0000000000000000, The corrupted value found following the pool block.
Debugging Details:
------------------
BUGCHECK_STR: 0x19_21
POOL_ADDRESS: GetPointerFromAddress: unable to read from fffff800050f8100
fffffa801514e000
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 2
LAST_CONTROL_TRANSFER: from fffff80004ff39b2 to fffff80004ec5c40
STACK_TEXT:
fffff880`03585a38 fffff800`04ff39b2 : 00000000`00000019 00000000`00000021 fffffa80`1514e000 00000000`00003850 : nt!KeBugCheckEx
fffff880`03585a40 fffff880`01a69dfd : 00000000`00000000 fffffa80`0f0eea30 00000000`6d536f56 00000000`00000000 : nt!ExDeferredFreePool+0xfaa
fffff880`03585af0 fffff880`01aa02fa : fffffa80`0d363650 00000000`01d1c240 fffffa80`0f0eea30 fffffa80`11690850 : volsnap!VspFreeBitMap+0x3d
fffff880`03585b20 fffff800`04ed0001 : fffff880`01aa0060 fffff800`050662b8 fffffa80`0c781b60 fffffa80`13e53dc0 : volsnap!VspReadjustBitmap+0x29a
fffff880`03585b70 fffff800`05160fee : 00000000`00000000 fffffa80`0c781b60 00000000`00000080 fffffa80`0c6fe890 : nt!ExpWorkerThread+0x111
fffff880`03585c00 fffff800`04eb75e6 : fffff880`03389180 fffffa80`0c781b60 fffff880`033940c0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`03585c40 00000000`00000000 : fffff880`03586000 fffff880`03580000 fffff880`03585690 00000000`00000000 : nt!KxStartSystemThread+0x16
STACK_COMMAND: kb
FOLLOWUP_IP:
volsnap!VspFreeBitMap+3d
fffff880`01a69dfd 4c8b5b08 mov r11,qword ptr [rbx+8]
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: volsnap!VspFreeBitMap+3d
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: volsnap
IMAGE_NAME: volsnap.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4ce792c8
FAILURE_BUCKET_ID: X64_0x19_21_volsnap!VspFreeBitMap+3d
BUCKET_ID: X64_0x19_21_volsnap!VspFreeBitMap+3d
Followup: MachineOwner
---------
At least I know what's causing my recent frequent BSODs now, and I know exactly where to start.
