4

私のプログラムで、サードパーティ ライブラリの 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

ダンプからより多くの情報を取得する方法、またはそれを使用してスタックオーバーフロー エラーが発生している場所を見つける方法についてのアイデアはありますか?

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を使用してスレッドを簡単に識別できます。コマンドを使用してそのスレッドに切り替えます~<N>s。ここで、はスレッド番号です。コマンドk 200を使用してさらに多くの呼び出しスタックをダンプし、最大200行の呼び出しスタックをダンプします。呼び出しスタックの一番下に、ネストされたループを発生させたコードが表示されるはずです。

コードが管理されている場合は、SOS拡張機能を使用してコールスタックをダンプします。

于 2011-11-17T15:02:50.427 に答える