3

私は、かなり広く展開されている .NET 2.0 Winforms アプリケーションをサポートしています。まれに、アプリケーションを起動しようとするとすぐにアプリケーションが .NET ランタイム例外を返すお客様からサポートの電話を受けることがあります。

過去に、お客様が .net フレームワークを再インストールするのを手伝いましたが、たいていはうまくいきますが、うまくいかないこともあります。

このような状況では、Windows Debugging Toolsを使用して問題の原因を特定できます。その場合、デバッグ シンボルをターゲット コンピューターにダウンロードする必要があります (ターゲットにダウンロードするのに数百 MB のデータをダウンロードする可能性があるため、避けたいと思います)。

これは .net アプリにとってやり過ぎですか? 任意の代替。これをどのようにデバッグしますか。非具体的なステップバイステップをいただければ幸いです。もちろん、このアプリはターゲット マシンで RELEASE 構成としてコンパイルされます。お客様は開発ツールやデバッグ ツールをインストールしていない可能性が非常に高いです。私たちは通常、コンピュータへのリモート コントロール アクセスを持っています。繰り返します。これは、顧客がアプリケーションを実行しようとするとすぐに発生し、すぐに失敗します。

お客様にとってこの問題を解決するための最も簡単な方法は何ですか?

イベント ログからの最近のエラーの例を次に示します。
イベント タイプ clr20r3。.exe P2 2010.1.0.0、p3 4B857AFD P4 BLAH BLAH system.invalidoperation、P10 NIL。

ソース: .NET ランタイム 2.0 エラー。イベント ID: 5000

前もって感謝します。

セス

4

4 に答える 4

6

なぜそれを使用しないのですか？

お客様のマシンの場合、リモート デバッグを行うことはできません。したがって、クラッシュの場合はクラッシュ ダンプをキャプチャし、ハングの問題の場合はハング ダンプをキャプチャすることをお勧めします。ここでは、WinDbg または ADPlus.exe が非常に役立ちます。

WinDbg でアプリケーションを起動し、実行するようにエンド ユーザーに依頼します。

.dump /f path

クラッシュ ダンプを保存するには、ダンプ ファイルを要求してクラッシュを分析します。

ターゲット マシンでは、シンボルは必要ありません。シンボルは、自分のマシンでクラッシュ ダンプを分析する場合に役立ちます。SOS などは、そのような場合に役立ちます。

もちろん、クラッシュ ダンプを取得する方法は他にもありますが、

http://blogs.msdn.com/lexli/archive/2009/08/23/when-the-application-program-crashes-on-windows.aspx

于 2010-03-06T09:45:34.080 に答える
2

編集：「起動時にすぐに発生する」を見ただけです。実際、WinDBG が役に立ちます。

Windows 用デバッグ ツールは主にネイティブ アプリケーション向けですが、マネージ アプリケーションにも役立ちます。マネージド アプリは、実行時に最終的に「ネイティブ」になるだけでなく、特にWinDBG または CDB 用のSOS 拡張機能もあります (コマンド ラインを使用する場合)。

特に、クラッシュしたアプリケーションの (ミニ) ダンプは、SOS 拡張機能を使用して非常にうまく分析できます。アプリケーションがリリース モードまたはデバッグ モードでコンパイルされているかどうかは、ダンプを分析するときに一致するシンボル ファイル (.PDB) が手元にある限り、それほど重要ではありません。

世の中にはたくさんの情報があり、この回答で話すことはたくさんありますが、最善の策は「windbg sos」を検索することです。

あなたが挙げた例について

イベント タイプ clr20r3。.exe P2 2010.1.0.0、p3 4B857AFD P4 BLAH BLAH system.invalidoperation、P10 NIL。

他の何かかもしれませんが、私には、.NET アプリケーションでキャッチされていない例外のように見えます。この場合は System.InvalidOperationException です。

クラッシュしたアプリケーションのミニダンプを取得できる場合 ( 「オンデマンド」または「イベント時に」ダンプを取得するためのデバッグ ツールの一部であるADPlusツールを調べる)、それを WinDBG に読み込んで SOS 拡張機能を使用できます。 (コマンド !clrstack、!dumpstack、!threads など) を使用して、キャッチされなかった例外がどこから来たのかを突き止めます。

于 2010-03-06T09:38:18.230 に答える
0

役立つURLとともに、ステップバイステップの説明を含むブログ投稿を作成しました。

http://www.spearsofttech.com/2010/03/09/how-to-use-debugging-tools-for-windows-to-debug-a-net-application/

セス

于 2010-03-09T19:59:31.010 に答える
0

「Windows Debugging Tools」は必要ないと思います。デバッグ シンボルは、.NET Framework ではなく、OS 用です。(Windows.Forms アプリケーションは、OS ではなく .NET Framework に存在することに注意してください。)

http://msdn.microsoft.com/en-us/library/y7f5zaaa.aspxの「リモート デバッグ」は役に立ちますか?

通常は「StopSwitch」を含めますが、これは JIT を有効にするための要件ではありません。( http://missico.spaces.live.com/blog/cns!7178D2C79BA0A7E3!309.entryの「StopSwitch による Just-In-Time デバッグの実行の停止」を参照) これにより、スイッチを有効にして、実行中のアプリケーションにアタッチできます。デバッガーの停止ステートメントにヒットしたとき。

「リリース」ビルドをデバッグできます。リリース pdb は、スタック トレースに役立ちます。

以前にこの問題がありました。StopSwitch を有効にすると、最初の行でチェックが行われましたが、.NET Framework がアプリケーションをロードする前に問題が発生したため、JIT は起動しませんでした。

于 2010-03-05T22:38:49.020 に答える