What do the details of an APPCRASH message mean?

Question

I am experiencing an APPCRASH from my C# application. The Runtime gives an error message of "This application has requested the Runtime to terminate it in an unusual way". Then, when I click okay I get a "MyApplication has stopped working" message with the usual "check online for a solution", "close program" and "debug program" options. When I click "additional details" I get the APPCRASH signature, with lots of additional information. Some of it is human readable, some of it is just hex numbers. The "Exception Code" is 40000015. There are also lines of "Additional Information". My question is: does anyone in the universe know what the information in an APPCRASH message means?

It seems like the message was meant to be read by someone who can divine a cause from it. When searching for answers I found a lot of people posting messages formatted exactly the same. Unfortunately, I have found no explanations of what this information means.

Also, I have tried the "Debug Program" option, but it is unhelpful. It just puts me in system dlls with none of my code anywhere up the call stack. I've investigated, and the error doesn't occur in this system code.

The APPCRASH message named another dll as the "Fault Module" (this code uses a lot of external dlls), and the fatal error probably occurs there. But that information isn't very helpful because I need to find the place in my code that makes a bad call to the external dll (or puts it in a bad state). Sadly, when I say "my code" I just mean the code that I'm working with. It's a huge codebase written by several dozen people over a couple years, so I can't just guessing places that might make the fatal call. That's why I was hoping to divine more information from the APPCRASH message. That's also why I'm being very stingy with details. The whole thing is all very proprietary with lots of red tape. That's also why I haven't posted the APPCRASH message contents.

To be clear, I am not asking you to debug my problem for me. I have no way of giving you a reproducible case of the error, and I'm not asking anyone to tell me the cause of the error in my specific case. I just want to know how to interpret those hex numbers, and I haven't been able to find any documentation.

Mehta

It the exception code that's used when native C or C++ code calls the abort() function. We can't help you find it but clearly it is located in the "system dlls" you got lost in. – Delisle

The exception doesn't occur in the system code that the debugger put me in; but it's likely an exception is occurring in a different external dll. If this is from an abort() call, then it's dying somewhere in unmanaged land. – Mehta

Sounds like you're having problems with unmanaged code. To isolate the problem, I would try to check for [DllImport] in your code an try to mock, comment this and see if you have less problems. Other idea is if you have 3rd party components that can have wrong unmanaged calls. Last, try to WinDBG and look for the problem. WinDBG will be my last resource, since I'm not specialist and it's a very hardcore way of debugging. – Oaf

Answer 1

Here is an example of an app crash message:

Problem signature:
Problem Event Name: APPCRASH
Application Name: WINWORD.EXE
Application Version: 12.0.4518.1014
Application Timestamp: 45428028
Fault Module Name: StackHash_7ae5
Fault Module Version: 6.0.6000.16386
Fault Module Timestamp: 4549bdc9
Exception Code: c0000374
Exception Offset: 000af1c9
OS Version: 6.0.6000.2.0.0.256.4
Locale ID: 1033
Additional Information 1: 7ae5
Additional Information 2: 4cf2e59e469447e0692da79a5a9446de
Additional Information 3: 333f
Additional Information 4: 583336399425ab3efc33bdfbb60895ee

Application name and application version are straightforward, as is the timestamp (this is the changed date in File Explorer, encoded as a 32-bit Unix timestamp value). Fault Module is usually a dll name, and the exception offset is the offset address of the hardware instruction in the DLL that caused the error. In this case it was an internal runtime error where no valid module could be retrieved, so we got StackHash instead of a real value. The versions are the normal PE version strings of executable files in Windows. The locale ID is the globalization settings bank being used: 1033 is en-US.

The exception code can be interpreted here. In this example, the error was a STATUS_HEAP_CORRUPTION.

The additional information fields are opaque data, and based on what the exception code was. I do not know of any useful information on those fields, there likely isn't any, and it is likely those fields are purposefully undocumented so that Microsoft can change them as needed. Those fields are usually md5 hashes of a lot of information... it's basically there so that lots of information can be compared to be the same/different quickly via the hashcode so you know if the error is due to the same execution state as another.

Savoyard

Answer 2

It means you have an uncaught unhanded exception and it is crashing your application.

If it is working in debug mode you need to look to see what is different about the release version. Are all the libraries present? Do you have your app.config setup?

Check your event viewer under Windows Logs -> Application for more information.

If you setup an exception handler you will get much better information, such as a stack trace.

Monkshood

Hi, thanks for responding. Unfortunately, I've tried all the usual tricks and I haven't gotten very far. Currently running in debug mode, and it breaks. I have the debugger set to break on unhandled exceptions, and it's not catching any. The information in the event viewer is no more detailed than the appcrash message. – Mehta

@Monkshood - there are some bad ass exceptions (like StackOverflowException or OutOfMemory exceptions) that corrupt AppDomain state, those exceptions cannot be logged/cached when they occur for real – Chemical

Answer 3

You need to produce a crashdump that can be analyzed after the fact. You will need to make some changes to the registry, and then you can analyze the dump file using Visual Studio. Hopefully, that will give you more clues such as specific function that is failing.

See this website for details: http://blog.functionalfun.net/2013/05/how-to-debug-silent-crashes-in-net.html

You'll be setting up DebugDiag, a tool from Microsoft.

Let me know how things go or if you find some better tools.

Regards,

Dave

Flambeau

Answer 4

There is a nice feature in .net, Managed Debugger Assistants, to troubleshoot native and managed code interoperations MSDN article about using it here

Exceptions thrown by MDA can be configured in Visual Studio exceptions view window.

Freed