Windows C++ WaitForSingleObject 中的应用程序错误
我有一个在 Windows Server 2003 上运行的 C++ 多线程应用程序，每隔几天就会崩溃一次。通过 Windbg 运行崩溃，我得到以下结果：
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
我对此所做的所有研究几乎都是空的，即我似乎无法解释 Windbg 相对于应用程序本身所说的内容。
FWIW，上述源代码嵌入在 try/catch 块中，因此应用程序因未捕获的异常而崩溃的事实对我来说表明是非常低级别的异常类型。
此外，此应用程序/进程附加了 4 个线程，通常更多。但 winbdg 仅报告一个线程，这对于应用程序来说没有意义。
因此，总而言之，
有人对 WaitForSingleObject 调用遇到过类似问题吗？
是否需要注意为什么 Windbg 在应该有更多线程时报告单个线程？
预先感谢您提供任何信息/帮助
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
has anyone had a similar issue with the WaitForSingleObject call?
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
STATUS_BREAKPOINT 表示 CPU 命中了
int 3指令；除非您正在运行检查构建，否则这种情况不会通过操作系统发生（即，当您断言失败时会发生这种情况）。您正在运行检查构建吗？WinDbg只是告诉你抛出异常的线程，运行
~*k来显示所有的异常。STATUS_BREAKPOINT means that the CPU hit an
int 3instruction; 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?WinDbg just tells you the thread that threw the exception, run
~*kto display all of them.崩溃可能是在不同的线程中。在故障转储上使用
.ecxr来获取实际崩溃的线程。如果~只给您一个线程，则意味着在故障转储进程附加到服务之前该进程几乎已经消失了。在这种情况下，您需要将调试器附加到正在运行的应用程序，然后等待崩溃发生。The crash is probably in a different thread. Use
.ecxron 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.