0

I am in the process of designing a crash handler solution for one of our applications that creates a crash dump file using the MiniDumpWriteDump() function. While reading up on the topic I have seen the recommendations to invoke MiniDumpWriteDump() from an external process to maximize the chance that the dump file contains the correct information. The common solution seems to be to run a watchdog process in parallel to the application process. When the application crashes it somehow contacts the watchdog process, providing it with the information that is required to create the crash dump. Then the application goes to sleep until it is terminated by the watchdog process.

I can imagine such a watchdog process being run continually as a background service. This has many implications, starting with "who creates the service?", but also "which user does the service run as?", and "how does the application contact the service?" etc. It seems a pretty heavy-weight solution which I don't feel is appropriate for the scope of my task.

A simpler approach is suggested by this SO answer: Launch a guard process on application startup that is tightly coupled to the application process. This is pretty good, but it still leaves me with the tasks of 1) keeping the information somewhere in the application how I can contact the guard process in case of a crash; and 2) making sure to terminate the guard process if the application process shuts down normally.

The simplest solution of all would be to launch the crash dump handler process at the time the crash occurs, passing all the information that is required to create the crash dump as arguments to the process. This information consists of

  • The process ID of the application process that crashed
  • The thread ID of the thread that crashed
  • The adress of the EXCEPTION_POINTERS structure that describes the exception that caused the crash

This "fire and forget" approach is compelling because it does not require any state retention, nor any complicated over-time process management. In fact, the approach seems so overwhelmingly simple that I cannot help but feel that I am overlooking something.

What are the arguments against such an approach?

Community
  • 1
  • 1
herzbube
  • 13,158
  • 9
  • 45
  • 87
  • 1
    You should consider using [WER](https://msdn.microsoft.com/en-us/library/windows/desktop/bb513641(v=vs.85).aspx) to handle your crash reporting needs. I've got an application that uses an exception filter as part of the application (not in an external process), but, it does not call MiniDumpWriteDump to collect the dump. The exception filter relies on WER to collect the dump. We then add some additional files onto the crash report and collect it from the Microsoft WER site when it arrives. – rrirower Sep 10 '15 at 13:03
  • In [another answer](http://stackoverflow.com/a/13591900/4136325), Hans Passant suggests using a memory mapped file for data transfer and not starting a new process. But if I had to implement it, I'd try the way of @rrirower first. Let WER create the dump and perhaps implement a watchdog to watch the directory for new dump files. – Thomas Weller Sep 11 '15 at 14:56
  • @Thomas I've seen that answer, yes. I still think the "fire and forget" approach is simpler. Regarding WER: Right now, collecting crash dumps is all very new for us and I still have to show to my team, my boss, support dept etc. how useful this can be. I don't think the rest of the company would like it if at this stage I were to add a new dependency to a Microsoft service. – herzbube Sep 11 '15 at 16:18
  • WER allows [dumps to be collected on the local disk](https://msdn.microsoft.com/de-de/library/windows/desktop/bb787181%28v=vs.85%29.aspx). No dependency to Microsoft there. – Thomas Weller Sep 12 '15 at 07:50
  • @ThomasWeller Yes, that does remove the dependency on WER. However, WER provides much more than crash collection. There are several types of useful reports. Keep in mind, that if you decide to collect the crash reports yourself, you'll also need to build in a mechanism to ship them back and to store them at the company site. That's something that WER handles for you. – rrirower Sep 13 '15 at 16:06
  • @rrirower: IMHO WER would e.g. not transmit a full memory dump (e.g. 2 GB) to Microsoft from where you could download it. In case of .NET, a full memory dump is sometimes required – Thomas Weller Sep 13 '15 at 16:27

1 Answers1

0

The main argument against the "fire and forget" approach, as I called it, is that it is not safe to launch a new process at a time when the application is already in a state where it is about to crash.

Because of that I went for the "guard process" approach. It brings a number of challenges with it, for which Hans Passant has outlined a solution. I also added a bit of code in this answer that should help with deep-copying the all-important EXCEPTION_POINTERS data structure.

Using WER, as proposed in the comments, also looks like a good alternative to writing your own guard process. I must admit I have not investigated this any further, though.

Community
  • 1
  • 1
herzbube
  • 13,158
  • 9
  • 45
  • 87