I wrote a simple packet filter driver based on the example ‘passthru’ of the Windows DDK, when I turned on the filter function, the OS is crashed and I got the following message from the WinDbg:
Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 Copyright (c)
Microsoft Corporation. All rights reserved.Loading Dump File [D:\iCheckTool\dump\MEMORY.DMP] Kernel Summary Dump
File: Only kernel address space is availableWARNING: Whitespace at start of path element Symbol search path is:
D:\iCheckTool\dump;
SRV*E:\DebuggingSymbols*http://msdl.microsoft.com/download/symbols;SRV*C:\MyLocalSymbols*http://192.168.20.25/zfprisymbols/
Executable search path is: Windows XP Kernel Version 2600 (Service
Pack 3) MP (2 procs) Free x86 compatible Product: WinNt, suite:
TerminalServer SingleUserTS Built by: 2600.xpsp_sp3_qfe.120504-1617
Machine Name: Kernel base = 0x804d8000 PsLoadedModuleList = 0x8055e720
Debug session time: Tue Sep 11 09:41:02.828 2012 (UTC + 8:00) System
Uptime: 0 days 0:02:30.578 Loading Kernel Symbols
………………………………………………………
……………………………………………………. Loading
User Symbols PEB is paged out (Peb.Ldr = 7ffd800c). Type “.hh
dbgerr001” for details Loading unloaded module list ……..
- *
- Bugcheck Analysis *
- *
Use !analyze -v to get detailed debugging information.
BugCheck C5, {4, 2, 1, 8054c10f}
Probably caused by : Pool_Corruption ( nt!ExDeferredFreePool+109 )
Followup: Pool_corruption
1: kd> !analyze -v
- *
- Bugcheck Analysis *
- *
DRIVER_CORRUPTED_EXPOOL (c5) An attempt was made to access a pageable
(or completely invalid) address at an interrupt request level (IRQL)
that is too high. This is caused by drivers that have corrupted the
system pool. Run the driver verifier against any new (or suspect)
drivers, and if that doesn’t turn up the culprit, then use gflags to
enable special pool. Arguments: Arg1: 00000004, memory referenced
Arg2: 00000002, IRQL Arg3: 00000001, value 0 = read operation, 1 =
write operation Arg4: 8054c10f, address which referenced memoryDebugging Details:
BUGCHECK_STR: 0xC5_2
CURRENT_IRQL: 2
FAULTING_IP: nt!ExDeferredFreePool+109 8054c10f 895f04 mov
dword ptr [edi+4],ebxDEFAULT_BUCKET_ID: DRIVER_FAULT
PROCESS_NAME: explorer.exe
TRAP_FRAME: b42555dc — (.trap 0xffffffffb42555dc) ErrCode = 00000002
eax=89cc1c60 ebx=89e4ded8 ecx=000001ff edx=89cc2a78 esi=80565d20
edi=00000000 eip=8054c10f esp=b4255650 ebp=b4255690 iopl=0 nv
up ei ng nz ac pe cy cs=0008 ss=0010 ds=0023 es=0023 fs=0030
gs=0000 efl=00010297 nt!ExDeferredFreePool+0x109: 8054c10f
895f04 mov dword ptr [edi+4],ebx
ds:0023:00000004=???????? Resetting default scopeLOCK_ADDRESS: 8055c4e0 — (!locks 8055c4e0)
Resource @ nt!PiEngineLock (0x8055c4e0) Available
Contention Count = 1 1 total locksPNP_TRIAGE: Lock address : 0x8055c4e0 Thread Count : 0 Thread
address: 0x00000000 Thread wait : 0x0LAST_CONTROL_TRANSFER: from 8054c10f to 80545768
STACK_TEXT: b42555dc 8054c10f badb0d00 89cc2a78 b8338538
nt!KiTrap0E+0x238 b4255690 8054c75f 00000001 8055c100 00020019
nt!ExDeferredFreePool+0x109 b42556d0 8058635e 899522e8 00000000
b42557d8 nt!ExFreePoolWithTag+0x47f b42556fc 805878b8 c0000023
00000007 8058758c nt!PiGetDeviceRegistryProperty+0x108 b425578c
bf879f40 8a523030 00000001 00000100 nt!IoGetDeviceProperty+0x25e
b42558f8 bf879735 00000000 e1b5e008 00000000
win32k!DrvEnumDisplayDevices+0x33b b425591c 8054268c 00000000 00000000
0007ecc4 win32k!NtUserEnumDisplayDevices+0x7c b425591c 7c92e514
00000000 00000000 0007ecc4 nt!KiFastCallEntry+0xfc WARNING: Frame IP
not in any known module. Following frames may be wrong. 0007f010
00000000 00000000 00000000 00000000 0x7c92e514STACK_COMMAND: kb
FOLLOWUP_IP: nt!ExDeferredFreePool+109 8054c10f 895f04 mov
dword ptr [edi+4],ebxSYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt!ExDeferredFreePool+109
FOLLOWUP_NAME: Pool_corruption
IMAGE_NAME: Pool_Corruption
DEBUG_FLR_IMAGE_TIMESTAMP: 0
MODULE_NAME: Pool_Corruption
FAILURE_BUCKET_ID: 0xC5_2_nt!ExDeferredFreePool+109
BUCKET_ID: 0xC5_2_nt!ExDeferredFreePool+109
Followup: Pool_corruption
Can someone tell me what caused this problem and how to fix it?
Thanks.
Apparently, you tried to write into invalid memory region (address = 0x4). Beyond this the debugger analysis you posted isn’t too helpful. You can try finding your driver stack (which is not present in your posted debug output) in the debugger to get the failing code, but it’s not guaranteed. Other methods to attack this include adding debug prints to your code and capturing it with DbgView (you can later extract them from the memory dump). And you can also connect kernel debugger and catch the error when it happens.