windows 检测应用程序何时停止响应，杀死它并重新启动它

Detect when an Application stops Responding, Kill it and Restart it

提问by Mehdi LAMRANI

I am developing a high performance App that is causing the main process to seemingly stop responding and crash - from time to time - due to overload (I get the Close Application Dialog so the App never exits per se, just freezes, which is annoying)

我正在开发一个高性能应用程序，它导致主进程似乎停止响应和崩溃 - 由于过载（我得到关闭应用程序对话框，所以应用程序本身永远不会退出，只是冻结，这很烦人）

I welcome any clean way to pro grammatically detect when the App is frozen, so I can use a BAT (or else) to automatically Kill the process and Restart.

我欢迎任何以编程方式检测应用程序何时冻结的干净方法，因此我可以使用 BAT（或其他）来自动终止进程并重新启动。

Of course, this is a temporary fix while auditing the App, but it comes very handy in the meanwhile.

当然，这是审核应用程序时的临时修复，但同时它非常方便。

TieBreaker :BTW, Is there a way to override windows' Exception Screen and just quit the App ??? This is mostly annoying feature most of the time.

TieBreaker ：顺便说一句，有没有办法覆盖 Windows 的异常屏幕并退出应用程序？？？大多数情况下，这主要是令人讨厌的功能。

EDIT :
FOR GOD'S SAKE : the app ISfreaking freezing, THOUGHevery single task run in BG Workers and threads !!! And I specified that in comments. Come'on, I am not that dumb. Just that your app runs BG workers does not imply it never freezes ! And As I said, please JUST answer my question, I am not looking for lessons on how to design my App, that I am already working on and I know what has to be done. As specified MANY times, I just need a fix on the server in the meantime. Thank you.

编辑：
在上帝的份：应用IS吓坏冻结，但在BG工人和线程的每一个任务运行！我在评论中说明了这一点。拜托，我没那么笨。只是您的应用程序运行 BG 工作人员并不意味着它永远不会冻结！正如我所说，请回答我的问题，我不是在寻找关于如何设计我的应用程序的课程，我已经在努力并且我知道必须做什么。正如多次指定的那样，我只需要同时修复服务器。谢谢你。

回答by Alex

I'll say it if noone else will :) Make a separate forms app that does-

如果没有其他人会说，我会说:) 制作一个单独的表单应用程序——

Process[] prs = Process.GetProcesses();

foreach (Process pr in prs)
{
    if (!pr.Responding) 
    {
        try
        {
            pr.Kill();
        }
        catch { }
    }
}

//then to restart-
var process = new Process
{
    StartInfo = new ProcessStartInfo
    {
        FileName = @"C:\yourapp.exe"
    }
};
process.Start();

Obviously oversimplified.

显然过于简单化了。

回答by ΩmegaMan

Move all CPU instensive tasks off of the GUI and invoke back to the gui to report any statuses.

将所有 CPU 密集型任务从 GUI 中移出并调用回 gui 以报告任何状态。

The main app should never freeze. I wrote an app that generated over 500 threads (all at once) and managed them as they asynchronously (.net 2) processed multiple database calls. I believe you need to systematically move all processes to a thread safe situation and remove any direct GUI calls.

主应用程序永远不应该冻结。我编写了一个应用程序，它生成了 500 多个线程（一次全部）并在它们异步 (.net 2) 处理多个数据库调用时管理它们。我相信您需要系统地将所有进程移动到线程安全的情况并删除任何直接的 GUI 调用。

ADDENDUM How did I run 500+ threads:

附录我是如何运行 500 多个线程的：

1. Usage of smart locks done from the beginning on all shared data locations. See my blog articles
   
   Smart Resource Locking in C# .Net for Thread Safe Code
   C# MultiThreading Using ThreadPool, Anonymous Delegates and Locks
   
   
