To access wait analysis, right-click on a thread and choose Analyze > Wait. If the thread is waiting for something, Process Hacker will tell you what it is. Otherwise, it will display a message informing you that the thread is not waiting. You should familiarize yourself with some of the most common scenarios, explained below.
Waiting for objects
This occurs due to the
NtWaitForMultipleObjectssystem call. Process Hacker gives you a list of objects which the thread is waiting on. If a program is hanging and you don't know what to do, try searching for one of these objects in the Find Handles and DLLs (Ctrl+F) window. You can proceed from there; try removing/stopping the listed programs or modifying their behaviour.
If an object is unnamed, not to worry; note down the handle value (e.g. 0xb0, 0xd4), go to the Handles tab, make sure Hide unnamed handles is not ticked, and double-click the corresponding handle. You can copy the object address into the Find Handles and DLLs window to see what processes have a handle to that object.
Waiting for a USER message
This usually occurs in GUI-based programs, in GUI threads. It can also be found in COM-based programs. For GUI programs it simply means the program is waiting for some user-related event such as mouse movement or keyboard activity. If it's a problem, try using Spy++ to monitor the messages that the process is receiving.
The message could read waiting for a file or I/O control request. This type of wait means the program is waiting for I/O of some kind, although that doesn't tell you much. However:
- If the file name starts with \Device\NamedPipe, you can search for that using Find Handles and DLLs to see what process is on the other end of the pipe.
- If the file name represents an actual file (C:\some\path\file.txt), the program is trying to do synchronous I/O on it and is waiting for a particular operation to finish. There's no easy way to determine what that operation is. This can also happen with named pipes.
- If the file name starts with \Device and you see I/O control request, it's probably due to the program trying to communicate with a driver, and the driver is simply taking a long time to do whatever it's doing. The kernel-mode stack trace may help you immensely for this case.