4

我的程序中出现了一个 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 错误发生位置的任何想法？

4

3 回答 3

13

您面临的问题是该进程是 32 位的，但您在 64 位上运行，因此您的转储是 64 位转储。要使用转储，您必须运行以下命令：

.load wow64exts
.effmach x86
!analyze -v

最后一个命令应该给你一个有意义的堆栈跟踪。

于 2011-11-19T20:26:03.050 回答
1

此页面提供了许多有用的信息和方法来分析问题。 http://www.dumpanalysis.org/blog/index.php/2007/09/11/crash-dump-analysis-patterns-part-26/

于 2012-01-17T02:26:03.693 回答
0

您没有提到您的代码是托管的还是非托管的。假设它是不受管理的。在调试器中：

.symfix
.reload
~*kb

查看所有线程的调用堆栈并识别导致 SO 的线程。用 SO 很容易识别线程，因为调用堆栈会特别长。使用 command 切换到该线程~<N>s，其中是线程号，使用 command 转储更多调用堆栈k 200以转储多达 200 行的调用堆栈。在调用堆栈的最底部，您应该能够看到生成嵌套循环的代码。

如果您的代码是托管的，请使用SOS扩展转储调用堆栈。

于 2011-11-17T15:02:50.427 回答