WaitForSingleObjectでのWindows C++アプリケーションのエラー

Windows Server 2003上で動作するC++マルチスレッドアプリケーションがあり、数日おきにクラッシュします。 windbgのスルークラッシュを実行して、私は次のような結果を得る：私はこの上で行ってきたすべての研究はかなり空を打ち出しているWaitForSingleObjectでのWindows C++アプリケーションのエラー

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ブロックに埋め込まれているため、キャッチされていない例外でアプリケーションがクラッシュしているという事実は、私には非常に低いレベルの例外タイプを示しています。

また、このapp/processには4つのスレッドが接続されています。しかし、winbdgはアプリに対して相対的に意味のない単一のスレッドしか報告していません。

ので、要約で

は、誰もがWaitForSingleObject関数呼び出しと同様の問題がありましたか？
windbgが1つのスレッドを報告している理由は何ですか？

あらゆる情報/助けを事前に感謝

出典

2011-01-31 David Brown

"1つ以上の引数が無効です"は、1つ以上の引数が無効であることを示しているようです。 –

FFDecoderMutexはハンドルですか？多分あなたはその住所を渡す必要があります。 – Benoit

あなたのミューテックスオブジェクトが破壊され、あなたがそれをロックしようとしているようです。それは完全なメモリダンプですか、おそらくあなたはその変数を検査し、それが適切であるかどうかをチェックすることができます。 – Naveen

STATUS_BREAKPOINTは、CPUがint 3命令を打つことを意味します。あなたがチェックビルドを実行していない限り、これはOS経由では起こりません（つまり、Assertに失敗した場合に起こることです）。チェックビルドを実行していますか？

2）多くのことをする必要があるときにwindbgが1つのスレッドを再読み込みしている理由について、

WinDbgは例外をスローしたスレッドを通知します。すべてを表示するには~*kを実行してください。

出典

2011-01-31 16:10:03

ヘイ・ポール、すばやい返信をありがとう。ソースコードに明示的なASSERT stmtはありません。ビルド時にどのオプションがVS2005 SP1を使用しているかはわかりません。私は、これが唯一のスレッドであることを確認しました（〜*を行い、プロセス/スレッドウィンドウを表示しました）。 –

OSのチェックビルド（http://www.osronline.com/DDKx/ddtools/checked_6dir.htm）を実行している場合、APIを誤用するとOS自体がint 3を投げます。あなたは実際にプロダクションサーバでチェックビルドを使用してはいけません。 –

返信のためにPaulに感謝します。そのプロダクションサーバー、Windows 2003 Serverのチェックされていないビルド。 –

クラッシュはおそらく別のスレッドにあります。クラッシュダンプに.ecxrを使用すると、実際のクラッシュスレッドにアクセスできます。 ~にスレッドが1つしかない場合は、サービスに添付されているクラッシュダンププロセスの前にプロセスがほとんどなくなっていることを意味します。この場合、実行中のアプリケーションにデバッガを接続して、クラッシュが実際に発生するまで待つ必要があります。

出典

2011-01-31 17:11:34 John

私はJITデバッガとしてwindbgセットアップを持っています。そのため、アプリケーションがクラッシュしたときにwindbgがプロセスをキャプチャしました。 windbgの下で実行されているアプリを起動しても、同じ結果が得られるように見えます。つまり、処理されていない例外のためにwindbgが制御されるまでにアプリはほとんどなくなります。 –

JITデバッグでは、状況が変わる可能性のある時間がかなり長くなります。実行中のプロセスにwindbgを付けると（-g -Gを使用して実行し続けることができます）、そのウィンドウははるかに小さくなります。 – John

ジョン、ありがとう、ヘッドアップ。私はそれを試してみます –

WaitForSingleObjectでのWindows C++アプリケーションのエラー

答えて

関連する問題