Wait analysis reference

First unread post1 postPage 1 of 1

Wait analysis reference

Unread postby wj32 » Mon Jan 17, 2011 11:25 am

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.

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 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

WAUserMessage.png

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

WAIo.png

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.
User avatar
wj32 offline
Posts: 721
Location: Australia
OS: Windows

First unread post1 postPage 1 of 1

Who is online

Users browsing this forum: No registered users and 2 guests