c++ - 无需源代码即可调试/绕过 BSOD

Question

你好，祝你有美好的一天。

这里需要一些帮助:

情况:
我有一个不起眼的 DirectX 9 应用程序(名称和应用程序详细信息与问题无关)，自某些驱动程序版本以来，它会导致所有 nvidia 卡(GeForce 8400GS 及更高版本)出现蓝屏死机。我认为该问题是由 DirectX 9 调用或触发驱动程序错误的标志间接引起的。

目标:
我想追踪有问题的标志/函数调用(为了好玩，这不是我的工作/家庭作业)并通过编写代理 dll 来绕过错误条件。我已经有一个完成的代理 dll，它为 IDirect3D9、IDirect3DDevice9、IDirect3DVertexBuffer9 和 IDirect3DIndexBuffer9 提供包装器，并提供 Direct3D 调用的基本日志记录/跟踪。但是，我无法查明导致崩溃的函数。

问题:

1. 不提供源代码或技术支持。不会有任何帮助，也没有其他人可以解决问题。
2. 内核生成的内存转储没有帮助 - 显然 nv4_disp.dll 内发生了访问冲突，但我无法使用堆栈跟踪转到 IDirect3DDevice9 方法调用，而且错误有可能异步发生。
3. (主要问题)由于大量 Direct3D9Device 方法调用，我无法可靠地将它们记录到文件中或通过网络:
   1. 即使没有刷新，登录文件也会导致速度显着减慢，因此，当系统出现 BSOD 时，日志的所有最后内容都会丢失。
   2. 通过网络进行日志记录(使用 UDP 和 WINSOck 的 sendto)也会导致显着的速度减慢，并且不能异步完成(异步数据包在 BSOD 时丢失)，而且数据包(崩溃周围的数据包)有时会丢失即使同步发送也会丢失。
   3. 当应用程序因日志记录例程而“减慢”速度时，发生 BSOD 的可能性较小，这使得跟踪它变得更加困难。

问题:
我通常不编写驱动程序，也不进行这种级别的调试，所以我觉得我错过了一些重要的东西，有一种比使用自定义日志记录机制编写 IDirect3DDevice9 代理 dll 更简单的方法来追踪问题。它是什么？诊断/处理/修复这样的问题的标准方法是什么(没有源代码，COM接口(interface)方法触发BSOD)？

小型转储分析(WinDBG):

Loading User SymbolsLoading unloaded module list...........Unable to load image nv4_disp.dll, Win32 error 0n2*** WARNING: Unable to verify timestamp for nv4_disp.dll*** ERROR: Module load completed but symbols could not be loaded for nv4_disp.dll********************************************************************************                                                                             **                        Bugcheck Analysis                                    **                                                                             ********************************************************************************Use !analyze -v to get detailed debugging information.BugCheck 1000008E, {c0000005, bd0a2fd0, b0562b40, 0}Probably caused by : nv4_disp.dll ( nv4_disp+90fd0 )Followup: MachineOwner---------0: kd> !analyze -v********************************************************************************                                                                             **                        Bugcheck Analysis                                    **                                                                             ********************************************************************************KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)This is a very common bugcheck.  Usually the exception address pinpointsthe driver/function that caused the problem.  Always note this addressas well as the link date of the driver/image that contains this address.Some common problems are exception code 0x80000003.  This means a hardcoded breakpoint or assertion was hit, but this system was booted/NODEBUG.  This is not supposed to happen as developers should never havehardcoded breakpoints in retail code, but ...If this happens, make sure a debugger gets connected, and thesystem is booted /DEBUG.  This will let us see why this breakpoint ishappening.Arguments:Arg1: c0000005, The exception code that was not handledArg2: bd0a2fd0, The address that the exception occurred atArg3: b0562b40, Trap FrameArg4: 00000000Debugging Details:------------------EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".FAULTING_IP: nv4_disp+90fd0bd0a2fd0 39b8f8000000    cmp     dword ptr [eax+0F8h],ediTRAP_FRAME:  b0562b40 -- (.trap 0xffffffffb0562b40)ErrCode = 00000000eax=00000808 ebx=e37f8200 ecx=e4ae1c68 edx=e37f8328 esi=e37f8400 edi=00000000eip=bd0a2fd0 esp=b0562bb4 ebp=e37e09c0 iopl=0         nv up ei pl nz na po nccs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202nv4_disp+0x90fd0:bd0a2fd0 39b8f8000000    cmp     dword ptr [eax+0F8h],edi ds:0023:00000900=????????Resetting default scopeCUSTOMER_CRASH_COUNT:  3DEFAULT_BUCKET_ID:  DRIVER_FAULTBUGCHECK_STR:  0x8ELAST_CONTROL_TRANSFER:  from bd0a2e33 to bd0a2fd0STACK_TEXT:  WARNING: Stack unwind information not available. Following frames may be wrong.b0562bc4 bd0a2e33 e37f8200 e37f8200 e4ae1c68 nv4_disp+0x90fd0b0562c3c bf8edd6b b0562cfc e2601714 e4ae1c58 nv4_disp+0x90e33b0562c74 bd009530 b0562cfc bf8ede06 e2601714 win32k!WatchdogDdDestroySurface+0x38b0562d30 bd00b3a4 e2601008 e4ae1c58 b0562d50 dxg!vDdDisableSurfaceObject+0x294b0562d54 8054161c e2601008 00000001 0012c518 dxg!DxDdDestroySurface+0x42b0562d54 7c90e4f4 e2601008 00000001 0012c518 nt!KiFastCallEntry+0xfc0012c518 00000000 00000000 00000000 00000000 0x7c90e4f4STACK_COMMAND:  kbFOLLOWUP_IP: nv4_disp+90fd0bd0a2fd0 39b8f8000000    cmp     dword ptr [eax+0F8h],ediSYMBOL_STACK_INDEX:  0SYMBOL_NAME:  nv4_disp+90fd0FOLLOWUP_NAME:  MachineOwnerMODULE_NAME: nv4_dispIMAGE_NAME:  nv4_disp.dllDEBUG_FLR_IMAGE_TIMESTAMP:  4e390d56FAILURE_BUCKET_ID:  0x8E_nv4_disp+90fd0BUCKET_ID:  0x8E_nv4_disp+90fd0Followup: MachineOwner

Answer 1

nv4_disp+90fd0
bd0a2fd0 39b8f8000000    cmp     dword ptr [eax+0F8h],edi

这是重要的部分。从这个角度来看，很可能 eax 无效，因此尝试访问无效的内存地址。

您需要做的是将nv4_disp.dll加载到IDA中(您可以获取免费版本)，检查IDA加载nv4_disp的镜像库并按'g'转到地址，尝试将90fd0添加到镜像库IDA正在使用，它应该直接将您带到有问题的指令(取决于章节结构)。

从这里您可以分析控制流，以及如何设置和使用 eax。如果您有一个好的内核级调试器，您可以在此地址上设置一个断点并尝试使其命中。

分析该函数时，您应该尝试找出该函数的作用、eax 在该点上指向的内容、它实际指向的内容以及原因。这是最难的部分，也是逆向工程难度和技巧的很大一部分。