windows驱动详解附带代码 调试蓝屏

Question

张帆的windows驱动技术详解 第6章 stringtest
不过似乎光盘中代码在第5章节
原代码似乎是一个一个功能开启的
  /*//字符串初始化实验
  StringInitTest();  //字符串拷贝实验
  StringCopyTest();  //字符串比较实验
  StringCompareTest();  //字符串变大写实验
  StringToUpperTest();  //字符串与整型相互转化实验
  StringToIntegerTest();  //ANSI_STRING字符串与UNICODE_STRING字符串相互转换实验
  StringConverTest();*/
我将测试函数一次全部开启在虚拟机XP下调试 NET STOP时候蓝屏WINDBG查看DUMP文件显示是unload函数问题 
但是我怀疑是内存问题 

Answer 1

帖代码或者WinDbg的!analyze输出来看看吧

Answer 2

谢谢楼上两位 
主要是想学习下分析的手段 毕竟以后的自己程序的蓝屏分析更加棘手
这次蓝屏学习到的问题就 WINDBG的分析DUMP文件似乎定位并不准确“帖代码或者WinDbg的!analyze输出来看看吧”
这边不带附件而且代码很长（我也不知道哪里出了问题）
不过CSDN似乎有驱动技术详解的源代码下DUMP文件
kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: f7a101b0, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 805b64b4, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)Debugging Details:
------------------
Could not read faulting driver nameREAD_ADDRESS:  f7a101b0 FAULTING_IP: 
nt!ObpCaptureObjectName+c6
805b64b4 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]MM_INTERNAL_CODE:  0CUSTOMER_CRASH_COUNT:  2DEFAULT_BUCKET_ID:  DRIVER_FAULTBUGCHECK_STR:  0x50PROCESS_NAME:  SystemLAST_CONTROL_TRANSFER:  from 805b6641 to 805b64b4STACK_TEXT:  
f7922b94 805b6641 e100d600 f7922d4c f7922c18 nt!ObpCaptureObjectName+0xc6
f7922be8 805b0ab6 865eb0f0 e100d600 e100d600 nt!ObpCaptureObjectCreateInformation+0x135
f7922c2c 805ba669 f7922d24 865eb0f0 e100d600 nt!ObOpenObjectByName+0x62
f7922c84 8053d808 f7922d44 00010000 f7922d24 nt!NtOpenSymbolicLinkObject+0x73
f7922c84 804fec71 f7922d44 00010000 f7922d24 nt!KiFastCallEntry+0xf8
f7922d08 8056917c f7922d44 00010000 f7922d24 nt!ZwOpenSymbolicLinkObject+0x11
f7922d3c f7a0f6d6 f7922d4c 86517390 001a0018 nt!IoDeleteSymbolicLink+0x3c
WARNING: Stack unwind information not available. Following frames may be wrong.
f7922d58 80576633 862cda18 f520fb84 8055b1fc StringTest+0x6d6
f7922d74 80534dd0 f520fb84 00000000 865b5640 nt!IopLoadUnloadDriver+0x19
f7922dac 805c5a28 f520fb84 00000000 00000000 nt!ExpWorkerThread+0x100
f7922ddc 80541fa2 80534cd0 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
STACK_COMMAND:  kbFOLLOWUP_IP: 
StringTest+6d6
f7a0f6d6 ??              ???SYMBOL_STACK_INDEX:  7SYMBOL_NAME:  StringTest+6d6FOLLOWUP_NAME:  MachineOwnerMODULE_NAME: StringTestIMAGE_NAME:  StringTest.sysDEBUG_FLR_IMAGE_TIMESTAMP:  4b0935ebFAILURE_BUCKET_ID:  0x50_StringTest+6d6BUCKET_ID:  0x50_StringTest+6d6Followup: MachineOwner
---------StringTest+0x6d6就是UNLOAD函数 不过应该不是这里确实是Tr0j4n所说的字符串测试函数的区段问题
能否在进一步定位？ 谢谢

Answer 3

这个是我从你得到的信息啊 如果是我单独调试 使用WINDBG或者有什么更好的工具 我能判断还出来么？
简单的说 我是从程序与工具的来的信息进行判断 而不需要老请教人
毕竟授人以鱼不如授人以渔

Answer 4

我有叫你用WinDbg么？代码里面有问题啊。代码里面的区段宏定义去掉，然后重新编译就好了啊

Answer 5

