Synchronization failure when debugging

Article translations Article translations
Article ID: 173260 - View products that this article applies to.
This article was previously published under Q173260
This article has been archived. It is offered "as is" and will no longer be updated.
Expand all | Collapse all

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.

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.

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.

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.

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.

Properties

Article ID: 173260 - Last Review: February 24, 2014 - Revision: 4.5
APPLIES TO
  • Microsoft Win32 Application Programming Interface, when used with:
    • Microsoft Windows NT 4.0
    • Microsoft Windows 2000 Standard Edition
    • Microsoft Windows XP Professional
    • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
    • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
    • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
    • Microsoft Windows Server 2003, Web Edition
    • Microsoft Windows Server 2003, Datacenter Edition for Itanium-Based Systems
    • Microsoft Windows Server 2003, Enterprise Edition for Itanium-based Systems
    • Microsoft Windows Server 2003, Standard x64 Edition
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003, Datacenter x64 Edition
    • Windows Vista Home Basic
    • Windows Vista Home Premium
    • Windows Vista Enterprise
    • Windows Vista Business
    • Windows Vista Ultimate
    • Windows Vista Starter
    • Windows Vista Business 64-bit Edition
    • Windows Vista Home Premium 64-bit Edition
    • Windows Vista Home Basic 64-bit Edition
    • Windows Vista Ultimate 64-bit Edition
    • Windows Vista Enterprise 64-bit Edition
    • Windows Server 2008 Standard
    • Windows Server 2008 Enterprise
    • Windows Server 2008 Datacenter
    • Windows Server 2008 for Itanium-Based Systems
    • Windows Web Server 2008
Keywords: 
kbnosurvey kbarchive kbapi kbbug kbdebug kbeventlog kbkernbase kbprb kbthreadsync KB173260

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com