What's wrong with this Windows API call WaitForSingleObject?

Question

The process got crashed unstably in Windows 7. I use !analyze -v command in WinDbg for exception analysis. It tells below information. The exception is actually thrown by WaitForSingleObject function which is called by IrsSim!IrsNet_BlockOutput. WinDbg's exception analysis told me that it was INVALID_POINTER_READ error.

For the calling code, the pChannel->hMutex is not NULL. I already dumped it and checked its value.

IRSNETRET IrsNet_BlockOutput( IRSNET    *pChannel)
{

// Check channel
    IRSNET_CHECK_CHANNEL(pChannel);

// Wait for synchronization mutex
    switch(WaitForSingleObject(pChannel->hMutex, INFINITE))
    {
...
}

<<<<<==========

FAULTING_IP: IrsSim!Channel::SendIrsMessage+285 [s:\som5\ics\scsv\isv\test.u\irssim\irsiftransport.cpp @ 539] 00520ed5 8b06 mov eax,dword ptr [esi]

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 77db4639 (ntdll!RtlDeactivateActivationContextUnsafeFast+0x00000058)
ExceptionCode: c0150010 ExceptionFlags: 00000001 NumberParameters: 3 Parameter[0]: 00000000 Parameter[1]: 07befc58 Parameter[2]: 00000000

DEFAULT_BUCKET_ID: INVALID_POINTER_READ

PROCESS_NAME: IrsSim.exe

ERROR_CODE: (NTSTATUS) 0xc0150010 - The activation context being deactivated is not active for the current thread of execution.

EXCEPTION_CODE: (NTSTATUS) 0xc0150010 - The activation context being deactivated is not active for the current thread of execution.

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 07befc58

EXCEPTION_PARAMETER3: 00000000

STACK_TEXT: 07d2fce0 00520ed5 irssim!Channel::SendIrsMessage+0x285 07d2fd1c 00521072 irssim!CChannelArray::SendIrsMessage+0x132 07d2fd50 0052208a irssim!CNetLibInterface::SendIrsMessage+0xba 07d2fd78 005c01b6 irssim!CSendActivity::Execute+0x76 07d2fdac 005e0b3f irssim!SimulationThreadState::ExecuteOneActivity+0x11f 07d2fdf8 005cc937 irssim!CSimulationSubThreadState::ExecuteState+0x267 07d2fe8c 005ccf02 irssim!ThreadFctSubSimulation+0xf2 07d2fec4 73b1e3ee mfc90u!_AfxThreadEntry+0xf2 07d2ff4c 739f3433 msvcr90!_endthreadex+0x44 07d2ff84 739f34c7 msvcr90!_endthreadex+0xd8 07d2ff90 767d339a kernel32!BaseThreadInitThunk+0xe 07d2ff9c 77d69ed2 ntdll!__RtlUserThreadStart+0x70 07d2ffdc 77d69ea5 ntdll!_RtlUserThreadStart+0x1b

================================

After that I use !teb command to try get more stack information.

0:011> k L=07beec2c 100 ChildEBP RetAddr 07bef54c 76be0bdd ntdll!NtWaitForMultipleObjects+0x15 07bef5e8 767d1a2c KERNELBASE!WaitForMultipleObjectsEx+0x100 07bef630 767d4208 kernel32!WaitForMultipleObjectsExImplementation+0xe0 07bef64c 767f80a4 kernel32!WaitForMultipleObjects+0x18 07bef6b8 767f7f63 kernel32!WerpReportFaultInternal+0x186 07bef6cc 767f7858 kernel32!WerpReportFault+0x70 07bef6dc 767f77d7 kernel32!BasepReportFault+0x20 07bef768 77da21d7 kernel32!UnhandledExceptionFilter+0x1af 07bef770 77da20b4 ntdll!__RtlUserThreadStart+0x62 07bef784 77da1f59 ntdll!_EH4_CallFilterFunc+0x12 07bef7ac 77d76ab9 ntdll!_except_handler4+0x8e 07bef7d0 77d76a8b ntdll!ExecuteHandler2+0x26 07bef7f4 77d76a2d ntdll!ExecuteHandler+0x24 07bef880 77d40143 ntdll!RtlDispatchException+0x127 07bef880 77db4639 ntdll!KiUserExceptionDispatcher+0xf 07befc34 76be0ad7 ntdll!RtlDeactivateActivationContextUnsafeFast+0x58 07befc38 76be0abc KERNELBASE!WaitForSingleObjectEx+0xde 07befc98 767d1194 KERNELBASE!WaitForSingleObjectEx+0xc3 07befcb0 767d1148 kernel32!WaitForSingleObjectExImplementation+0x75

07befcc4 005e3b6e kernel32!WaitForSingleObject+0x12

07befcd4 00520d3b IrsSim!IrsNet_BlockOutput+0x1e

07befd14 00521072 IrsSim!Channel::SendIrsMessage+0xeb 07befd48 0052208a IrsSim!CChannelArray::SendIrsMessage+0x132 07befd70 005c01b6 IrsSim!CNetLibInterface::SendIrsMessage+0xba 07befda4 005e0b3f IrsSim!CSendActivity::Execute+0x76 07befdf0 005cc937 IrsSim!SimulationThreadState::ExecuteOneActivity+0x11f 07befe84 005ccf02 IrsSim!CSimulationSubThreadState::ExecuteState+0x267 07befebc 73b1e3ee IrsSim!ThreadFctSubSimulation+0xf2 07beff44 739f3433 mfc90u!_AfxThreadEntry+0xf2 07beff7c 739f34c7 msvcr90!_endthreadex+0x44 07beff88 767d339a msvcr90!_endthreadex+0xd8 07beff94 77d69ed2 kernel32!BaseThreadInitThunk+0xe 07beffd4 77d69ea5 ntdll!__RtlUserThreadStart+0x70 07beffec 00000000 ntdll!_RtlUserThreadStart+0x1b

====================================>>>>>>

Answer 1

This looks a lot like the 0xC015000f exception encountered in MFC applications ("The activation context being deactivated is not the most recently activated one.")

In all cases where I have encountered this exception, the exception is not the primary issue. It is a side effect of an earlier exception, usually an access violation, where the stack is not unwound properly. Somewhere a call frame that used a macro such as the AFX_MANAGE_STATE macro is missed in the exception handling. The result is that the next time the activation context is manipulated, say by another routine that results in a call to something like AFX_MAINTAIN_STATE2::~AFX_MAINTAIN_STATE2, the system detects a cookie mismatch and throws the exception.

In your case you may either be causing an exception (most likely an AV) in one piece of code that then is manifested by the context exception. To trap the root cause, run the debugger with first chance exception handling enabled. That way the AV that is being trapped elsewhere up the call frame by someone perhaps using a try/catch(...) will be exposed. Since you appear to be threading, you may simply have a race condition on a memory access that causes the primary exception (if that is indeed what is happening).

I see in a previous post: "In fact, this problem comes from porting the program from 64-bit Win XP to 64-bit Win7. The compiler is switched therefore from VC6 to VC9. "

This is not a bug in MFC. MFC 6 did not include the activation context switching code (which is cookie based) that was added, I think, in Visual Studio 2005. So you would not encounter this exception. We too thought the newer MFC had issues but in every case we have encountered, it was our code that caused the problem. The original problems are masked by code flows that started with a try/catch (usually ...) that eventually called code that used one of the MFC manage state macros that then called more code where eventually the AV would occur. Since the catch was way up the stack, and depending on the corruption, not all frames are unwound properly, the back side of the MFC macros are missed (some destructor failed to pop its context). To make matters worse (for debugging), the eventual context crash can occur anywhere in your code (we experienced a lot of them in CWnd's base window message processing routing method). We eventually created another tool for a user to run that would attach itself as a debugger to our (release target) executable that trapped first chance exceptions and created a dmp file so we could find the inital point where the exception occurred since a dump of the context exception almost never was useful since the original source of the problem was long since past execution.