3

何百人ものユーザーがいる 2 年前の C++/Win32 プログラムがあります。数日前、あるユーザーが次のクラッシュを報告しました。プログラムがユーザー入力を受け取る前に、起動時に発生しています。他の誰もこの問題を抱えていません。

問題の署名:
問題イベント名
: APPCRASH アプリケーション名: xyz.exe
アプリケーション バージョン: 0.0.2.94
アプリケーション タイムスタンプ: 50b92e99
障害モジュール名: StackHash_dec5
障害モジュール バージョン: 6.0.6002.18541
障害モジュール タイムスタンプ: 4ec3e39f
例外コード: c0000374
例外オフセット: 000abc4f
OSバージョン: 6.0.6002.2.2.0.768.3
ロケール ID: 1033
追加情報 1: dec5
追加情報 2: cef9e6e9412cee8472af82d5cdb064b7
追加情報 3: 5d30
追加情報 4: 7ad67f8281216f819f54c76815aefb56

プログラムは SetUnhandledExceptionFilter ハンドラーを使用してミニダンプを書き込みますが、ユーザーはミニダンプがないと言います。コードc0000374(ヒープの破損)なので、それは正常だと思います。

ユーザーが問題を報告した後、メッセージ ポンプを通過するすべてのメッセージをログに記録するなど、膨大な数のトレース ステートメントを含む特別なビルドをユーザーに提供しましたが、そこからわかったのは、GetMessage が最後に受信したメッセージは、私が作成した新しいメッセージだったということだけです。その特別なビルドをデバッグの一部として入れます。そのメッセージとそれが呼び出すコードは、彼のクラッシュが始まった後に追加したため、クラッシュの原因になることはありません。これは、メッセージを処理するスレッドではなく、他のスレッドでクラッシュが発生していることを意味している可能性があります。プログラムは、起動時に一連のスレッドを作成します。

これをデバッグするための戦略を提案できる人はいますか? .dmp ファイルがないと困ります。

4

1 に答える 1

2

アプリケーションがクラッシュしてすぐに終了しない限り、つまりプロセスがまだ存在している限り、sysinternals(http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx)によるprocdumpprocdump -ma xxxx.exeをフルメモリダンプを書き込み、WinDbgで分析できます。

于 2012-12-02T21:36:30.800 に答える