我的堆栈中有WerpReportFault()
的崩溃转储,它们看起来并不像我期望的那样。
如果看到WerpReportFault()
和0x80000003断点,我可以使用WinDbg重新转储不同的异常指针,取自传递给WerpReportFault()
的第二个参数。
我非常确定之前已经有效,因为我甚至在my answer over there中建议这样做。还有其他网站暗示这种技术,例如, James Ross
我正在分析的转储内部有一个“普通例外”,例如访问冲突:
0:000> .exr -1
ExceptionAddress: 53ec8b55
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 53ec8b55
Attempt to read from address 53ec8b55
但他们仍然有WerpReportFault()
作为堆栈:
0:000> k
ChildEBP RetAddr
0018f25c 74c4171a ntdll!NtWaitForMultipleObjects+0x15
0018f2f8 75181a08 KERNELBASE!WaitForMultipleObjectsEx+0x100
0018f340 75184200 kernel32!WaitForMultipleObjectsExImplementation+0xe0
0018f35c 751a80ec kernel32!WaitForMultipleObjects+0x18
0018f3c8 751a7fab kernel32!WerpReportFaultInternal+0x186
0018f3dc 751a78a0 kernel32!WerpReportFault+0x70
0018f3ec 751a781f kernel32!BasepReportFault+0x20
0018f478 7295fa2e kernel32!UnhandledExceptionFilter+0x1af
参数2似乎不是在.dump
命令中使用的好异常指针。
0:000> kb
ChildEBP RetAddr Args to Child
[...]
0018f3dc 751a78a0 0018f4a0 00000001 0018f478 kernel32!WerpReportFault+0x70
[...]
是什么导致了我遇到的问题以及如何解决这个问题?我知道它一定是可能的,因为!analyze -v
可以告诉我真正的调用堆栈。
是由于Visual Basic 6和未处理的异常过滤器吗?
0018f478 7295fa2e 00000000 72a2bd04 0018f4a8 kernel32!UnhandledExceptionFilter+0x1af
0018ff80 00440fe2 00443860 7518338a 7efde000 msvbvm60!Zombie_Release+0x10fd5
我真的希望有一个很好的调用堆栈,因为我的所有手动调试和我的所有脚本都被破坏了,这依赖于k
和!clrstack
等。他们无法处理堆栈上的WerpReportFault()
。
所有转储都是32位,你可以想象从VB6依赖。
答案 0 :(得分:1)
这样的问题是由错误的背景引起的。它似乎设置为正常的上下文记录。要将其设置为异常上下文,请使用.ecxr
。要切换回正常情境(您看到),请使用.cxr