問題タブ [crash-dumps]

アプリから印刷ボタンを 2 回クリックすると、IE 6.0 がクラッシュします。

再現手順: 1) 印刷ボタンをクリックし、印刷ダイアログをキャンセルします。2) もう一度印刷をクリックします。IE 6.0 がクラッシュします。

IE 7 & 8 では正常に動作します。

以下は、WinDbg から取得したスタック トレースです。

Windows Vista で windbg 6.12.0002.633 X86 を使用して、メモリ リークのメモリ ダンプを分析しています。コマンド「dumpheap -stat to determine the quantities of objects in the heap. Unfortunately, I'm getting the error*** エラー: シンボル ファイルが見つかりませんでした。」を使用しようとしています。SLC.dll のシンボルをエクスポートするようにデフォルト設定されています. I have activated!sym ノイズが多いto show where the error comes from and the file SLC.pdb is just not available on the symbol server. I have googled the file but haven't found such a downloadable file. The last line in the log output says:「mpheap -stat」` でエラーを解決できませんでした。このエラーが永続的に発生しているため、デバッグを続行できません。

SLC.pdb ファイルを入手できる場所や、この問題を回避する別の方法を知っている人はいますか?

ProcDumpと同様にアプリケーションでミニダンプ ファイルを生成する方法を探していますが、できればコードを使用し、それを行うために 3dparty ツールを抽出する必要はありません。

ProcDumpを使用したくない主な理由は次のとおりです
。1) バイナリのサイズが大幅に増加します (私のアプリはフリーウェアであり、帯域幅は無料ではないため、これは問題です)。
2) 汚いと感じる。
3) そのアプリを inn windows mobile に移植することはできません。

私の要件は次のとおりです
。1) 致命的なクラッシュで mdump ファイルを生成する機能。
2）アプリを「一時停止」してダンプを実行する機能、および続行がボーナスになり
ます。
これが本当にオプションでない場合、現在のコンテキストでローカル変数の値を動的に取得する方法はありますか?

補足: 私はこの記事を見つけましたが、非常に古いので、私の仕事のベースにするのをためらっています.
IE 9 またはサイトに問題があるようで、タグに問題がありました。

ユーザーのコンピューターでときどきクラッシュする Windows C++ アプリがあります。私はアプリを作成しませんでしたし、独自のログもありません。アプリケーションの終了時に有用な情報 (クラッシュが発生したファイルと行番号など) をログに記録できるツール/ユーティリティはありますか? エンド ユーザーのコンポーネントには Visual Studio がありません。

あなたへの簡単な質問。

アプリがクラッシュログを定期的にチェックしてサーバーにアップロードする場合、Appstoreの承認プロセスに問題はありますか？これも可能ですか？そうでない場合は、グローバル例外ハンドラーのようなものを使用して、サーバーに例外メッセージをアップロードしながら、アプリを正常に終了させることができますか？

ありがとう、
テジャ

最近クラッシュし始めた古いレガシー アプリで問題が発生しています。DebugDiag 分析を調査しようとしていますが、うまくいきません。ロックする SQL クエリがあり、呼び出し元のスレッドが消えませんか? 次に、コールスタックは再び oledb32!CImpIErrorInfo::GetHelpFile+a1 を指します。

この問題に関連すると思われるDebugDiagからの情報は次のとおりです。

w3wp.exe_ MyApp _PID_ 7572 _Date__10_21_2010__Time_08_43_22AM_ 720 _Manual Dump.dmp 内の次のスレッドは、ADO を使用してデータベース操作を行っています。

MSADO15!CERRORLOOKUP::GETHELPINFO への呼び出しは、oledb32!CImpIErrorInfo::GetHelpFile+a1 から発信されました。

...クリップ...クリップ...

スレッド 17 - システム ID 4160 エントリ ポイント msvcrt!_endthreadex+2f 作成時刻 21.10.2010 0:08:16 ユーザー モードで費やされた時間 0 日 00:11:22.781 カーネル モードで費やされた時間 0 日 00:27:49.953

このスレッドは、ADO を使用してデータベース操作を行っています。

MSADO15!CERRORLOOKUP::GETHELPINFO への呼び出しは、oledb32!CImpIErrorInfo::GetHelpFile+a1 から発信されました。

関数ソース ntdll!GetUILangID+31
ntdll!LdrpSearchResourceSection_U+186
ntdll!LdrFindResource_U+18
kernel32!FindResourceExW+65
user32!LoadStringOrError+31
user32!LoadStringW+18
msado15!FetchInfo+ba
msado15!CErrorLookup::GetHelpInfo+1e
oledb32!CImpIErrorInfo:: GetHelpFile+a1
msvbvm60!ExecProj::SetModuleCount+a
msvbvm60!CEcProjTypeComp::Release+4
msvbvm60!Rc​​mConstructModuleInstance+8f
oleaut32!DispCallFunc+16a
msvbvm60!VBStrToLong+cf
msvbvm60!FileOutString+bb
msvbvm60!_ vbaPrintObj+51
MSWCRUNllUnregisterer!
MSWCRUN!DllUnregisterDesigner+accb
MSWCRUN!DllUnregisterDesigner+af8c
MSWCRUN!DllUnregisterDesigner+a7de
MSWCRUN!DllUnregisterDesigner+7b51
MyApp!DllCanUnloadNow+212e
oleaut32!DispCallFunc+16a
msvbvm60!VBStrToLong+cf
msvbvm60!FileOutString+bb
msvbvm60! _vbaPrintObj+51
MSWCRUN!DllUnregisterDesigner+8ad3
MSWCRUN!DllUnregisterDesigner+7d13
MSWCRUN!DllUnregisterDesigner+6e64
MSWCRUN!DllUnregisterDesigner+9097
MSWCRUN!DllUnregisterDesigner+8fa6
vbscript!IDispatchInvoke2+b2
vbscript!IDispatchInvoke+59
vbscript!InvokeDispatchName!InvokeDispatch+ 12a
vb4
CScriptRuntime::RunNoEH+234c
vbscript!CScriptRuntime::Run+62
vbscript!CScriptEntryPoint::Call+51
vbscript!CSession::Execute+c8
vbscript!COleScript::ExecutePendingScripts+144
vbscript!COleScript::SetScriptState+14d
asp!CActiveScriptEngine::TryCall+19
asp!CActiveScriptEngine::Call+31
asp!CallScriptFunctionOfEngine+5b
asp!ExecuteRequest+17e
asp!Execute+24c
asp!CHitObj::ViperAsyncCallback+3f0
asp!CViperAsyncRequest::OnCall+92
comsvc​​s!CSTAActivityWork::STAActivityWorkHelper+32
ole32!EnterForCallback+c4
ole32!SwitchForCallback+1a3
ole32!PerformCallback+54
ole32!CObjectContext::InternalContextCallback +159
ole32!CObjectContext::DoCallback+1c
comsvc​​s!CSTAActivityWork::DoWork+12d
comsvc​​s!CSTAThread::DoWork+18
comsvc​​s!CSTAThread::ProcessQueueWork+37
comsvc​​s!CSTAThread::WorkerLoop+190
msvcrt!_endthreadex+a3
kernel32!BaseThreadStart+34

...クリップ...クリップ...

194.241.111.228:26238から 81.175.250.2:80 へのクライアント接続
ホスト ヘッダー 81.175.250.2:80 /MyApp/netk.asp に対する GET
要求
リクエストの状態 HTR_READING_CLIENT_REQUEST ネイティブのリクエストの状態 NREQ_STATE_PROCESS

最近、お客様から64ビットのクラッシュダンプを受け取りました。
プロセスはすべて32ビットですが、お客様のマシンはx64Server2008を実行しています。

Visual Studio（2008と2010 Expressの両方）から、64ビットバージョンを使用する必要があると言われましたMSVSMON.EXEが、64ビットマシンがないため使用できません。

WinDbgでこれを行う方法があると確信していますが、WinDbgは敵対的であることがわかりました。

できればVisualStudioを使用して、32ビットマシンで64ビットダンプをデバッグする方法はありますか？

私のアプリケーションがアクセスする必要のない多くのクライアントマシンで動作する場合、クライアントマシンでのバグ追跡の経験を知っている人を探しています。私のアプリケーションには非常に大きなデバッグ ロギング機能がありますが、多くの場合、これは非常に大きなログや読み取り不能なログがなければ、クラッシュの問題を適切に検出することができず、この種の問題を検出するために他の解決策を探しています。

ソフトウェアのクラッシュに関する情報を適切に転送するコードを開発したいと考えています。Developer マシンでは after crashVisual Studio JIT Debuggerを使用しますが、リモート オプションでは使用できません (私が思うに) クラッシュに関する情報をJITクラッシュ形式などで転送する良い方法はありますか?

純粋な管理されていないプロジェクトと個別C++に管理されているプロジェクトには、このソリューションが必要です。C#

こんにちは、良い答えをありがとう。

現在、別のプロセスからクラッシュしたプロセスのメモリ ダンプを取得できるメモリ ダンプ ツールを設計しようとしています。しかし、私はこれにまったく慣れていないので、これを機会として、メモリ ダンプの手法をしっかりと理解したいと思います。

クラッシュしたプロセスのメモリ ダンプを作成する作業パラダイムを知りたいです。私の現在の野生の想像力は以下のようなものです：

プロセスがクラッシュすると、オペレーティング システムは常にそれを認識します (方法はわかりませんが、できるはずです)。その後、OS は何らかのメカニズムを起動して、クラッシュしたプロセスの仮想アドレス空間の内容をいわゆるダンプ ファイルにコピーしました。次に、WinDbg を使用してダンプ ファイルをデバッグできます。

クラッシュしたプロセスの仮想アドレス空間全体をダンプ ファイルにコピーできるとしたら、ファイルが大きすぎないのでしょうか。または、ダンプする仮想アドレス空間 (カーネル/ユーザー) を指定できますか?

特に次の側面について、私が最初に始めるための参考文献を誰かに提供してもらえますか。

1. メモリダンプとは？

2. いわゆるカーネル ダンプとユーザー モード ダンプがある場合、それらは何ですか?

3. Windows プラットフォームでは、どの API が必要ですか? MiniDumpWriteDump()などの関数は関係がありますか?

4. OS が特定のプロセスのクラッシュを検出した場合、ダンプ ツールにダンプの開始を通知するために監視できる信号はありますか?

私の言葉を見てくれてありがとう。

追加1:

(5) ミニダンプとは? カーネル/ユーザー モードのダンプとの関係は?

(6)メモリダンプについて話すとき、どのメモリについて話しているのですか? 仮想メモリまたは物理メモリ? この写真から、物理メモリだと思います。

ADD2:

DbgHelp.dll に含まれる API を使用した MiniDump の記述に関する参考文献を見つけました。シェアしたいと思います。これに関連する他の優れた資料を提供できる場合は、共有していただけませんか? ありがとう。

（ところで：私はこのスレッドを自分の進捗状況で更新し続けます。コメントをいただければ幸いです。）

MiniDumpWriteDump()メソッドを使用してミニダンプを作成する方法を研究しています。いくつかの記事を読んだ後、私にできることは、ダンプしたいものを OS に伝えるためのコールバック関数とさまざまなフラグを提供することだけだと感じました。その後、OS はコール スタックなどのさまざまな情報をダンプ ファイルに収集します。

でも、これだけでいいの？私はいわゆる API を使いたくありません。海ではなく、バスタブで泳いでいるような気分になります。コンピュータのメモリを自由に調べる方法はありますか? 誰かがそれを達成するための参照を提供できますか?

どうもありがとう。