Preventing, Preventing, or Bypassing AppCrash

Question

We get a seemingly random AppCrash, where windows actually capture the process and close it, providing some sort of covert debugging report that includes things like NTDLL.dll, StackHash, User32.dll, etc. Examination of these modules and information in reports for more than a year gives a little more information that we had before. The best thing we could do was limit it to the DLL that our application uses to communicate with hardware that communicates via TCP / IP. We do not control this external library, we must use it and given that the problem is random (cannot be duplicated at our end, it solves on rebooting the PC), we seem to be stuck with it.

The problem is that our application must run 24/7 on a tool that is not controlled by humans. I need to detect when our application crashes and issue a reboot command to everything. The problem is AppCrash detection; there are no exceptions in the application (AppCrash is external to the application), and no registration generates any indications that the program closes.

What we need to do is start a service that checks the application or not, and if not, it reboots the system. However, when the AppCrash dialog box is displayed, it leaves the process running.

Is there a way to prevent these AppCrash notifications, bypass them, or install, at least close the program? Please do not point to stackhash.com or use the MS error report; these devices do not support internet. We also cannot fix any error in the used DLL (the OEM provider is not working).

Answer 1

One approach may be to have the application periodically inform the other service that it is alive and functioning well, rather than trying to detect when it crashes. Using IPC, you can send a heartbeat message to the monitoring service once per second.

Answer 2

You can create a wrapper application that interacts with the DLL and start the application as a separate process and only talk to the shell application (for example, through MemoryMappedFile and named Mutex).
Thus, your application is not directly affected when such an AppCrash occurs (only the wrapper is killed) - it can automatically take measures that you consider necessary (for example, remove the dialog and / or use Process.Kill to get rid of this ... )

You can even make this shell a Windows service, for which you, in turn, will configure automatic reboot upon failure (in MMC / Services).

Another point is to configure the OS to automatically reboot in this case (if it is classified as a system error, then you can configure this behavior).

EDIT - according to the comments, 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

Answer 3

Consider the tip: http://forums.techguy.org/windows-7/1032392-solved-all-browsers-crashing-windows.html

In the admin console:

Reset WINSOCK entries to installation defaults: netsh winsock reset catalog Reset IPv4 TCP/IP stack to installation defaults: netsh int ipv4 reset reset.log Reset IPv6 TCP/IP stack to installation defaults: netsh int ipv6 reset reset.log 

This fixed the same glass problems that I had with firefox and chrome. This is similar to the tcp / ip generic resolution, which may also solve your tcp / ip application issues.

I assume that these settings somehow got out of hand - I have pcap and other tools on my machine, so maybe they conflict? I do not know. Did you use the network stack or device settings?