问题
I have a certain .net application that occasionally crashes with one of the following windows errors:
[application name] has encountered a problem and needs to close. We are sorry for the inconvenience.
or
[application name] has stopped working
I want to monitor this app from another .net process, prevent showing the default windows error report dialog, and do my own error processing.
Is there a way I can detect that the other app has crashed?
And can I prevent or hide the default error dialog?
Some background information: I do have the code for the crashing app, and I can change it if necessary. However the crash is caused by a third party unmanaged assembly, which overwrites some memory and leaves the app in an unrecoverable state. A simply try-catch block is not enough to prevent the crash. This is why I want to monitor and handle the error from a separate process.
回答1:
If the app writes to the windows event log, your other program could check there for errors
回答2:
Can AppDomain.UnhandledException help?
回答3:
The dialog box is a function of Windows Error Reporting (WER).
Is there a way I can detect that the other app has crashed?
There are plenty of options, from a service that requires some kind of heartbeat message from the process, to enabling catching of corrupted state exceptions, to enabling a corporate WER server. (link below)
[C]an I prevent or hide the default error dialog?
The WER configuration documentation has information about excluding a process from the automatic dialog.
Specifically the registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\
Windows Error Reporting\ExcludedApplications\[Application Name]
(HKCU has a similar key)
Unfortunately, if it's an access violation, you're pretty well hosed. By the time that the exception has made it to WER the entire stack is blown, and the memory is already corrupt.
Disabling the built in error reporting for your application, will also prevent the automated creation of minidumps, which may be helpful, if not in solving the direct issue, providing ammunition for use convincing the vendor to fix their dll.
If the vendor is unwilling or unable to fix the problem, you could copy the way Explorer handles shell extensions, and host the component in a separate process. That way, when it crashes, it only trashes the memory of the other process. You'd have to write a wrapper to allow you to communicate with it.
来源：https://stackoverflow.com/questions/32502190/how-can-i-monitor-an-application-crash-from-a-separate-process