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

Question

I have a Windows Console application built in Visual Studio 2010 and it keeps crashing but the error is not caught by the visual studio debugging tool nor by try/catch statements in my code.

I have managed to locate the WER file on my system and would like to be able to understand the contents of the file so I can pinpoint exactally what is causing the unhandled exception.

I would be greatful if anyone can offer some idea on how I can use the following information to locate the process causing me this problem and also what the exception may be...

The information from the WER file is:

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

Here is the section of code I believe to be causing the exception to be thrown:

//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";
}

To add to all the above I seem to have found that there is a general exception that is being thrown but it doesn't help me out much - if anyone can put some light on this it would be great:

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

Answer 1

If your program is multi-threaded and the exception is thrown in one of the spawned threads, the Exception may not be caught depending on how you do exception handling in your program.

You can add a catch-all exception handler like this:

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);
    }
}

UPDATE

Based on the code you posted, here are some things to look at

• Put a try/catch block around the code you posted.
• Are you sure that oSplitData is not null?

• In the following line, oProject will be null if oSplitData.Project is not of type SageDataObject190.Project. Test for null .

  oProject = oSplitData.Project as SageDataObject190.Project;

Answer 2

Are you invoking non-managed C++ or other code?

I'd try something like

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 ;
}

See Will CLR handle both CLS-Complaint and non-CLS complaint exceptions?

Also C++ try, catch and throw statements at msdn:http://msdn.microsoft.com/en-us/library/6dekhbbc(v=vs.100).aspx

And MSIL opcode throw (0x7A) allows the throwing any object reference. C#, however, does not allow it.

But it looks like they improved things with .Net 2.0 and started wrapping oddball stuff in an RuntimeWrappedException .

Answer 3

You are probably dealing with so-called corrupted state exceptions. These exceptions corrupt the process in a way so it is usually more safe to kill the process since it is very difficult to impossible to recover from such an error, even if it would be only for running a short catch-clause. Examples are StackOverflowExceptions, OutOfMemoryExceptions or AccessViolationExceptions.

There is an extensive and generally interesting explanation on corrupted state exceptions in this article .

What is helpful on getting a hand on such exceptions is to use DebugDiag. With this tool from Microsoft ( download on this page ) you can define a crash rule which generates a crashdump for your failed process. You can easily open these dump files in Visual Studio, where you may find the source of the exception that lead to the failure. This is not guaranteed but it often helped me in the past to nail down some nasty errors.