Detect when an application stops responding, kill and restart

Question

I am developing a high-performance application, which leads to the fact that the main process seems to stop responding and crashes - from time to time - due to overload (I get the Close Application dialog box, so the application never quits by itself, it just hangs, what annoys)

I welcome any clean way to factor when an application is frozen, so I can use BAT (or another) to automatically kill the process and restart.

Of course, this is a temporary solution when auditing the application, but at the same time it is very convenient.

TieBreaker: By the way, is there a way to override the Exec windows screen and just exit the application ??? It most often causes irritation.

EDIT:
FOR GOD SAKE: IS freaking frozing application, THOUGH each task runs in BG Workers and threads !!! And I clarified this in the comments. Come on, I'm not so stupid. Just that your application works with working BG, this does not mean that it never freezes! And as I said, please just answer my question, I'm not looking for lessons on how to develop an application that I'm already working on, and I know what needs to be done. As indicated by MANY times, I just need a fix on the server in the meantime. Thanks.

Answer 1

I will say this if no one else does :) Create a separate forms application 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 simplified ..

Answer 2

Move all CPU computing tasks from the graphical user interface and return to gui to report any statuses.

The main application should never freeze . I wrote an application that generated more than 500 threads (all at once) and managed them, because they processed several database queries asynchronously (.net 2). I believe that you need to systematically move all processes to a safe situation and delete any direct GUI calls.

ADD How I launched 500+ threads:

• The use of smart locks performed from the very beginning in all places of common data. See My Blog Articles
  
  Intelligent Resource Lock in C # .Net for secure thread code
  C # MultiThreading using ThreadPool, anonymous delegates and locks
  
  
• An interface was created that specified the operation of the action with data, the status of the error as a property.
• The base class Threading (for classes in # 4 and # 5) was created, which created, started, and cleared thread operations. There is no business logic, just a method of processing threads in one place.
• The class created on the basis of the interface in # 2, as well as the one obtained from step # 3. The class had to receive data through the interface and put the data (thread-safe through a localized lock) and report its status. The class is also designed to discard the thread loop if no work is done using thread.Sleep (0) rather than waiting.
• A manager class has been created (which starts in its thread and is obtained from # 3). Launched 1-N # 4 classes to work. Each of these instances was placed on a worklist.
• The manager class simply looked at the worklist for instances that reported that their work was done, if it was done, this moved the instance to the work done. The Manager class also wrote status (thread safe through locks) to public properties (as well as any reported errors by children instances). The manager abandoned the thread cycle after each run and slept for 250 milliseconds before starting again.
• There were working timers in the GUI thread that concerned receiving a certain status from the manager. They will extract data from manager properties and return a graphical interface for managing the object (gridview), which reports all statuses and errors.

Thus, I was able to ensure that individual threads do a certain job, and if in the process there was a problem reporting this, or success or failure was reported. These messages bounced to the manager, who bounced to the timers that reached the GUI. Gui did not process business logic except to run mananager and timers.

---

I understand that this does not help your situation now, and I feel your pain. But until you can separate the business logic from the graphical interface and process situations with errors in the flows (background workers) and output them to the graphical interface, you will still encounter this disorder with the current code.

If something is blocking, which is a sign that the business logic is too closely related to the graphical interface and needs to be parted before you get the desired result from the graphical interface.

NTN

Answer 3

We handle this in the service, since the main exe service will be slightly larger than the shell that starts the child threads.

Then the child threads are responsible for reporting to the parent thread when they can record the last date / time when they were “visible”.

In a regular interval, the service application checks the list of child processes and, if one of them was not detected within a given period of time (i.e. 2 minutes), but did not report that it was closed, the parent process will first try to join the thread and gracefully close it (usually fails), and then, if this does not work, cancel the thread.

We have successfully used this approach for many years, starting with the fact that the OCR service we worked for constantly hung up due to bugs in the OCR software.