2. Interface created which specified an action operation with data, error status as a properties.
3. Threading base class created (for classes in #4 and #5) which created, started and cleaned up thread opertions. No business logic, just a method of handling threading in one location.
4. Class created based on interface in #2 and also derived from step #3. Class via the interface was required to get data and place data (thread safe via localized lock) and report its status. Class also designed to give up thread cycle if no work done to be done via thread.Sleep(0)instead of busy waiting.
5. Manager class created (which ran on its own thread and derived from #3).It launched 1-N #4 classes to do work. Each of those instances was placed into a working list.
6. Manager class simply browsed the working list for instances which reported their work was done if it was done it moved the instance to the done work. Manager class also kept records of the status (thread safe via locks) to exposed properties (as well as any reported errors by the children instances). Manager gave up thread cycle after each run and slept for 250 milleseconds before starting again.
7. GUI thread had working timers which dealt with getting specific status from the manager. They would extract the data from the manager's properties and invoke back the GUI to target a control (gridview) which reported all statuses and errors.

1. 从一开始就在所有共享数据位置使用智能锁。请参阅我的博客文章
   
   C# .Net 中的智能资源锁定以实现线程安全代码C# 多线程
   使用 ThreadPool、匿名委托和锁
   
   
2. 创建的接口指定了一个带有数据的操作操作，错误状态作为属性。
3. 创建线程基类（用于#4 和#5 中的类），它创建、启动和清理线程操作。没有业务逻辑，只是一种在一个位置处理线程的方法。
4. 基于#2 中的接口创建的类，也是从步骤#3 派生的。需要通过接口类来获取数据和放置数据（通过本地化锁线程安全）并报告其状态。如果没有通过 thread.Sleep(0)而不是忙等待完成的工作，类也被设计为放弃线程周期。
5. 创建的管理器类（它在自己的线程上运行并从 #3 派生）。它启动了 1-N 个 #4 类来完成工作。这些实例中的每一个都被放入工作列表中。
6. 管理器类只是浏览报告其工作已完成的实例的工作列表，如果已完成，它将实例移至已完成的工作。管理器类还将状态记录（通过锁线程安全）记录到暴露的属性（以及子实例报告的任何错误）。经理在每次运行后放弃线程周期并在再次启动之前休眠 250 毫秒。
7. GUI 线程具有处理从管理器获取特定状态的工作计时器。他们将从管理器的属性中提取数据并调用回 GUI 以定位报告所有状态和错误的控件 (gridview)。

By doing that, I was able to achieve individual threads doing specific work and if a process ran into a problem it reported it, or it reported success or failure. Those messages bubbled up to the manager which bubbled up to the timers which bubbled up to the GUI. The gui handled no business logic except to start the mananager and timers.

通过这样做，我能够实现执行特定工作的单个线程，如果进程遇到问题，它会报告它，或者它报告成功或失败。这些消息冒泡到管理器，冒泡到冒泡到 GUI 的计时器。除了启动管理器和计时器之外，gui 不处理任何业务逻辑。

---

---

I get that this doesn't help your situation right now and I feel your pain. But until you are able to seperate out the business logic from the GUI and handle error situations in the threads (background workers) and bubble them up to the GUI, you will still have this frustration with the current code.

我知道这对你现在的情况没有帮助，我能感觉到你的痛苦。但是，直到您能够从 GUI 中分离出业务逻辑并处理线程（后台工作者）中的错误情况并将它们冒泡到 GUI 之前，您仍然会对当前代码感到沮丧。

If something is locking that is a sign that business logic is too tightly coupled with GUI operation and that has to be divorced before you will get the performance you want from the GUI.

如果某些东西正在锁定，则表明业务逻辑与 GUI 操作耦合得太紧密，必须先将其分开，然后才能从 GUI 获得所需的性能。

HTH

HTH

回答by competent_tech

We handle this in a service by having the main service exe be little more than a shell that launches the child threads.

我们通过让主服务 exe 只是一个启动子线程的外壳在服务中处理这个问题。

The child threads are then responsible for reporting back to the parent thread whenever they can to record the last date/time they were "seen".

子线程然后负责向父线程报告，只要它们可以记录他们“看到”的最后日期/时间。

On a regular interval, the service app checks the list of child processes and, if one hasn't been seen for a predetermined period of time (i.e. 2 minutes), but did not report that it had closed down, the parent process will first try to join the thread and shut it down gracefully (usually fails) and then, if that didn't work, aborts the thread.

服务应用程序定期检查子进程列表，如果在预定的时间段（即 2 分钟）内没有看到子进程，但没有报告它已关闭，则父进程将首先尝试加入线程并正常关闭它（通常会失败），然后，如果这不起作用，则中止线程。

We have used this approach successfully for many years, starting when an OCR service that we were running would hang constantly due to bugs in the OCR software.

我们已经成功使用这种方法很多年了，从我们正在运行的 OCR 服务由于 OCR 软件中的错误而不断挂起时开始。