How to troubleshoot .NET 2.0 Error Reporting messages in the event log?

Question

I work on an open source product called EVEMon written in C# targeting the .NET 2.0 platform, I have one user who is suffering from a strange .NET crash that we have been un

Answer 1

Peeking into your source code (trunk) indicates that your unhandled exception handling seems to be incomplete in regard to Windows Forms applications:

You need to handle both non-UI thread exceptions and UI thread exceptions:

• For the former you need to implement a CLR unhandled exception handler via AppDomain.CurrentDomain.UnhandledException, which is in place already.

• For the latter you need to implement a Windows Forms unhandled exception handler via Application.ThreadException, which seems to be missing; this could indeed yield exactly those problems you are witnessing. For an implementation example see MSDN documentation of Application.ThreadException Event.

Please note that right now you explicitly suppress catching unhandled Windows Forms exceptions via Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException), you'll need to change this to UnhandledExceptionMode.CatchException to enable routing to your handler for Application.ThreadException, as correctly suggested by Jehof already.

Answer 2

...if you are able to contact that suffering user, here is an

Idea: log pre-execution stages

Instead of making a shortcut to your program.exe, make a shortcut to program.bat, which will

echo "Pre-start" > stage.txt
start program.exe

The first line of Program.cs will therefore be

File.WriteAllLines("stage.txt", "Program execution started.");

In the handler of AppDomain.UnhandledException first line will be

File.WriteAllLines("stage.txt", "Unhandled exception has been caught.");

Also, make sure that the handler does not allocate memory or resources — pre-allocate them on programs start. Handler only trigger the writing to the log.

Comments

It is very likely that the stage.txt (sent by the user) will contain "Pre-start". This happens when an exception is thrown in 3rd party .dll — even before your program has started.

In that case you will need a simple checker program, which will not reference the assemblies that you program.exe does, but will Assembly.Load(...) them.

P.S.

stage.txt should be placed somewhere under %APPDATA%, not in Program Files.

I found an interesting case on Server 2003 and another nice discussion.

Answer 3

What OS (Windows XP, Windows Vista, etc.) does the user use?

If Windows Vista try to disable "Problem Reports and Solutions feature" (Control Panel-->Problem Reports and Solutions-->Change Settings-->Advanced Settings-->Turn off for my programs, problem reporting)

Or try to set

  Application.SetUnhandledExceptionMode( UnhandledExceptionMode.CatchException );

This will always route exceptions to the ThreadException handler.

Answer 4

This is how I would tackle the problem for a end user with a crash.

1. Download and install Debugging Tools for Windows at http://www.microsoft.com/whdc/devtools/debugging/default.mspx

2. Once the tools are installed (they end up going to C:\Program Files\ by default) start a command line window.

3. Change to the directory which contains adplus (e.g "C:\Program Files\Debugging Tools for Windows (x86)").

4. Run the follwing command. This will start the application and attach adplus.

adplus -crash -o C:\debug\ -FullOnFirst -sc C:\path\to\your\app.exe

After the crash dump is created

Once the application crashes start WinDbg and load the .dmp file that is created in C:\debug. (File --> Open Crash Dump)

Execute these commands to see the stack trace and hopefully find the problem.

To load SOS for debugging

• Pre .NET 4.0

.loadby sos mscorwks

• .NET 4.0

.loadby sos clr

To see the stack trace

!clrstack

To see a more useful stack trace

!clrstack –p

To poke inside an object..perhaps see what caused the exception

!do <address>

e.g This is the result from a application that faulted randomly with an IO exception. WinDbg pointed out the path that was being referenced which was incorrect.

0:009> !do 017f2b7c    
Name: System.String    
MethodTable: 790fd8c4    
EEClass: 790fd824    
Size: 124(0x7c) bytes    
 (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)    
String: \\server\path\not_here.txt
Fields:    
      MT    Field   Offset                 Type VT     Attr    Value Name    
79102290  4000096        4         System.Int32  1 instance       54 m_arrayLength    
79102290  4000097        8         System.Int32  1 instance       53 m_stringLength    
790ff328  4000098        c          System.Char  1 instance       5c m_firstChar    
790fd8c4  4000099       10        System.String  0   shared   static Empty    
    >> Domain:Value  00161df8:790d884c <<    
7912dd40  400009a       14        System.Char[]  0   shared   static WhitespaceChars    
    >> Domain:Value  00161df8:014113e8 <<

Answer 5

In a nutshell: there is an unhandled exception in the application.

If you have access to the machine (through remote access, etc.), try installing Visual Studio Express and starting the application. You should see a dialog offering the chance to debug the application with a new instance of Visual Studio.

It may also be that there is something preventing Windows Forms from properly initializing. I've seen forum posts that suggest that font issues can cause this -- ensure that the users have the fonts installed that your application needs plus the usual defaults such as MS SansSerif, Arial, Tahoma, Times and suchlike.

And failing that... try sacrificing a chicken over the PC. Works a charm every time!

Answer 6

We've had issues with Exceptions in Thread-Code. If you spawn a new Thread and forget to handle an exception in the thread method, the application just "stops" - no error message, no nothing, but only an entry in the Event Log. Not even then UnhandledExceptionHandler is triggered.

Maybe something like this is the cause?