Synchronization failure when debugging

Threads waiting on a synchronization object may not be released (for example, by PulseEvent() or a SetEvent()/ResetEvent() combination) while you are debugging an application under Windows NT.

This symptom is an anomaly related to the debug environment under Win32. It will only occur under a Win32 debugger, including any version of the Visual C++ debugger and WinDBG.

Placing Sleep(0) before the PulseEvent() or SetEvent()/ResetEvent() calls will probably avoid this problem, but this is not guaranteed either. Unfortunately, there is no guaranteed workaround for this situation.

Note that this symptom is not a bug, but rather a side effect of debugging under Windows NT. There are no current plans to change this behavior. It is also important to note that this anomaly will not occur outside of a debug environment.

PulseEvent() may fail to release a thread waiting on an event object while the application is running in a debug environment. This is true regardless of whether or not the code is compiled with debug information. This is also regardless of whether the debuggee is executed by the "go" command or by being "single stepped."

The problem is more likely to occur if more than one thread is waiting on the same event. Failure to release the waiting thread becomes more likely still if there are debug events occurring in these threads, such as those caused by OutputDebugString(). Placing a call to OutputDebugString() directly before a call to PulseEvent() is an effective way of regularly causing a waiting thread not to wake up in the debug environment.

This happens because the Win32 debug environment commonly suspends threads. When this happens, it pulls the thread out of its current state and causes it to wait on a "suspend" event. This sort of suspend happens internally on each and every debug event. When resumed, the threads are put back into their previous wait state. If the PulseEvent() occurs while a thread is in a debug suspended state, the pulse is lost for that thread. This is also true of a thread suspended by the application using SuspendThread().

This behavior is not limited to PulseEvent(). Waiting threads are susceptible to the "debug suspend" in other scenarios as well, including a quick SetEvent()/ResetEvent() pair.

As mentioned above, one possible workaround to this problem is to put a Sleep(0) call before any PulseEvent() or SetEvent() call. This solves the problem in most cases, because it gives threads being resumed an opportunity to start waiting again.

It is important to note that this anomaly will not occur outside of a debug environment.