Preventing, Avoiding, or Bypassing AppCrash

Question

We get a seemingly random AppCrash, where windows actually takes over the process and closes it, giving some arcane debugging report that includes things like NTDLL.dll, StackHash, User32.dll, etc. Researching these modules and information in the reports for more than a year yields little more information that we had before. The best we've been able to do is narrow it down to a DLL our application uses to interact with a piece of hardware that communicates over TCP/IP. We have no control over this external library, must use it, and given the fact the problem is random (cannot ever duplicate on our end, solves itself on a PC restart), we seem to be stuck with it.

The problem is that our application needs to run 24/7 on an instrument that is not monitored by a human being. I need to detect when our application crashes, and issue a restart command to the entire thing. The problem is detecting an AppCrash; no exceptions are generated inside the application (the AppCrash is external to the application), and no amount of logging generates any indication the program is closing.

What we'd like to do is run a service that checks for the application running or not, and if not it issues a reboot command to restart the system. However, when the AppCrash dialog is showing, it leaves the process running.

Is there a way to either prevent these AppCrash notifications, bypass them, or set them to at least close the program first? Please, no pointers to stackhash.com or using MS error reporting; these devices are not internet-capable. We also can't fix whatever bug is in the DLL we're using (OEM supplier is uncooperative).

Answer 1

One approach might be to have the app periodically tell another service that it's alive and functioning well, rather than trying to detect when it crashes. Using IPC, you could send a heartbeat message to a monitoring service once a second.

Answer 2

You could make a wrapper application that interacts with the DLL and have your app start that wrapper as a separate process and only talk to the wrapper app (for example via MemoryMappedFile and named Mutex).
This way your app is not directly influenced when such an AppCrash happens (only the wrapper gets killed) - it can then automatically take the measures you deem necessary (for example make the dialogue go away and/or use Process.Kill to get rid of it...).

You could even make that wrapper a Windows Service for which you in turn configure an automatic reboot on failure (in MMC/Services).

Another point would be to setup the OS to reboot automatically on such an occasion (IF this is classified as a system error then you can configure such a behaviour).

EDIT - as per comment some links to MemoryMappedFile information:

• http://blogs.msdn.com/b/salvapatuel/archive/2009/06/08/working-with-memory-mapped-files-in-net-4.aspx
• http://weblogs.asp.net/gunnarpeipman/archive/2009/06/21/net-framework-4-0-using-memory-mapped-files.aspx
• http://blogs.msdn.com/b/bclteam/archive/2011/06/06/memory-mapped-file-quirks.aspx
• http://msdn.microsoft.com/en-us/library/system.io.memorymappedfiles.memorymappedfile.aspx