无法读取 Windbg 中的故障转储
我的程序中出现了 stackoverflow 异常，该异常可能源自第三方库 microsoft.sharepoint.client.runtime.dll。
使用 adplus 创建故障转储，我面临的问题是，当我在 Windbg 中打开它时，我很难从中获取任何信息。这是我得到的回复：
> 0:000> .restart /f
Loading Dump File [C:\symbols\FULLDUMP_FirstChance_epr_Process_Shut_Down_DocumentumMigrator.exe__0234_2011-11-17_15-19-59-426_0d80.dmp]
User Mini Dump File with Full Memory: Only application data is available
Comment: 'FirstChance_epr_Process_Shut_Down'
Symbol search path is: C:\symbols
Executable search path is:
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Machine Name:
Debug session time: Thu Nov 17 15:19:59.000 2011 (UTC + 2:00)
System Uptime: 2 days 2:44:48.177
Process Uptime: 0 days 0:13:05.000
.........................................WARNING: rsaenh overlaps cryptsp
.................WARNING: rasman overlaps apphelp
......
..WARNING: webio overlaps winhttp
.WARNING: credssp overlaps mswsock
.WARNING: IPHLPAPI overlaps mswsock
.WARNING: winnsi overlaps mswsock
............
wow64cpu!CpupSyscallStub+0x9:
00000000`74e42e09 c3 ret
关于如何从转储中获取更多信息，或者如何使用它来查找发生 stackoverflow 错误的位置，有什么想法吗？
I have been getting a stackoverflow exception in my program which may be originating from a thirdparty libary, microsoft.sharepoint.client.runtime.dll.
Using adplus to create the crash dump, I'm facing the problem that I'm struggling to get any information from it when i open it in windbg. This is what I get as a response:
> 0:000> .restart /f
Loading Dump File [C:\symbols\FULLDUMP_FirstChance_epr_Process_Shut_Down_DocumentumMigrator.exe__0234_2011-11-17_15-19-59-426_0d80.dmp]
User Mini Dump File with Full Memory: Only application data is available
Comment: 'FirstChance_epr_Process_Shut_Down'
Symbol search path is: C:\symbols
Executable search path is:
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Machine Name:
Debug session time: Thu Nov 17 15:19:59.000 2011 (UTC + 2:00)
System Uptime: 2 days 2:44:48.177
Process Uptime: 0 days 0:13:05.000
.........................................WARNING: rsaenh overlaps cryptsp
.................WARNING: rasman overlaps apphelp
......
..WARNING: webio overlaps winhttp
.WARNING: credssp overlaps mswsock
.WARNING: IPHLPAPI overlaps mswsock
.WARNING: winnsi overlaps mswsock
............
wow64cpu!CpupSyscallStub+0x9:
00000000`74e42e09 c3 ret
Any ideas as to how i can get more information from the dump, or how to use it to find where my stackoverflow error is occuring?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您面临的问题是该进程是 32 位的，但您正在 64 位上运行，因此您的转储是 64 位转储。要使用转储，您必须运行以下命令：
最后一个命令应该为您提供有意义的堆栈跟踪。
The problem you are facing is that the process is 32-bit, but you are running on 64-bit, therefore your dump is a 64-bit dump. To make use of the dump you have to run the following commands:
The last command should give you a meaningful stack trace.
该页面提供了大量有用的信息和分析问题的方法。
http:// www.dumpanalysis.org/blog/index.php/2007/09/11/crash-dump-analysis-patterns-part-26/
This page provides lots of useful information and method to analyze the problem.
http://www.dumpanalysis.org/blog/index.php/2007/09/11/crash-dump-analysis-patterns-part-26/
您没有提到您的代码是托管还是非托管。假设它不受管理。在调试器中：
查看所有线程的调用堆栈并识别导致 SO 的线程。用SO很容易识别线程，因为调用堆栈会特别长。使用命令
~s 切换到该线程，其中 是线程号，使用命令k 200转储更多调用堆栈，最多转储 200 行调用堆。在调用堆栈的最底部，您应该能够看到发起嵌套循环的代码。如果您的代码是托管的，请使用 SOS 扩展来转储调用堆栈。
You didn't mention if your code is managed or unmanaged. Assuming it is unmanaged. In debugger:
Look through the call stack for all threads and identify thread that caused SO. It is easy to identify the thread with SO, because the call stack will be extra long. Switch to that thread using command
~<N>s, where is thread number, dump more of the call stack using commandk 200to dump up to 200 lines of call stack. At the very bottom of the call stack you should be able to see the code that originated the nested loop.If your code is managed, use SOS extension to dump call stacks.