Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

Synchronization failure when debugging


View products that this article applies to.

Symptoms

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.

↑ Back to the top


Cause

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.

↑ Back to the top


Resolution

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.

↑ Back to the top


Status

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.

↑ Back to the top


More information

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.

↑ Back to the top


Article Info
Article ID : 173260
Revision : 9
Created on : 1/1/0001
Published on : 1/1/0001
Exists online : False
Views : 64