不要上火 我的意识是 如果我得不到帮助 只用WINDBG 和程序相关信息 我就判断不出来错误
我需要从这个例子得到调试和判断的知识
而不是每次都上来把例子放到这里  得知哪里错误 我需要的是如何判断是这个错误你没有叫我使用WINDBG  那个反问不是针对你

Answer 6

不过很感谢你关注这个帖子 
再次贴下 调试信息
kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: f79f8180, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 805b64b4, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)Debugging Details:
------------------
Could not read faulting driver nameREAD_ADDRESS:  f79f8180 FAULTING_IP: 
nt!ObpCaptureObjectName+c6
805b64b4 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]MM_INTERNAL_CODE:  0CUSTOMER_CRASH_COUNT:  1DEFAULT_BUCKET_ID:  DRIVER_FAULTBUGCHECK_STR:  0x50PROCESS_NAME:  SystemLAST_CONTROL_TRANSFER:  from 805b6641 to 805b64b4STACK_TEXT:  
f7922b94 805b6641 e100d600 f7922d4c f7922c18 nt!ObpCaptureObjectName+0xc6
f7922be8 805b0ab6 865eb0f0 e100d600 e100d600 nt!ObpCaptureObjectCreateInformation+0x135
f7922c2c 805ba669 f7922d24 865eb0f0 e100d600 nt!ObOpenObjectByName+0x62
f7922c84 8053d808 f7922d44 00010000 f7922d24 nt!NtOpenSymbolicLinkObject+0x73
f7922c84 804fec71 f7922d44 00010000 f7922d24 nt!KiFastCallEntry+0xf8
f7922d08 8056917c f7922d44 00010000 f7922d24 nt!ZwOpenSymbolicLinkObject+0x11
f7922d3c f79f76d6 f7922d4c 85f735a8 001a0018 nt!IoDeleteSymbolicLink+0x3c
f7922d58 80576633 861256e8 f6f6cb84 8055b1fc 2!HelloDDKUnload+0x46 [c:\share\2\driver.cpp @ 324]
f7922d74 80534dd0 f6f6cb84 00000000 865b5640 nt!IopLoadUnloadDriver+0x19
f7922dac 805c5a28 f6f6cb84 00000000 00000000 nt!ExpWorkerThread+0x100
f7922ddc 80541fa2 80534cd0 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
STACK_COMMAND:  kbFOLLOWUP_IP: 
2!HelloDDKUnload+46 [c:\share\2\driver.cpp @ 324]
f79f76d6 8b55fc          mov     edx,dword ptr [ebp-4]FAULTING_SOURCE_CODE:  
   320: 
   321:  //¨¦?3y¡¤?o?¨¢¡ä?¨®
   322:  UNICODE_STRING pLinkName = pDevExt->ustrSymLinkName;
   323:  IoDeleteSymbolicLink(&pLinkName);
>  324:  pNextObj = pNextObj->NextDevice;
   325:  IoDeleteDevice( pDevExt->pDevice );
   326:  }
   327: }
   328: 
   329: /************************************************************************
SYMBOL_STACK_INDEX:  7SYMBOL_NAME:  2!HelloDDKUnload+46FOLLOWUP_NAME:  MachineOwnerMODULE_NAME: 2IMAGE_NAME:  2.sysDEBUG_FLR_IMAGE_TIMESTAMP:  4b0a068fFAILURE_BUCKET_ID:  0x50_2!HelloDDKUnload+46BUCKET_ID:  0x50_2!HelloDDKUnload+46Followup: MachineOwner
---------

Answer 7

你在8楼帖的!analyze -v是实时调试时输出的？下面两句堆栈可以看出是HelloDDKUnload里调用IoDeleteSymbolicLink时蓝屏的：
IoDeleteSymbolicLink就一个参数，先检查这个参数是不是指向无效内存了：
IoDeleteSymbolicLink参数1的类型是UNICODE_STRING指针，地址为f7922d4c，先看看UNICODE_STRING.Buffer(f7922d4c+4)里有没有正确的SymbolicLink字符串，WinDbg实时调试时输入：
我猜输出的应该全是问号?，说明pDevExt->ustrSymLinkName这个东西可能在其它地方已经被销毁了，剩下的就是慢慢下断点一步步来跟踪了，比如给pDevExt->ustrSymLinkName设个内存访问断点ba r x xxxxxxxx

Answer 8

因为你在分页内从中访问了非分页的内存，把INITCODE 改为PAGEDCODE,就是说所有代码都放到分页内存中就不会出现这种问题了