Windows C++ app error in WaitForSingleObject

I've got a C++ multithreaded app running on Windows Server 2003 that keeps crashes every couple days. Running the crash thru windbg, I get the following results:

FAULTING_IP: 
+2502faf01a7df58
00000000 ??              ???

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 0

FAULTING_THREAD:  00001520

DEFAULT_BUCKET_ID:  STATUS_BREAKPOINT

PROCESS_NAME:  FixFastMDP.exe

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid

MOD_LIST: <ANALYSIS/>

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

PRIMARY_PROBLEM_CLASS:  STATUS_BREAKPOINT

BUGCHECK_STR:  APPLICATION_FAULT_STATUS_BREAKPOINT

LAST_CONTROL_TRANSFER:  from 7c827d0b to 7c8285ec

STACK_TEXT:  
0293ee78 7c827d0b 77e61d1e 00000484 00000000 ntdll!KiFastSystemCallRet

0293ee7c 77e61d1e 00000484 00000000 0293eec0 ntdll!NtWaitForSingleObject+0xc

0293eeec 77e61c8d 00000484 00001388 00000000 kernel32!WaitForSingleObjectEx+0xac

0293ef00 00403bce 00000484 00001388 108744c3 kernel32!WaitForSingleObject+0x12

0293feec 7c83a827 0159ba50 7c889080 0016b278 FixFastMDP!decoderItThread+0x7e 
[c:\gszdvmt\trading\serverside\globex\fixfastmdp\mdpmulticast.cpp @ 732]

0293ff44 7c83aa0b 00403b50 0159ba50 00000000 ntdll!RtlpWorkerCallout+0x71

0293ff64 7c83aa82 00000000 0159ba50 0016b278 ntdll!RtlpExecuteWorkerRequest+0x4f

0293ff78 7c839f60 7c83a9ca 00000000 0159ba50 ntdll!RtlpApcCallout+0x11

0293ffb8 77e64829 00000000 00000000 00000000 ntdll!RtlpWorkerThread+0x61

0293ffec 00000000 7c839efb 00000000 00000000 kernel32!BaseThreadStart+0x34



STACK_COMMAND:  ~0s; .ecxr ; kb

FOLLOWUP_IP: 
FixFastMDP!decoderItThread+7e [c:\gszdvmt\trading\serverside\globex\fixfastmdp\mdpmulticast.cpp @ 732]
00403bce 3d02010000      cmp     eax,102h

FAULTING_SOURCE_CODE:  
   728:         ////

   729:         // call the decoderit() 开发者_开发技巧func with the message

   730:         DWORD waitError = WaitForSingleObject( FFDecoderMutex, MUTEX_TIMEOUT );

   731:         {

>  732:             if( waitError == WAIT_TIMEOUT )

   733:             {

   734:                 logMsg( "[decoderItThread] Mutex Error: WAIT_TIMEOUT" );

  735:          }

   736:             else if( waitError == WAIT_ABANDONED )

   737:             {



SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  fixfastmdp!decoderItThread+7e

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: FixFastMDP

IMAGE_NAME:  FixFastMDP.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4d41d25b

FAILURE_BUCKET_ID:  STATUS_BREAKPOINT_80000003_FixFastMDP.exe!decoderItThread

BUCKET_ID:  APPLICATION_FAULT_STATUS_BREAKPOINT_fixfastmdp!decoderItThread+7e

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/FixFastMDP_exe/0_0_0_0/4d41d25b/unknown/0_0_0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1

All the research I've done on this has pretty much come up empty, i.e. I can't seem to interpret what windbg is saying relative to the app itself.

FWIW, the above source code is embedded in a try/catch block, so the fact that the app is crashing on an exception that is not being caught indicates to me a very low level type of exception.

Also, this app/process has 4 threads attached to it, usually more. But winbdg is reporting only a single thread which doesn't make sense relative to the app.

So, in summary

1. has anyone had a similar issue with the WaitForSingleObject call?

2. any heads up regarding why windbg is reporting a single thread when there ought to be a lot more?

Thanks in advance for any info/help

STATUS_BREAKPOINT means that the CPU hit an int 3 instruction; this wouldn't happen via the OS unless you were running checked build (i.e. this is what happens when you fail an Assert). Are you running checked build?

2)any heads up regarding why windbg is reproting a single thread when there ought to be alot more?

WinDbg just tells you the thread that threw the exception, run ~*k to display all of them.

The crash is probably in a different thread. Use .ecxr on a crash dump to get to the actual crashing thread. If ~ gives you only one thread it means that the process was alreay almost gone before the crash dump process attached to the service. In this case you will need to attach a debugger to the running application and just wait for the crash to happen live.