Wait analysis reference
Posted: 17 Jan 2011 11:25
Note
Wait analysis is a simple extension of stack tracing and is only useful on 32-bit systems. You should read the thread stacks article first. |
Waiting for objects
This occurs due to the
NtWaitForSingleObject
or NtWaitForMultipleObjects
system 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.
I/O
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.