我的第一个dmp分析

我的第一个dmp分析，还有很多说不清的，高手见笑了！

在做重定向时，发生了BSOD，dmp信息：

 

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: 00000020, a pool block header size is corrupt.
Arg2: 81f72c98, The pool entry we were looking for within the page.
Arg3: 81f72cd8, The next pool entry.
Arg4: 0a080001, (reserved)

Debugging Details:
------------------

BUGCHECK_STR:  0x19_20

POOL_ADDRESS:  81f72c98 Nonpaged pool

DEFAULT_BUCKET_ID:  DRIVER_FAULT

PROCESS_NAME:  notepad.exe

 

LAST_CONTROL_TRANSFER:  from 8054c583 to 804faf43
STACK_TEXT: 
f66e8a14 8054c583 00000019 00000020 81f72c98 nt!KeBugCheckEx+0x1b
f66e8a64 8058438a 81f72ca0 00000000 823bde18 nt!ExFreePoolWithTag+0x2a3
f66e8b4c 805c0450 823bde30 00000000 820850d8 nt!IopParseDevice+0xba2
f66e8bc4 805bc9dc 00000000 f66e8c04 00000040 nt!ObpLookupObjectName+0x53c
f66e8c18 80577033 00000000 00000000 6e8c8401 nt!ObOpenObjectByName+0xea
f66e8c94 805779aa 0007d2d4 80100080 0007d274 nt!IopCreateFile+0x407
f66e8cf0 8057a0b4 0007d2d4 80100080 0007d274 nt!IoCreateFile+0x8e
f66e8d30 8054262c 0007d2d4 80100080 0007d274 nt!NtCreateFile+0x30
f66e8d30 7c92e4f4 0007d2d4 80100080 0007d274 nt!KiFastCallEntry+0xfc

STACK_COMMAND:  kb

FOLLOWUP_IP:
nt!ExFreePoolWithTag+2a3
8054c583 8b45f8          mov     eax,dword ptr [ebp-8]

SYMBOL_STACK_INDEX:  1

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  48a3fbd9

SYMBOL_NAME:  nt!ExFreePoolWithTag+2a3

FAILURE_BUCKET_ID:  0x19_20_nt!ExFreePoolWithTag+2a3

BUCKET_ID:  0x19_20_nt!ExFreePoolWithTag+2a3

Followup: MachineOwner

 

    由崩溃前的函数调用栈看出，是NtCreateFile例程的调用过程中出现了问题。可以看到是ExFreePoolWithTag例程执行出现了错误，而KeBugCheckEx是错误发生时，内核进行的BugCheck，绘制蓝屏背景。ExFreePoolWithTag错误就比较简单了，多数是由于超额释放了Buffer所致。
    于是想到我用于重定向申请的Buffer，当使用RtlCopyUnicodeString进行Copy时，微软的RtlCopyUnicodeString很规范，很标准啊，在拷贝完String Buffer 后，它会在字符最后加一个Unicode的'/0'结束符。若申请的Buffer刚好是字符个数的Length，则‘/0’溢出了Buffer。    于是想到我用于重定向申请的Buffer，当使用RtlCopyUnicodeString进行Copy时，
微软的RtlCopyUnicodeString很规范，很标准啊，在拷贝完String Buffer 后，它会在字符最后加一个Unicode的'/0'结束符。若申请的Buffer刚好是StrLength，则‘/0’溢出了Buffer，覆盖了其他Buffer，则在ExFreePoolWithTag时很可能会BSOD。 
    所以，在申请Buffer时，Buffer的长度一定要加入结束符，即Length + '/0'。