when c# program crash how to know why?

Question

Often my program crash by some reason. In this case I do see Windows message with "Close" button. Every time such thing happen I do really want to know what happened.

Thanks to community I already know how to "handle" some situations, I've added such code in the beggining of my program:

    static void Main(string[] args)
    {
        AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;

        TaskScheduler.UnobservedTaskException +=
        (object sender, UnobservedTaskExceptionEventArgs excArgs) =>
        {
            Log.Push(LogItemType.Error, "Exception occured. Task terminated! + " + excArgs.Exception);
            excArgs.SetObserved();
        };

    .....

    static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        Console.WriteLine("Error: CurrentDomain_UnhandledException entered.");
        string message = (e.ExceptionObject as Exception).Message;
        Console.WriteLine(message);
        System.Diagnostics.Trace.WriteLine(message, "Unhandled UI Exception");
        Log.Push(LogItemType.Error, message);
    }

Sometimes this helps. But sometimes program just crash with no message. What else can I do? Every time program crash I want to know why.

upd Windows Logs contains almost everything I need, except the most important thing - the stacktrace

Faulting application name: MBClient.exe, version: 1.0.0.0, time stamp: 0x50a5da1d
Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec4aa8e
Exception code: 0xc0000374
Fault offset: 0x00000000000c40f2
Faulting process id: 0x10f8
Faulting application start time: 0x01cdc3c2041e2607
Faulting application path: C:\Oleg\bin\mbclient\MBClient.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 810c805d-2fc3-11e2-bfb5-2c768a509157

Answer 1

Exception code 0xc0000374 means you're facing heap corruption.

The most common causes for this kind of error are these two:

• A faulty RAM module
• Buffer overrun, when one thread tries to read something and another thread has removed data in the meanwhile. This shouldn't happen in managed code as far as I can tell.

You probably have to get Windows Debugging Tools to figure out what's wrong if you can't debug the application in the dev environment.