2

Visual Studio 2010 でビルドされた Windows コンソール アプリケーションがクラッシュし続けていますが、Visual Studio デバッグ ツールやコード内の try/catch ステートメントによってエラーが検出されません。

システム上の WER ファイルを見つけることができました。ファイルの内容を理解して、未処理の例外の原因を正確に特定できるようにしたいと考えています。

次の情報を使用して、この問題の原因となっているプロセスと、例外が何であるかを特定する方法について、誰かがアイデアを提供できれば幸いです...

WER ファイルの情報は次のとおりです。

Version=1
EventType=APPCRASH
EventTime=129973086237604286
ReportType=2
Consent=1
ReportIdentifier=91331e8b-2dc8-11e2-977b-080027f7e5bb
IntegratorReportIdentifier=91331e8a-2dc8-11e2-977b-080027f7e5bb
WOW64=1
Response.type=4
Sig[0].Name=Application Name
Sig[0].Value=SAGE_TESTING.vshost.exe
Sig[1].Name=Application Version
Sig[1].Value=10.0.30319.1
Sig[2].Name=Application Timestamp
Sig[2].Value=4ba2084b
Sig[3].Name=Fault Module Name
Sig[3].Value=ntdll.dll
Sig[4].Name=Fault Module Version
Sig[4].Value=6.1.7600.16385
Sig[5].Name=Fault Module Timestamp
Sig[5].Value=4a5bdb3b
Sig[6].Name=Exception Code
Sig[6].Value=c015000f
Sig[7].Name=Exception Offset
Sig[7].Value=000845bb
DynamicSig[1].Name=OS Version
DynamicSig[1].Value=6.1.7600.2.0.0.272.7
DynamicSig[2].Name=Locale ID
DynamicSig[2].Value=2057
DynamicSig[22].Name=Additional Information 1
DynamicSig[22].Value=0a9e
DynamicSig[23].Name=Additional Information 2
DynamicSig[23].Value=0a9e372d3b4ad19135b953a78882e789
DynamicSig[24].Name=Additional Information 3
DynamicSig[24].Value=0a9e
DynamicSig[25].Name=Additional Information 4
DynamicSig[25].Value=0a9e372d3b4ad19135b953a78882e789

例外がスローされる原因になっていると思われるコードのセクションは次のとおりです。

//Data from the project linked to the split data
if (oSplitData.Project != null)
{
    oProject = oSplitData.Project as SageDataObject190.Project;

    oBasicDetail.ProjectID = oProject.ProjectID;
    oBasicDetail.ProjectReference = oProject.Reference.ToString();
}
else
{
    oBasicDetail.ProjectID = -1;
    oBasicDetail.ProjectReference = "NO_PROJECT";
}

上記のすべてに加えて、スローされている一般的な例外があることがわかったようですが、それはあまり役に立ちません-誰かがこれに光を当てることができれば、それは素晴らしいことです:

Unhandled exception at 0x78bc7361 in SAGE_TESTING.exe: 0xC0000005: Access violation reading location 0xfeeefeee.
4

3 に答える 3

3

プログラムがマルチスレッドであり、生成されたスレッドの1つで例外がスローされた場合、プログラムでの例外処理の方法によっては、例外がキャッチされない場合があります。

次のようなキャッチオール例外ハンドラを追加できます。

class Program 
{
    static void Main(string[] args) 
    {
        AppDomain.CurrentDomain.UnhandledException += UnhandledExceptionHandler;
        // Your code here
    }

    static void UnhandledExceptionHandler(object sender, UnhandledExceptionEventArgs e) 
    {
        Console.WriteLine(e.ExceptionObject.ToString());
        Environment.Exit(1);
    }
}

アップデート

あなたが投稿したコードに基づいて、ここにいくつかの注意事項があります

  • 投稿したコードの周りにtry/catchブロックを配置します。
  • oSplitDataがnullではないことを確認しますか？

  • 次の行で、oSplitData.ProjectのタイプがSageDataObject190.Projectでない場合、oProjectはnullになります。nullをテストします。

    oProject = oSplitData.Project as SageDataObject190.Project;

于 2012-11-13T20:37:16.393 に答える
0

非マネージ C++ またはその他のコードを呼び出していますか?

私は何かを試してみます

static void Main()
{
  try
  {
    DoSomethingUseful() ;
  }
  catch ( Exception e )
  {
    // managed exceptions caught here
  }
  catch
  {
    // non-managed C++ or other code can throw non-exception objects
    // they are caught here.
  }
  return ;
}

「 CLR は CLS 準拠の例外と非 CLS 準拠の例外の両方を処理しますか?」を参照してください。

また、msdn での C++ の try、catch、および throw ステートメント: http://msdn.microsoft.com/en-us/library/6dekhbbc(v=vs.100).aspx

また、MSIL オペコードthrow(0x7A) を使用すると、任意のオブジェクト参照をスローできます。ただし、C# では許可されません。

しかし、彼らは.Net 2.0で物事を改善し、奇妙なものをRuntimeWrappedException.

于 2012-11-13T20:53:38.447 に答える
0

おそらく、いわゆる破損状態の例外を扱っているでしょう。これらの例外はプロセスを何らかの形で破壊するため、短い catch-clause を実行するためだけであっても、このようなエラーから回復することは非常に困難または不可能であるため、通常はプロセスを強制終了する方が安全です。例としては、StackOverflowExceptions、OutOfMemoryExceptions、または AccessViolationExceptions があります。

この記事には、破損状態の例外に関する広範で一般的に興味深い説明があります。

このような例外に対処するのに役立つのは、DebugDiag を使用することです。Microsoft のこのツール (このページからダウンロード) を使用すると、失敗したプロセスのクラッシュダンプを生成するクラッシュ ルールを定義できます。これらのダンプ ファイルは Visual Studio で簡単に開くことができ、失敗の原因となった例外の原因を見つけることができます。これは保証されていませんが、過去にいくつかの厄介なエラーを特定するのに役立ちました.

于 2012-11-13T21:27:53.680 に答える