预防、避免或绕过 AppCrash
我们得到了一个看似随机的 AppCrash，Windows 实际上接管了该进程并关闭了它，并给出了一些神秘的调试报告，其中包括 NTDLL.dll、StackHash、User32.dll 等。研究这些模块和报告中的信息超过一年后我们得到的信息并不比以前多多少。我们能做的最好的事情就是将其范围缩小到我们的应用程序用来与通过 TCP/IP 进行通信的硬件进行交互的 DLL。我们无法控制这个外部库，必须使用它，并且考虑到问题是随机的（在我们这边永远无法重复，在电脑重新启动时自行解决），我们似乎被它困住了。
问题是我们的应用程序需要在无人监控的仪器上 24/7 运行。我需要检测我们的应用程序何时崩溃，并向整个应用程序发出重新启动命令。问题是检测 AppCrash；应用程序内部不会生成任何异常（AppCrash 位于应用程序外部），并且任何日志记录都不会生成任何程序正在关闭的指示。
我们想要做的是运行一个服务来检查应用程序是否正在运行，如果没有，它会发出重新启动命令来重新启动系统。但是，当显示 AppCrash 对话框时，它会使进程保持运行状态。
有没有办法阻止这些 AppCrash 通知、绕过它们或将它们设置为至少先关闭程序？请不要指向 stackhash.com 或使用 MS 错误报告；这些设备不支持互联网。我们也无法修复我们正在使用的 DLL 中的任何错误（OEM 供应商不合作）。
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).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一种方法可能是让应用程序定期告诉另一个服务它还活着并且运行良好，而不是尝试检测它何时崩溃。使用 IPC，您可以每秒向监控服务发送一次心跳消息。
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.
您可以创建一个与 DLL 交互的包装器应用程序，并让您的应用程序作为单独的进程启动该包装器，并且仅与包装器应用程序通信（例如通过 MemoryMappedFile 并命名为 Mutex）。
这样，当发生此类 AppCrash 时，您的应用程序不会受到直接影响（只有包装器被杀死） - 然后它可以自动采取您认为必要的措施（例如使对话消失和/或使用 Process.Kill 来摆脱它...）。
您甚至可以将该包装器设置为 Windows 服务，然后为该服务配置失败时自动重新启动（在 MMC/服务中）。
另一点是将操作系统设置为在这种情况下自动重新启动（如果这被归类为系统错误，那么您可以配置此类行为）。
编辑 - 根据评论，一些指向 MemoryMappedFile 信息的链接：
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://forums.techguy.org/windows -7/1032392-solved-all-browsers-crashing-windows.html
在管理控制台中：
这解决了我遇到的相同的 stackhash 问题与 Firefox 和 chrome 一起使用。这似乎是一个通用的 tcp/ip 解决方案，也可以解决您应用程序的 tcp/ip 问题。
我认为这些设置不知何故变得不正常——我的机器上有 pcap 和其他工具，所以它们可能会发生冲突吗？不知道。您是否摆弄过网络堆栈或网卡设备设置？
Consider the advice from:
http://forums.techguy.org/windows-7/1032392-solved-all-browsers-crashing-windows.html
In an admin console:
This fixed the same stackhash problems I was having with firefox and chrome. It seems like a general tcp/ip resolution that may address your app's tcp/ip problems as well.
I presume these settings got out-of-wack somehow - I have pcap and other tools on my machine so perhaps they conflict? Don't know. Have you fiddled with your network stack or nic device settings?