从 Visual C++ 了解故障转储应用程序
更新
感谢下面的反馈，我能够找到 ADPlus.vbs，它是 Windows 调试工具的一部分。
不要忘记在运行之前设置 _NT_SYMBOL_PATH。
与使用应用程序崩溃时通过 Windows 生成的常规转储相比，使用此功能，我们能够更清楚地看到应用程序的内部情况。
非常感谢大家的回复。
原始问题
我们有一个用 Visual C++ 编写的服务器应用程序，有时（相对很少）会在客户站点上崩溃。根据查看我们自己的日志文件，我们无法理解为什么会发生这种情况，因此下一步是开始查看故障转储。
我们只是故意在我们的应用程序中放入一个错误（空指针），以便我们可以生成故障转储并验证生成的转储是否有价值，但到目前为止我无法弄清楚我正在做什么看到。
我想我的第一个问题是我是否正确设置了 WinDbg（这里的另一个开发人员正在将转储加载到 Visual Studio 2010 中并看到相同的错误，所以我假设它没问题，或者我们都错了： ) ) - 然后下一个问题是，我如何理解它告诉我的内容。
主要的困惑是转储似乎告诉我它已经达到了断点，这对我来说似乎很奇怪，因为没有连接调试器。
该应用程序崩溃时正在 Windows Server 2003 系统上运行。我相信我已经正确地将 WinDbg 指向 DLL 和 EXE 的 PDB 文件。
FAULTING_IP:
ntdll!DbgBreakPoint+0
7c81a3e1 cc int 3
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 7c81a3e1 (ntdll!DbgBreakPoint)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000000
Parameter[1]: 8779fdb0
Parameter[2]: 00000003
DEFAULT_BUCKET_ID: STATUS_BREAKPOINT
PROCESS_NAME: CallPlusServerLauncher.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid
EXCEPTION_PARAMETER1: 00000000
EXCEPTION_PARAMETER2: 8779fdb0
EXCEPTION_PARAMETER3: 00000003
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
ADDITIONAL_DEBUG_TEXT: Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[ffffffff]
FAULTING_THREAD: ffffffff
PRIMARY_PROBLEM_CLASS: STATUS_BREAKPOINT
BUGCHECK_STR: APPLICATION_FAULT_STATUS_BREAKPOINT
STACK_TEXT:
1bd0ffc8 7c83fe08 00000005 00000004 00000001 ntdll!DbgBreakPoint
1bd0fff4 00000000 00000000 00000000 00000000 ntdll!DbgUiRemoteBreakin+0x36
FOLLOWUP_IP:
ntdll!DbgBreakPoint+0
7c81a3e1 cc int 3
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: ntdll!DbgBreakPoint+0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: ntdll
IMAGE_NAME: ntdll.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 49900d60
STACK_COMMAND: ddS 1bd10000 1bd0c000 ; dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ~439s; .ecxr ; kb
BUCKET_ID: MANUAL_BREAKIN
FAILURE_BUCKET_ID: STATUS_BREAKPOINT_80000003_ntdll.dll!DbgBreakPoint
WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/CallPlusServerLauncher_exe/0_0_0_0/4df87414/ntdll_dll/5_2_3790_4455/49900d60/80000003/0001a3e1.htm?Retriage=1
Followup: MachineOwner
UPDATE
Thanks to feedback below I was able to home in on ADPlus.vbs, which is part of the debugging tools for Windows.
Don't forget to set up _NT_SYMBOL_PATH before you run it.
Using this we've been able to see much more clearly in to the application with far greater clarity than we ever have using the regular dumps produced via Windows when the application crashes.
Many thanks to all for the responses.
ORIGINAL QUESTION
We have an server application written in Visual C++ that some times (relatively rarely) crashes on customer sites. We haven't been able to understand why this happens based on looking at our own log files so the next step is to start looking at crash dumps.
We've just purposefully put a bug in to our app (a null pointer) so that we can generate a crash dump and verify that the dumps produced are valuable, but thus far I can't make head or tail of what i'm seeing.
I think my first question is whether i've even got WinDbg set up correctly (the other developer here is loading the dump in to Visual Studio 2010 and seeing the same errors so i'm assuming it's fine, or we're both wrong :) ) - and then next question is, how do I understand what it's telling me.
The main confusion is that the dump seems to be telling me it has reached a break point, which seems odd to me since there was no debugger connected.
The app was running on a Windows Server 2003 system when it crashed. I believe I have pointed WinDbg at the PDB file for the DLL and EXE correctly.
FAULTING_IP:
ntdll!DbgBreakPoint+0
7c81a3e1 cc int 3
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 7c81a3e1 (ntdll!DbgBreakPoint)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000000
Parameter[1]: 8779fdb0
Parameter[2]: 00000003
DEFAULT_BUCKET_ID: STATUS_BREAKPOINT
PROCESS_NAME: CallPlusServerLauncher.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid
EXCEPTION_PARAMETER1: 00000000
EXCEPTION_PARAMETER2: 8779fdb0
EXCEPTION_PARAMETER3: 00000003
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
ADDITIONAL_DEBUG_TEXT: Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[ffffffff]
FAULTING_THREAD: ffffffff
PRIMARY_PROBLEM_CLASS: STATUS_BREAKPOINT
BUGCHECK_STR: APPLICATION_FAULT_STATUS_BREAKPOINT
STACK_TEXT:
1bd0ffc8 7c83fe08 00000005 00000004 00000001 ntdll!DbgBreakPoint
1bd0fff4 00000000 00000000 00000000 00000000 ntdll!DbgUiRemoteBreakin+0x36
FOLLOWUP_IP:
ntdll!DbgBreakPoint+0
7c81a3e1 cc int 3
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: ntdll!DbgBreakPoint+0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: ntdll
IMAGE_NAME: ntdll.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 49900d60
STACK_COMMAND: ddS 1bd10000 1bd0c000 ; dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ~439s; .ecxr ; kb
BUCKET_ID: MANUAL_BREAKIN
FAILURE_BUCKET_ID: STATUS_BREAKPOINT_80000003_ntdll.dll!DbgBreakPoint
WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/CallPlusServerLauncher_exe/0_0_0_0/4df87414/ntdll_dll/5_2_3790_4455/49900d60/80000003/0001a3e1.htm?Retriage=1
Followup: MachineOwner
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
DbgBreakPoint——在我看来，您使用远程调试器中断了执行。
如果你没有，那么我已经看到当你打开代码页（编辑：我的意思是
页堆）时会出现DbgBreakPoint（你应该知道你是否这样做了）并且检测到无效内存访问。DbgBreakPoint -- Looks to me like you broke execution using a remote debugger.
If you didn't then I have seen DbgBreakPoint show up when you have code pages (Edit: I meant
page heap) turned on (you should know if you did this) and there was a detection of invalid memory access.断言还可以触发断点异常。例如，当堆因双重删除或溢出而损坏时，我（经常）看到它们从堆中出来，检查删除周围的情况。但我认为只有调试运行时，这就是您部署的吗？
Asserts can also trigger a breakpoint exception. For example I have (too often) seen them come out of the heap checking around a delete when the heap has got corrupted by double-delete or overflow. But only with the debug runtime I thought, is that what you have deployed?