3

I have a big and complex process that runs on a production environment that's basically a WPF user interface developed in C#. It also hosts threads and DLL's written in C++ unmanaged and managed code.

Typically, if an exception raises, it's caught and the related stack dump is written in a log file for post-mortem debugging purposes. Unfortunately, from time to time, the application crashes without writing any information in the log so we have no clue about who's causing the crash.

Does anybody know how to detect and eventually trace all the causes that make the application crash and are not detected with a simple try-catch block?

To give an example I saw that StackOverflow Exception is not caught and also errors like 0xc0000374 coming from unmanaged code are not detected. This is not a matter of debugging it. I know I can attach a debugger to the system and try to reproduce the problem. But as I told this is a production system and I have to analyze issues coming from the field after the problem occurred.

René Vogt
  • 43,056
  • 14
  • 77
  • 99
Massimiliano Omero
  • 31
  • 5
  • Some program faults are just too severe to allow the program to continue. And either the CLR or the OS will pull the plug, no stack trace. If you have a program running in production that routinely fails with SOE and heap corruption then you have a pretty doggone big problem, the kind you can only ever diagnose from a minidump. Black belt debugging skills required. Realistically, run man, run! – Hans Passant Dec 17 '15 at 11:05
  • Unfortunately there are some (not much but not negligible) crashes reported from the field where this software is installed. Issue is not systematic and nobody knows the sequence to reproduce it. But in my opinion this is a general topic. I want the system is able to generate dump or stack trace for all the failures in order to help post-mortem debugging for issues not detected in validation phase. It's really not only related with the current issue(s). I know how to do it in Linux/RTOS on embedded systems where I have more than 15 years of experience but I'm pretty a newbie with Microsoft – Massimiliano Omero Dec 17 '15 at 14:50

3 Answers3

0

Unlike C# exceptions, C++ exceptions do not catch hardware exceptions such as access violations or stack overflows since C++ apps run unmanaged and directly on the cpu.

For post-crash analysis I would suggest using something like breakpad. breakpad will create a dump file which will give you very useful information such as a call-stack, running threads and stack/heap memory depending on your configuration.

This way you would not need to witness the crash happening or even try to reproduce it which I know from experience can be very difficult. All you would need is a way to retrieve these crash dumps from your users devices.

Mohamad Elghawi
  • 2,071
  • 10
  • 14
  • Thanks, I will explore it. A crash dump is even better for my purposes. – Massimiliano Omero Dec 17 '15 at 10:59
  • Struggling trying to get something compilable for Windows. I have gyp file and I can't covert it in a solution file. I found in the Internet that inside the sources there is a batch file (gyp.bat) to convert gyp in sln but I don't think it's in the fresh package I just cloned on my system – Massimiliano Omero Dec 17 '15 at 14:36
  • @MassimilianoOmero Have a look at this [thread](http://stackoverflow.com/questions/3618721/how-to-build-google-google-breakpad-for-windows). – Mohamad Elghawi Dec 17 '15 at 15:51
  • Thanks, already saw it. Unfortunately the gyp tool is no more in the package. I tried to get one older package from a svn repo (the latest is on git) but it's not working properly. With SVN repo I can properly genearate the solution that does not compile, apparently for a bug in the sources that seems fixed in a version on the git repo but getting the git repo and using the gyp tools from svn generates wrong solution/vcproj files (some header files are missing). I'm trying to find a way to fix it ... – Massimiliano Omero Dec 17 '15 at 16:25
0

You can log exception by subscribing to AppDomain.UnhandledException event. Its args.ExceptionObject argument is of type object and is designed not to be limited by C# exceptions, so you can call ToString method to log it somewhere.

Also check MSDN docs for its limitations. For instance:

Starting with the .NET Framework 4, this event is not raised for exceptions that corrupt the state of the process, such as stack overflows or access violations, unless the event handler is security-critical and has the HandleProcessCorruptedStateExceptionsAttribute attribute.

dewaffled
  • 2,850
  • 2
  • 17
  • 30
  • Already tried it and I think does not work with all the exceptions (I tried with stack overflow and heap corruption, real exceptions, not thrown by the user). My handler has never been called. Maybe I doing something wrong but I just followed the documentation – Massimiliano Omero Dec 17 '15 at 14:31
0

Solved ! I followed Mohamad Elghawi suggestion and I integrated breakpad. After I struggled a lot in order to make it compiling, linking and working under Visual Studio 2008, I was able to catch critical system exceptions and generate a crash dump. I'm also able to generate a dump on demand, this is useful when the application stuck for some reason and I'm able to identify this issue with an external thread that monitors all the others. Pay attention ! The visual studio solution isn't included in the git repo and the gyp tool, in contradiction as wrongly mentioned in some threads, it's also not there. You have to download the gyp tool separately and work a bit on the .gyp files inside the breadpad three in order to generate a proper solution. Furthermore some include files and definitions are missing if you want to compile it in Visual Studio 2008 so you have also to manage this.

Thanks guys !

Community
  • 1
  • 1
Massimiliano Omero
  • 31
  • 5