2012-01-25 10 views
0

一部のマシンでアプリケーションに次のエラーが表示されます。私は、この問題をデバッグするための最良の方法が何であるかをさまよっている - それは障害が私のコードベース外で起こっているように見えるので、何もログに記録されていない.NET 2.0のkernelbase.dllでc#エラーが発生しました

Log Name: Application Source: Application Error Date: 25/01/2012 2:23:29 PM Event ID: 1000 Task Category: (100) Level: Error Keywords:
User: N/A Computer:
Description: Faulting application name:, version: 2.0.0.64, time stamp: 0x4f1f54ed Faulting module name: KERNELBASE.dll, version: 6.1.7601.17651, time stamp: 0x4e2111c0 Exception code: 0xe0434f4d Fault offset: 0x0000d36f Faulting process id: 0x%9 Faulting application start time: 0x%10 Faulting application path: %11 Faulting module path: %12 Report Id: %13

+1

http://support.microsoft .com/kb/911816 – leppie

+0

これらのマシンが確実に(この時間の5%ではない)このエラーを生成する場合、これらのマシンでリモートデバッガを接続しようとしましたか? (可能であれば)これは、問題がどこにあるかについて、少なくともあなたに考えを与えるはずです。また、いくつかの詳細は傷ついていないでしょう、このアプリは何ですか、あなたはP/Invokes、COMを使用していますか、おそらく他のアプリケーションでホストされていますか、ビルドなどをリリースまたはデバッグしていますか? –

+1

これは、捕捉されない管理例外。管理されたアプリがクラッシュする最も一般的な理由。 AppDomain.CurrentDomain.UnhandledExceptionのイベントハンドラを作成し、e.ExceptionObject.ToString()の値を記録してエラー処理を改善してください。ほとんどの場合、問題を正確に突き止めるのに十分です。 –

答えて

1

(私がやった何かによって引き起こさは間違いありません!)エラーコード0xe0434f4dはCLR例外のためのものです。

デバッグするには、クラッシュダンプとWinDbgについて知ることができます。以下は、ASP.NETのための一例ですが、.NETアプリケーションの他の種類のクラッシュダンプをキャプチャする方法を知っていれば、ダンプ解析ワークフローは同じである、

http://blogs.msdn.com/b/tess/archive/2008/02/08/net-debugging-demos-lab-2-crash.aspx

関連する問題