当c#程序崩溃怎么知道为什么？

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.

Answer 2

You can try to use the WER - Microsofts Windows Error Reporting for that. It is per default on every system. So eg you can do an automatic dump instead of the windows popup message.
There are a number of settings in the group policy editor. see the following links http://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb513638%28v=vs.85%29.aspx

Answer 3

I know this is an old question, but I came here after googling the exception code 0xc0000374.

There is an update available for the MS Visual C++ 2013 Redistributable package that fixes a heap corruption bug in the MS Visual C++ 2013 redistributable package.

Note: This update is (at time of writing) not being distributed through Windows Update. Note 2: Obviously, this update will only help, if you are using a library compiled with MS VC++ 2013 (like in my case: the MySQL ODBC Connector 5.3.x)

The update link: https://support.microsoft.com/en-us/help/3138367/update-for-visual-c-2013-and-visual-c-redistributable-package

And the source that pointed me to this update: https://bugs.mysql.com/bug.php?id=86054

Answer 4

In my case:

I use unmanaged memory. So the most simple way to REPRODUCE this bug is:

var DataPtr = Marshal.AllocHGlobal(1000 * sizeof(int));//asign a pointer for 1000 integers
Marshal.FreeHGlobal(ptr);
Marshal.FreeHGlobal(ptr);

If you try this you'll get:

The program '[12579] MyDemo.exe' has exited with code -1073740940 (0xc0000374).

So if you use such code [Alloc\Free] you might have copied some pointer to already released memory and later on release it, after it's already released.

Hope this helps someone!

Answer 5

I was able to obtain a CLR call stack by using WinDbg Preview .

1. Install and launch WinDbg Preview
2. Through the file menu, launch the application executable (may have to click the "Go" button in WinDbg if the application doesn't launch immediately)
3. Perform some actions in the application that would trigger the ntdll.dll crash
4. (Optional) If you have.pdb files available, enter .symfix <path to folder containing pdb files> in the WinDbg command line
5. Enter clrstack in the WinDbg command line (you can also use dumpstack to get a more detailed view).

You should now see the full CLR call stack in the WinDbg output window, which should give you an indication of which part of your code caused the ntdll.dll crash.

Answer 6

只需在您认为可能崩溃的代码“危险”部分使用try catch 。