导致AppCrash的C#控制台应用程序中的未处理异常

时间:2012-11-13 20:31:08

标签: c# exception exception-handling error-handling unhandled-exception

我有一个在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";
}

为了增加以上所有内容,我似乎发现有一个普遍的例外被抛出但它并没有帮助我 - 如果有人能够对此有所了解,那就太棒了:< / p>

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

非常感谢提前。

3 个答案:

答案 0 :(得分:3)

如果您的程序是多线程的并且在其中一个生成的线程中抛出异常,则可能无法捕获异常,具体取决于您在程序中执行异常处理的方式。

您可以像这样添加一个catch-all异常处理程序:

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 不为空吗?
  • 在以下行中,如果oSplitData.Project不是SageDataObject190.Project类型,则oProject将为 null 。测试 null

    oProject = oSplitData.Project as SageDataObject190.Project;

答案 1 :(得分: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 ;
}

请参阅Will CLR handle both CLS-Complaint and non-CLS complaint exceptions?

此外,C ++在msdn:http://msdn.microsoft.com/en-us/library/6dekhbbc(v=vs.100).aspx

尝试,捕获并抛出语句

MSIL操作码throw(0x7A)允许抛出任何对象引用。但是,C#不允许它。

但看起来他们用.Net 2.0改进了东西并开始在RuntimeWrappedException中包装奇怪的东西。

答案 2 :(得分:0)

您可能正在处理所谓的损坏状态异常。这些异常以某种方式破坏了进程,因此杀死进程通常更安全,因为很难从这样的错误中恢复,即使它只是用于运行短的catch子句。示例是StackOverflowExceptions,OutOfMemoryExceptions或AccessViolationExceptions。

this article中有关于已损坏状态异常的广泛且通常有趣的解释。

如何帮助解决此类异常是使用DebugDiag。使用Microsoft(download on this page)中的此工具,您可以定义崩溃规则,该规则会为失败的进程生成故障转储。您可以在Visual Studio中轻松打开这些转储文件,您可以在其中找到导致失败的异常源。这不能保证,但过去常常帮助我找出一些令人讨厌的错误。