I am refactoring a custom process monitoring application for a client that is deployed in Windows Server 2008 R2 and Windows Server 2012 environments.
The monitoring application needs to identify crashed, unresponsive processes (identified as "Not Responding" in the Task Manager), forcefully kill them and restart. The processes monitored can be either Console or Win32-based applications, predominantly Console-based.
The Process.Responding property is of no use in this particular occasion as it determines if the UI is responding (potentially using a similar method "under the hood" as the one below to update this property).
The IsHungAppWindow method is also of no use if it were imported as the Console-based applications do not fulfill the following criteria:
An application is considered to be not responding if it is not waiting for input, is not in startup processing, and has not called PeekMessage within the internal timeout period of 5 seconds.
The Status property of the Win32_Process
WMI class is of no use were I monitoring processes using the WMI system classes since:
This property is not implemented and does not get populated for any instance of this class. It is always NULL.
The ExecutionState property of the Win32_Process
WMI class is of no use as it appears not to be implemented also. Although not explicitly stated, after running local tests it repeatedly returns NULL
and a third party indicates this.
How can I reasonably determine whether or not processes are unresponsive?
The best answer and solution I can determine is to monitor
Application Error
andApplication Hang
events from the Windows Event Viewer Application log.As of .NET 3.5, a handy class was implemented to avoid reading and filtering the entire event logs: EventLogWatcher allowing to watch for specific events instead.
Here is a very basic example, filtering by
EventID
,Level
andApplicationName
using an XPath query:This can easily be expanded upon to filter by the fully qualified, faulty application execution path
Properties[10]
.