問題タブ [procdump]

Windowsサービスのダンプを取得するためにProcDumpを使用することが可能かどうか/方法を知っている人はいますか? 実行したいコマンドは次のようなものです。

ただし、コマンドラインまたはデバッガーからサービスを開始できませんというメッセージが表示されます。これを回避する方法があるかどうか誰かが知っていますか?

また投稿: http://forum.sysinternals.com/problem-launching-procdump-from-a-64bit-service_topic27425.html

顧客サイトで同じ実行可能ファイルを使用して複数のサービスを実行できる可能性があります。プログラムに「Procdump を有効にする」設定を追加し、お客様に procdump をダウンロードして bin ディレクトリに配置するように指示しています。

設定がオンの場合、サービスの起動時に (プロセス ID を指定して) procdump を起動します。

問題は次のとおりです。「ローカル サービス」または「ローカル システム」として実行している場合、procdump は 64 ビット サーバーでは機能しません。管理者権限を持つドメイン ユーザーとして実行すると、正常に動作します。コマンドプロンプトから手動で起動しても問題なく動作します。手動で実行すると、タスク マネージャーに procdump *32 と procdump64 という 2 つの procdump プロセスが作成されているように見えます。

64 ビット サービスが「ローカル サービス」または「ローカル システム」として実行されている場合、procdump を起動すると、procdump*32 のみが表示されます。procdump64 を起動するはずの方法が失敗していると想定しています。 また、ダンプの作成に失敗し、サービスをタスクキルすると終了に失敗します (通常は終了します)。

これがなぜなのか、またはそれについて私にできることがあれば何か考えはありますか? procdump を実行しているアカウントに必要な権限はありますか?

ここに ProcDump チュートリアルがあります: http://drdobbs.com/blogs/parallel/229300328

クラッシュするアプリケーションがあるので、ProcDump が役立つかどうかを確認したいと考えています。アプリケーションが入ってC:\Program Files\MyCompanyName\thebadapp.exeいるので、ProdCump.exe を C:\ にコピーして、次のように開きました。

...しかし、Prodcump が返されます:

ディレクトリ C:\Files\MyCompanyName\ が存在しません

私が間違っているのは何ですか？

ありがとう。

Cygwinにはプログラムが含まれていますdumper.exe

ダンパーユーティリティを使用して、実行中のWindowsプロセスのコアダンプを作成できます。

ただし、Cygwinプロセスでのみ機能するようです

しばらくProcDumpを使用していますが、Cygwinパッケージに含まれているプログラムに移動したいと思います。

ProcDumpで作成したクラッシュダンプから意味のある情報を取得するのに苦労していますが、それは私が経験している一見ランダムなクラッシュに関連していると確信しています。

Windows764ビットで実行されているVB6アプリケーションがあります。ときどきクラッシュし、エラーログにntdll.dllの障害となるエントリが残りますが、それ以上の情報は提供されません。そのため、SysInternalsのProcDumpを実行してプロセスを実行し、クラッシュダンプを自動的に作成しました。

クラッシュを社内で再現することができなかったので、ダンプがあったとしても、問題が何であるかを教えてくれると確信していました。ただし、1日のほとんどを実行した後、プログラムはまだ正常に実行されていますが、ProcDumpはすでにいくつかのダンプを書き込んでいることがわかります。ntdll.dllの問題を指摘しているようですが、どこから修正を適用すればよいかわかりません。

ダンプの1つで実行!analyze -vすると、次のようになります。

このエントリの意味を理解するという観点から、誰かが私を正しい方向に向けることができますか、そしてそれについて私は何ができますか？

質問は少し厄介かもしれませんが、ここに私の詳細な問題があります：

現在、SysInternals の procdump.exeをセットアップして、偽の消失を示すアプリケーションを監視するように検討しています。つまり、ユーザーは、アプリケーションの短い目に見えるハングの後、アプリケーションがトレースなしで単に「なくなった」と報告しています。窓。

私の最初のアイデアはprocdump -e -x . MyApp.exe、アプリケーションが未処理の例外に遭遇したときにクラッシュ ダンプを記録する実行することでしたが、その後、-tスイッチもあることがわかりました。

-t - プロセスの終了時にダンプを書き込みます。

プロセスが終了すると、自動的にダンプが生成されます。

今問題

-t スイッチをトリガーできる定義済みの場所にExitProcessor呼び出しを挿入して、アプリでスイッチをテストしました。TerminateProcess

アプリは期待どおりに動作しますが、つまりTerminateProcess、実行中のアプリをすぐに「強制終了」し、ExitProcessグローバル クリーンアップが実行されるためしばらく時間がかかりますが、この方法で生成されたダンプはどちらの場合も役に立ちません。

私が取得するダンプには、-t常に単一のスレッド (アプリケーションが終了時に 20 を超えるスレッドを実行していた場所) のみが含まれており、コールスタックは有用な場所にさえありません。(終了したアプリからの 1 つのランダムなスレッドのようです。)

私は何か間違ったことをしていますか？procdump -tプロセス終了関数の予期しない呼び出しを追跡するために使用できますか?

