BUG的详情
被调试机：7600.16385.x86fre.win7_rtm.090713-1255
调试机：win10,
调试工具：windbg proview
导致蓝屏的软件：pchunter
视频：https://www.youtube.com/watch?v=8tBRtlvapWU
运行pchunter，点击“网络”卡片页时，系统就会蓝屏。
对第一次蓝屏捕捉到的信息进行分析。这里只列出了一些重点信息及描述。
BUG的概述
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: fffffff5, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 840bf2ee, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved) PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: fffffff5, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 840bf2ee, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)
BugCheckCode：PAGE_FAULT_IN_NONPAGED_AREA 是微软定义的Bug编码，其值为0x00000050.下面英文说的是，系统使用了无效的系统内存导致触发异常，且该异常没能被处理。可能是内存地址被破坏了或被释放了。
Arguments，为参数错误检查。这里检测到的信息是，参数1：指出当前系统访问当地址是0xfffffff5；参数2：是说当前的操作是读；参数3：是说当前指令的地址是0x840bf2ee；参数4：保留。
BUG的详情
Debugging Details:
------------------
KEY_VALUES_STRING: 1
TIMELINE_ANALYSIS: 1
DUMP_CLASS: 1
DUMP_QUALIFIER: 0
BUILD_VERSION_STRING: 7600.16385.x86fre.win7_rtm.090713-1255
DUMP_TYPE: 0
BUGCHECK_P1: fffffffffffffff5
BUGCHECK_P2: 0
BUGCHECK_P3: ffffffff840bf2ee
BUGCHECK_P4: 0
READ_ADDRESS: fffffff5
FAULTING_IP:
nt!ObpQueryNameString+2b
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch]
......
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
PROCESS_NAME: PCHunter32.exe
BUILD_VERSION_STRING：指出了运行的系统版本信息。
BUGCHECK_P1~4：和BUG概述中的基本一致。
READ_ADDRESS：读地址为0xfffffff5的内存。
FAULTING_IP：导致Bug的地址。即该bug发生在nt!ObpQueryNameString+2b处，该地址的需要执行的指令是
DEFAULT_BUCKET_ID：故障类型。这里指出是win7驱动发生故障。
PROCESS_NAME：与该BUG相关的进程。
陷阱帧
TRAP_FRAME: 98926954 -- (.trap 0xffffffff98926954)
.trap 0xffffffff98926954
ErrCode = 00000000
eax=98926a1c ebx=00000000 ecx=98926abc edx=98926a6c esi=ffffffe9 edi=00000001
eip=840bf2ee esp=989269c8 ebp=98926a2c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!ObpQueryNameString+0x2b:
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] ds:0023:fffffff5=??
.trap
Resetting default scope
LAST_CONTROL_TRANSFER: from 83f1ee71 to 83ead394
TRAP_FRAME ：陷阱帧，是一个nt!_KTRAP_FRAME结构体。
KTRAP_FRAME 用于在系统处理异常或中断期间，保存CPU的寄存器的内容。 KTRAP_FRAME结构通常分配在线程的内核模式堆栈中。陷阱帧的一小部分由CPU填充，作为其自身中断和异常处理的一部分，陷阱帧的其余部分由Windows提供的软件异常和中断处理程序
创建
（例如KiTrap0E（）、KiPageFault
KiInterruptDispatch
等函数）。
LAST_CONTROL_TRANSFER：最后的控制权转让，也就是调用栈中的最后一个CALL。这里，在地址0x83f1ee71调用了0x83ead394
调用堆栈
STACK_TEXT:
9892649c 83f1ee71 00000003 21db833f 00000065 nt!RtlpBreakWithStatusInstruction
989264ec 83f1f96d 00000003 88621d48 00000000 nt!KiBugCheckDebugBreak+0x1c
989268b0 83ec78e3 00000050 fffffff5 00000000 nt!KeBugCheck2+0x68b
9892693c 83e885f8 00000000 fffffff5 00000000 nt!MmAccessFault+0x106
9892693c 840bf2ee 00000000 fffffff5 00000000 nt!KiTrap0E+0xdc
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18
98926af4 8bc77245 03fc016c 001ffeb4 00000000 PCHunter32aq+0x52887
98926b2c 8bc772d3 00000010 0000013c 98926bfc PCHunter32aq+0x53245
98926b3c 8bca740b 00000000 00000000 03fc0020 PCHunter32aq+0x532d3
98926bfc 83e7e4bc 886240d8 88722178 88722178 PCHunter32aq+0x8340b
98926c14 8407feee 8862cc68 88722178 887221e8 nt!IofCallDriver+0x63
98926c34 8409ccd1 886240d8 8862cc68 00000000 nt!IopSynchronousServiceTail+0x1f8
98926cd0 8409f4ac 886240d8 88722178 00000000 nt!IopXxxControlFile+0x6aa
98926d04 83e8542a 00000258 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
98926d04 779464f4 00000258 00000000 00000000 nt!KiFastCallEntry+0x12a
001263e0 77944cac 75d0a08f 00000258 00000000 ntdll!KiFastSystemCallRet
001263e4 75d0a08f 00000258 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
00126444 768eec25 00000258 04470140 00126538 KERNELBASE!DeviceIoControl+0xf6
00126470 008cf640 00000258 04470140 00126538 kernel32!DeviceIoControlImplementation+0x80
00126520 00409ffa 00000000 0012c400 00000000 PCHunter32+0x4cf640
...
前面5个函数是系统用来保存现场（寄存器）以及检测崩溃信息。
从BUG详情中已经知道，崩溃地址是nt!ObpQueryNameString+0x2b。是由于[esi+0Ch]=0xfffffff5导致的。
追踪崩溃源头
Debugging Details:
------------------
KEY_VALUES_STRING: 1
TIMELINE_ANALYSIS: 1
DUMP_CLASS: 1
DUMP_QUALIFIER: 0
BUILD_VERSION_STRING: 7600.16385.x86fre.win7_rtm.090713-1255
DUMP_TYPE: 0
BUGCHECK_P1: fffffffffffffff5
BUGCHECK_P2: 0
BUGCHECK_P3: ffffffff840bf2ee
BUGCHECK_P4: 0
READ_ADDRESS: fffffff5
FAULTING_IP:
nt!ObpQueryNameString+2b
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch]
......
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
PROCESS_NAME: PCHunter32.exe
BUILD_VERSION_STRING：指出了运行的系统版本信息。
BUGCHECK_P1~4：和BUG概述中的基本一致。
READ_ADDRESS：读地址为0xfffffff5的内存。
FAULTING_IP：导致Bug的地址。即该bug发生在nt!ObpQueryNameString+2b处，该地址的需要执行的指令是
DEFAULT_BUCKET_ID：故障类型。这里指出是win7驱动发生故障。
PROCESS_NAME：与该BUG相关的进程。
陷阱帧
Debugging Details:
------------------
KEY_VALUES_STRING: 1
TIMELINE_ANALYSIS: 1
DUMP_CLASS: 1
DUMP_QUALIFIER: 0
BUILD_VERSION_STRING: 7600.16385.x86fre.win7_rtm.090713-1255
DUMP_TYPE: 0
BUGCHECK_P1: fffffffffffffff5
BUGCHECK_P2: 0
BUGCHECK_P3: ffffffff840bf2ee
BUGCHECK_P4: 0
READ_ADDRESS: fffffff5
FAULTING_IP:
nt!ObpQueryNameString+2b
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch]
......
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
PROCESS_NAME: PCHunter32.exe
BUILD_VERSION_STRING：指出了运行的系统版本信息。
BUGCHECK_P1~4：和BUG概述中的基本一致。
READ_ADDRESS：读地址为0xfffffff5的内存。
FAULTING_IP：导致Bug的地址。即该bug发生在nt!ObpQueryNameString+2b处，该地址的需要执行的指令是
DEFAULT_BUCKET_ID：故障类型。这里指出是win7驱动发生故障。
PROCESS_NAME：与该BUG相关的进程。
陷阱帧
TRAP_FRAME: 98926954 -- (.trap 0xffffffff98926954)
.trap 0xffffffff98926954
ErrCode = 00000000
eax=98926a1c ebx=00000000 ecx=98926abc edx=98926a6c esi=ffffffe9 edi=00000001
eip=840bf2ee esp=989269c8 ebp=98926a2c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!ObpQueryNameString+0x2b:
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] ds:0023:fffffff5=??
.trap
Resetting default scope
LAST_CONTROL_TRANSFER: from 83f1ee71 to 83ead394
TRAP_FRAME ：陷阱帧，是一个nt!_KTRAP_FRAME结构体。
KTRAP_FRAME 用于在系统处理异常或中断期间，保存CPU的寄存器的内容。 KTRAP_FRAME结构通常分配在线程的内核模式堆栈中。陷阱帧的一小部分由CPU填充，作为其自身中断和异常处理的一部分，陷阱帧的其余部分由Windows提供的软件异常和中断处理程序
创建
（例如KiTrap0E（）、KiPageFault
KiInterruptDispatch
等函数）。
LAST_CONTROL_TRANSFER：最后的控制权转让，也就是调用栈中的最后一个CALL。这里，在地址0x83f1ee71调用了0x83ead394
TRAP_FRAME: 98926954 -- (.trap 0xffffffff98926954)
.trap 0xffffffff98926954
ErrCode = 00000000
eax=98926a1c ebx=00000000 ecx=98926abc edx=98926a6c esi=ffffffe9 edi=00000001
eip=840bf2ee esp=989269c8 ebp=98926a2c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!ObpQueryNameString+0x2b:
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] ds:0023:fffffff5=??
.trap
Resetting default scope
LAST_CONTROL_TRANSFER: from 83f1ee71 to 83ead394
TRAP_FRAME ：陷阱帧，是一个nt!_KTRAP_FRAME结构体。
KTRAP_FRAME 用于在系统处理异常或中断期间，保存CPU的寄存器的内容。 KTRAP_FRAME结构通常分配在线程的内核模式堆栈中。陷阱帧的一小部分由CPU填充，作为其自身中断和异常处理的一部分，陷阱帧的其余部分由Windows提供的软件异常和中断处理程序
创建
（例如KiTrap0E（）、KiPageFault
KiInterruptDispatch
等函数）。
LAST_CONTROL_TRANSFER：最后的控制权转让，也就是调用栈中的最后一个CALL。这里，在地址0x83f1ee71调用了0x83ead394
调用堆栈
STACK_TEXT:
9892649c 83f1ee71 00000003 21db833f 00000065 nt!RtlpBreakWithStatusInstruction
989264ec 83f1f96d 00000003 88621d48 00000000 nt!KiBugCheckDebugBreak+0x1c
989268b0 83ec78e3 00000050 fffffff5 00000000 nt!KeBugCheck2+0x68b
9892693c 83e885f8 00000000 fffffff5 00000000 nt!MmAccessFault+0x106
9892693c 840bf2ee 00000000 fffffff5 00000000 nt!KiTrap0E+0xdc
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18
98926af4 8bc77245 03fc016c 001ffeb4 00000000 PCHunter32aq+0x52887
98926b2c 8bc772d3 00000010 0000013c 98926bfc PCHunter32aq+0x53245
98926b3c 8bca740b 00000000 00000000 03fc0020 PCHunter32aq+0x532d3
98926bfc 83e7e4bc 886240d8 88722178 88722178 PCHunter32aq+0x8340b
98926c14 8407feee 8862cc68 88722178 887221e8 nt!IofCallDriver+0x63
98926c34 8409ccd1 886240d8 8862cc68 00000000 nt!IopSynchronousServiceTail+0x1f8
98926cd0 8409f4ac 886240d8 88722178 00000000 nt!IopXxxControlFile+0x6aa
98926d04 83e8542a 00000258 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
98926d04 779464f4 00000258 00000000 00000000 nt!KiFastCallEntry+0x12a
001263e0 77944cac 75d0a08f 00000258 00000000 ntdll!KiFastSystemCallRet
001263e4 75d0a08f 00000258 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
00126444 768eec25 00000258 04470140 00126538 KERNELBASE!DeviceIoControl+0xf6
00126470 008cf640 00000258 04470140 00126538 kernel32!DeviceIoControlImplementation+0x80
00126520 00409ffa 00000000 0012c400 00000000 PCHunter32+0x4cf640
...
前面5个函数是系统用来保存现场（寄存器）以及检测崩溃信息。
从BUG详情中已经知道，崩溃地址是nt!ObpQueryNameString+0x2b。是由于[esi+0Ch]=0xfffffff5导致的。
追踪崩溃源头
STACK_TEXT:
9892649c 83f1ee71 00000003 21db833f 00000065 nt!RtlpBreakWithStatusInstruction
989264ec 83f1f96d 00000003 88621d48 00000000 nt!KiBugCheckDebugBreak+0x1c
989268b0 83ec78e3 00000050 fffffff5 00000000 nt!KeBugCheck2+0x68b
9892693c 83e885f8 00000000 fffffff5 00000000 nt!MmAccessFault+0x106
9892693c 840bf2ee 00000000 fffffff5 00000000 nt!KiTrap0E+0xdc
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18
98926af4 8bc77245 03fc016c 001ffeb4 00000000 PCHunter32aq+0x52887
98926b2c 8bc772d3 00000010 0000013c 98926bfc PCHunter32aq+0x53245
98926b3c 8bca740b 00000000 00000000 03fc0020 PCHunter32aq+0x532d3
98926bfc 83e7e4bc 886240d8 88722178 88722178 PCHunter32aq+0x8340b
98926c14 8407feee 8862cc68 88722178 887221e8 nt!IofCallDriver+0x63
98926c34 8409ccd1 886240d8 8862cc68 00000000 nt!IopSynchronousServiceTail+0x1f8
98926cd0 8409f4ac 886240d8 88722178 00000000 nt!IopXxxControlFile+0x6aa
98926d04 83e8542a 00000258 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
98926d04 779464f4 00000258 00000000 00000000 nt!KiFastCallEntry+0x12a
001263e0 77944cac 75d0a08f 00000258 00000000 ntdll!KiFastSystemCallRet
001263e4 75d0a08f 00000258 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
00126444 768eec25 00000258 04470140 00126538 KERNELBASE!DeviceIoControl+0xf6
00126470 008cf640 00000258 04470140 00126538 kernel32!DeviceIoControlImplementation+0x80
00126520 00409ffa 00000000 0012c400 00000000 PCHunter32+0x4cf640
...
前面5个函数是系统用来保存现场（寄存器）以及检测崩溃信息。
从BUG详情中已经知道，崩溃地址是nt!ObpQueryNameString+0x2b。是由于[esi+0Ch]=0xfffffff5导致的。
追踪崩溃源头
追踪崩溃源头
查看
nt!ObpQueryNameString ~ nt!ObpQueryNameString+0x2b的
反汇编：
查看
nt!ObpQueryNameString ~ nt!ObpQueryNameString+0x2b的
反汇编：
查看
nt!ObpQueryNameString ~ nt!ObpQueryNameString+0x2b的
反汇编：
uf nt!ObpQueryNameString
nt!ObpQueryNameString:
840bf2c3 6a44 push 44h
840bf2c5 68f0c3e583 push offset nt! ?? ::FNODOBFM::`string'+0x1790 (83e5c3f0)
840bf2ca e83932dfff call nt!_SEH_prolog4 (83e72508)
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8]
840bf2d2 c745d8010000c0 mov dword ptr [ebp-28h],0C0000001h
840bf2d9 33db xor ebx,ebx
840bf2db 895dc4 mov dword ptr [ebp-3Ch],ebx
840bf2de 895de0 mov dword ptr [ebp-20h],ebx
840bf2e1 c645e701 mov byte ptr [ebp-19h],1
840bf2e5 885de6 mov byte ptr [ebp-1Ah],bl
840bf2e8 8d77e8 lea esi,[edi-18h]
840bf2eb 8975d0 mov dword ptr [ebp-30h],esi
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] uf nt!ObpQueryNameString
nt!ObpQueryNameString:
840bf2c3 6a44 push 44h
840bf2c5 68f0c3e583 push offset nt! ?? ::FNODOBFM::`string'+0x1790 (83e5c3f0)
840bf2ca e83932dfff call nt!_SEH_prolog4 (83e72508)
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8]
840bf2d2 c745d8010000c0 mov dword ptr [ebp-28h],0C0000001h
840bf2d9 33db xor ebx,ebx
840bf2db 895dc4 mov dword ptr [ebp-3Ch],ebx
840bf2de 895de0 mov dword ptr [ebp-20h],ebx
840bf2e1 c645e701 mov byte ptr [ebp-19h],1
840bf2e5 885de6 mov byte ptr [ebp-1Ah],bl
840bf2e8 8d77e8 lea esi,[edi-18h]
840bf2eb 8975d0 mov dword ptr [ebp-30h],esi
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] uf nt!ObpQueryNameString
nt!ObpQueryNameString:
840bf2c3 6a44 push 44h
840bf2c5 68f0c3e583 push offset nt! ?? ::FNODOBFM::`string'+0x1790 (83e5c3f0)
840bf2ca e83932dfff call nt!_SEH_prolog4 (83e72508)
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8]
840bf2d2 c745d8010000c0 mov dword ptr [ebp-28h],0C0000001h
840bf2d9 33db xor ebx,ebx
840bf2db 895dc4 mov dword ptr [ebp-3Ch],ebx
840bf2de 895de0 mov dword ptr [ebp-20h],ebx
840bf2e1 c645e701 mov byte ptr [ebp-19h],1
840bf2e5 885de6 mov byte ptr [ebp-1Ah],bl
840bf2e8 8d77e8 lea esi,[edi-18h]
840bf2eb 8975d0 mov dword ptr [ebp-30h],esi
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] uf nt!ObpQueryNameString
nt!ObpQueryNameString:
840bf2c3 6a44 push 44h
840bf2c5 68f0c3e583 push offset nt! ?? ::FNODOBFM::`string'+0x1790 (83e5c3f0)
840bf2ca e83932dfff call nt!_SEH_prolog4 (83e72508)
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8]
840bf2d2 c745d8010000c0 mov dword ptr [ebp-28h],0C0000001h
840bf2d9 33db xor ebx,ebx
840bf2db 895dc4 mov dword ptr [ebp-3Ch],ebx
840bf2de 895de0 mov dword ptr [ebp-20h],ebx
840bf2e1 c645e701 mov byte ptr [ebp-19h],1
840bf2e5 885de6 mov byte ptr [ebp-1Ah],bl
840bf2e8 8d77e8 lea esi,[edi-18h]
840bf2eb 8975d0 mov dword ptr [ebp-30h],esi
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] 上述代码有关esi的整理如下：
------------------------------------------------------------------------------------------
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8] ;edi=arg1
840bf2e8 8d77e8 lea esi,[edi-18h] ;esi=[arg1-18h]
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] ;eax=*(byte*)(esi+0c) error
------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8] ;edi=arg1
840bf2e8 8d77e8 lea esi,[edi-18h] ;esi=[arg1-18h]
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] ;eax=*(byte*)(esi+0c) error
------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8] ;edi=arg1
840bf2e8 8d77e8 lea esi,[edi-18h] ;esi=[arg1-18h]
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] ;eax=*(byte*)(esi+0c) error
------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8] ;edi=arg1
840bf2e8 8d77e8 lea esi,[edi-18h] ;esi=[arg1-18h]
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] ;eax=*(byte*)(esi+0c) error
------------------------------------------------------------------------------------------
这说明，导致esi+0ch崩溃的是因为arg1=1 。通过查看调用栈可知：arg1 是 nt!ObQueryNameString 传递给 nt!ObpQueryNameString 的第一个参数。
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18
这说明，导致esi+0ch崩溃的是因为arg1=1 。通过查看调用栈可知：arg1 是 nt!ObQueryNameString 传递给 nt!ObpQueryNameString 的第一个参数。
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18
这说明，导致esi+0ch崩溃的是因为arg1=1 。通过查看调用栈可知：arg1 是 nt!ObQueryNameString 传递给 nt!ObpQueryNameString 的第一个参数。
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18 这说明，导致esi+0ch崩溃的是因为arg1=1 。通过查看调用栈可知：arg1 是 nt!ObQueryNameString 传递给 nt!ObpQueryNameString 的第一个参数。
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18 98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18
uf nt!ObQueryNameString
nt!ObQueryNameString:
840bfa62 8bff mov edi,edi
840bfa64 55 push ebp
840bfa65 8bec mov ebp,esp
840bfa67 6a00 push 0
840bfa69 ff7514 push dword ptr [ebp+14h] ;
840bfa6c ff7510 push dword ptr [ebp+10h] ;
840bfa6f ff750c push dword ptr [ebp+0Ch] ;
840bfa72 ff7508 push dword ptr [ebp+8] ;arg1:
840bfa75 e849f8ffff call nt!ObpQueryNameString (840bf2c3)
840bfa7a 5d pop ebp
840bfa7b c21000 ret 10h 分析
nt!ObQueryNameString
传给
nt!ObpQueryNameString的第一个参数是从哪里来的？都做了什么操作？
从汇编代码中很容易看出，传递给
nt!ObpQueryNameString的第一个参数也是
nt!ObQueryNameString的第一个参数，而且 nt!ObQueryNameString 未修改参数1.
补充：
ObQueryNameString 函数：返回指定内核对象的名称。
uf nt!ObQueryNameString
nt!ObQueryNameString:
840bfa62 8bff mov edi,edi
840bfa64 55 push ebp
840bfa65 8bec mov ebp,esp
840bfa67 6a00 push 0
840bfa69 ff7514 push dword ptr [ebp+14h] ;
840bfa6c ff7510 push dword ptr [ebp+10h] ;
840bfa6f ff750c push dword ptr [ebp+0Ch] ;
840bfa72 ff7508 push dword ptr [ebp+8] ;arg1:
840bfa75 e849f8ffff call nt!ObpQueryNameString (840bf2c3)
840bfa7a 5d pop ebp
840bfa7b c21000 ret 10h 分析
nt!ObQueryNameString
传给
nt!ObpQueryNameString的第一个参数是从哪里来的？都做了什么操作？
从汇编代码中很容易看出，传递给
nt!ObpQueryNameString的第一个参数也是
nt!ObQueryNameString的第一个参数，而且 nt!ObQueryNameString 未修改参数1.
补充：
ObQueryNameString 函数：返回指定内核对象的名称。
uf nt!ObQueryNameString
nt!ObQueryNameString:
840bfa62 8bff mov edi,edi
840bfa64 55 push ebp
840bfa65 8bec mov ebp,esp
840bfa67 6a00 push 0
840bfa69 ff7514 push dword ptr [ebp+14h] ;
840bfa6c ff7510 push dword ptr [ebp+10h] ;
840bfa6f ff750c push dword ptr [ebp+0Ch] ;
840bfa72 ff7508 push dword ptr [ebp+8] ;arg1:
840bfa75 e849f8ffff call nt!ObpQueryNameString (840bf2c3)
840bfa7a 5d pop ebp
840bfa7b c21000 ret 10h 分析
nt!ObQueryNameString
传给
nt!ObpQueryNameString的第一个参数是从哪里来的？都做了什么操作？
从汇编代码中很容易看出，传递给
nt!ObpQueryNameString的第一个参数也是
nt!ObQueryNameString的第一个参数，而且 nt!ObQueryNameString 未修改参数1.
补充：
ObQueryNameString 函数：返回指定内核对象的名称。
NTKERNELAPI NTSTATUS ObQueryNameString(
PVOID Object,
POBJECT_NAME_INFORMATION ObjectNameInfo,
ULONG Length,
PULONG ReturnLength
);
参数
Object：内核对象的指针，该值不能为NULL.
ObjectNameInfo：由用户提供的存放返回值得缓冲区，若不知大小则可以为NULL，由ReturnLength返回需要的缓冲区大小。
NTKERNELAPI NTSTATUS ObQueryNameString(
PVOID Object,
POBJECT_NAME_INFORMATION ObjectNameInfo,
ULONG Length,
PULONG ReturnLength
);
参数
Object：内核对象的指针，该值不能为NULL.
ObjectNameInfo：由用户提供的存放返回值得缓冲区，若不知大小则可以为NULL，由ReturnLength返回需要的缓冲区大小。
参数
Object：内核对象的指针，该值不能为NULL.
ObjectNameInfo：由用户提供的存放返回值得缓冲区，若不知大小则可以为NULL，由ReturnLength返回需要的缓冲区大小。
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！
最后于 2018-6-2 09:26
被Koorey编辑
，原因： 上传了当时的dump文件
上传的附件：
