c – 在没有源代码的情况下调试/绕过BSOD

需要一点帮助：

情况：
我有一个模糊的DirectX 9应用程序(名称和应用程序的详细信息与问题无关),导致所有nvidia卡(GeForce 8400GS及以上)的蓝屏死机,因为某些驱动程序版本.我认为问题是由DirectX 9调用或触发驱动程序错误的标志间接引起的.

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

问题：

>没有可用的源代码或技术支持.没有任何帮助,没有其他人会解决问题.
>内核生成的内存转储没有帮助 – 显然在nv4_disp.dll中发生了访问冲突,但我无法使用stacktrace转到IDirect3DDevice9方法调用,而且有可能异步发生错误.
>(主要问题)由于大量的Direct3D9Device方法调用,我无法将它们可靠地记录到文件或网络中：

>即使没有刷新,登录到文件也会导致显着减速,因此系统BSOD会丢失日志的所有最后内容.
>通过网络登录(使用UDP和WINSOck的sendto)也会导致显着的减速,并且不能异步完成(异步数据包在BSOD上丢失),即使同步发送,数据包(崩溃周围的数据包)有时也会丢失.
>当应用程序通过记录例程“减慢”时,BSOD不太可能发生,这使得跟踪它变得更难.

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

Minidump分析(WinDBG)：

Loading User Symbols
Loading 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 pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003.  This means a hard
coded breakpoint or assertion was hit,but this system was booted
/NODEBUG.  This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code,but ...
If this happens,make sure a debugger gets connected,and the
system is booted /DEBUG.  This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005,The exception code that was not handled
Arg2: bd0a2fd0,The address that the exception occurred at
Arg3: b0562b40,Trap Frame
Arg4: 00000000

Debugging 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+90fd0
bd0a2fd0 39b8f8000000    cmp     dword ptr [eax+0F8h],edi

TRAP_FRAME:  b0562b40 -- (.trap 0xffffffffb0562b40)
ErrCode = 00000000
eax=00000808 ebx=e37f8200 ecx=e4ae1c68 edx=e37f8328 esi=e37f8400 edi=00000000
eip=bd0a2fd0 esp=b0562bb4 ebp=e37e09c0 iopl=0         nv up ei pl nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202
nv4_disp+0x90fd0:
bd0a2fd0 39b8f8000000    cmp     dword ptr [eax+0F8h],edi ds:0023:00000900=????????
Resetting default scope

CUSTOMER_CRASH_COUNT:  3

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x8E

LAST_CONTROL_TRANSFER:  from bd0a2e33 to bd0a2fd0

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
b0562bc4 bd0a2e33 e37f8200 e37f8200 e4ae1c68 nv4_disp+0x90fd0
b0562c3c bf8edd6b b0562cfc e2601714 e4ae1c58 nv4_disp+0x90e33
b0562c74 bd009530 b0562cfc bf8ede06 e2601714 win32k!WatchdogDdDestroySurface+0x38
b0562d30 bd00b3a4 e2601008 e4ae1c58 b0562d50 dxg!vDdDisableSurfaceObject+0x294
b0562d54 8054161c e2601008 00000001 0012c518 dxg!DxDdDestroySurface+0x42
b0562d54 7c90e4f4 e2601008 00000001 0012c518 nt!KiFastCallEntry+0xfc
0012c518 00000000 00000000 00000000 00000000 0x7c90e4f4


STACK_COMMAND:  kb

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

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nv4_disp+90fd0

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nv4_disp

IMAGE_NAME:  nv4_disp.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  4e390d56

FAILURE_BUCKET_ID:  0x8E_nv4_disp+90fd0

BUCKET_ID:  0x8E_nv4_disp+90fd0

Followup: MachineOwner