ProcDump が間違ったスレッドの事後分析ダンプをダンプしているように見えます。ProcDump を JIT デバッガーにしました。

テスト プログラム C++ MFC を作成しました。

(ProcDumpTest.exe プログラムの) メニューから [クラッシュ] 項目を選択すると、アプリケーションがクラッシュし、ダンプが作成されます。ただし、ダンプには、予期しないスレッドのスタックと命令ポインター (eip = 7c90e514) が (windbg) 表示されます。エラーが発生したスレッドのスタック トレースを取得するには?

より深刻なケースで同じ問題が発生しました。助けてくれてありがとう！Gさらに表示

CPUが断続的にスパイクする原因となるWebサイトの問題のトラブルシューティングを試みています。このサイトはWebサーバーのファーム上にあり、すべてのサーバーで異なる時間に断続的に発生します。スパイクを引き起こすプロセスはw3wp.exeです。私はすべての明白なことをチェックしました、そして今スパイクを引き起こすw3wp.exeのためにダンプファイルの複数のセットを分析したいと思います。

指定された時間に指定されたCPUしきい値に達したときに、w3wp.exeプロセスのダンプファイルを自動的に生成しようとしています。

ProcDump.exeを使用してこれを行うことができ、PID（プロセスID）が変更される前に起動された場合は処理されます。

例: procdump -ma -c 80 -s 10 -n 2 5844(5844はPIDです）

• -maすべてのプロセスメモリを含むダンプファイルを書き込みます。デフォルトのダンプ形式には、スレッドとハンドルの情報が含まれています。
• -cプロセスのダンプを作成するCPUしきい値。
• -sダンプが書き込まれる前にCPUしきい値に到達する必要がある連続秒数（デフォルトは10）。
• -n終了する前に書き込むダンプの数。

上記のコマンドは、CPUが10秒間80％スパイクするまで、w3wp.exeを監視し、少なくとも2回の反復で完全なダンプを取ります。

問題：

w3wp.exeの複数のインスタンスを実行しているため、プロセス名を使用できません。PIDを指定する必要があります。PIDは、アプリプールがリサイクルされるたびに変更されます。これにより、複数のダンプファイルをキャプチャする前にPIDが変更されます。次に、各Webサーバーでprocdumpを再度開始する必要があります。

私の質問：

PIDが変更された後でも、ダンプファイルを自動的に生成し続けるにはどうすればよいですか？

I have to catch crashes of particular application on ARM devices. procdump works fine for x86 and x64 archs, but doesn't run on ARM. Any pointers ?

デバッグに役立つように、自分のアプリケーション (フレームワーク .NET 4.0 に対してコンパイルされた VB.NET) 自体のプロセス ダンプを書き込もうとしています。このために、Sysinternals の Procdump を使用しています。

開始するには、クリック イベントで次のコードを実行するだけです (したがって、コール スタックで何か認識できるはずです)。

最後の行にもブレークポイントがあります。

ダンプを作成するには、VS 2010 内でアプリケーションをデバッグ モードで起動し、ボタンをクリックしてこのコードを実行します。ブレークポイントに到達すると、ダンプが書き込まれたことがわかります。この時点で、Visual Studio を使用して別のダンプ ファイルも作成します ([デバッグ] -> [ダンプを名前を付けて保存])。

これにより、Procdump.exe によって作成されたものと Visual Studio によって作成されたものの、ほぼ同じサイズ (400 メガバイト) の 2 つのダンプ ファイルが残ります。ビルドされたコードには何も触れずに、両方のダンプ ファイルを開き (ビルドされたコードを開いた状態で Ctrl+O を押します)、シンボル フォルダー オプションでデバッグ出力フォルダーを指定します。

ここで、Visual Studio によって作成されたダンプで [混合でデバッグ] をクリックすると、(メイン スレッドで) 認識可能なメソッド名を含むコール スタックが取得され、デバッガーはそれをソース コード内のブレークポイントのある位置に適切に配置します。だった。

ただし、Procdump によって作成されたダンプで [混合でデバッグ] をクリックすると、(メイン スレッドの) コール スタックには clr.dll!6cb34e46()、KERNELBASE.dll!75106a8e() と ntdll.dll! のようなものしか含まれません。上部に 76f07094() があります。認識可能なコードはなく、時計に関連するものもありません。

何故ですか？ 実際、私はこれら 2 つのダンプがほぼ等しいことを期待していました (数行のコードが異なるだけです)。 [アタッチされているデバッガーと関係があります。以下の編集を参照してください。]

どちらの場合も、シンボルが正しく読み込まれたことに注意してください。Debug->Windows->Modules で取得したリストは、両方のダンプに同じシンボルがロードされることを示しています。さらに、両方のダンプでバックグラウンド スレッドに切り替えると、両方のダンプでこれらの (変数の値などを含む) の正しいコール スタックが取得されます。

編集

デバッガーを接続せずにアプリケーションを実行すると、予想されるプロセス ダンプが得られることに気付きました (つまり、Visual Studio によってキャプチャされたものと同じですが、1 行ずれています)。問題が解決しました。しかし、デバッガーを接続した状態でなぜその結果が得られなかったのかについては、まだ興味があります。