Ошибка приложения Windows C++ в WaitForSingleObject

У меня есть многопоточное приложение на C++, работающее на Windows Server 2003, которое продолжает сбой каждые пару дней. Запуск аварии через WinDbg, я получаю следующие результаты:Ошибка приложения Windows C++ в WaitForSingleObject

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 сообщает об одной нити, когда должно быть намного больше?

Заранее спасибо за любую информацию/помочь

источник

2011-01-31 David Brown

«Один или несколько аргументов недействительны», похоже, указывает на то, что один или несколько аргументов недействительны. –

Вы уверены, что FFDecoderMutex является дескриптором? Возможно, вам нужно передать свой адрес. – Benoit

Похоже, что ваш объект mutex был разрушен, и вы пытаетесь его заблокировать. Это полный дамп памяти, возможно, вы можете проверить эту переменную и проверить, является ли она правильной или нет. – Naveen

STATUS_BREAKPOINT означает, что процессор ударил int 3 инструкции; это не произойдет через ОС, если вы не выполнили проверочную сборку (т. е. это то, что происходит, когда вы не выполняете Assert). Вы используете проверенную сборку?

2) любые головки вверх относительно того, почему windbg переписывает одну нить, когда должно быть много больше?

WinDbg просто сообщает вам нить, которая выбрала исключение, запустите ~*k, чтобы отобразить все из них.

источник

2011-01-31 16:10:03

Эй, Пол, спасибо за быстрый ответ. В исходном коде нет явного ASSERT stmt, не знаю, какие опции управляют тем, что в сборке (я использую VS2005 SP1). Я проверил, что это единственный поток, показывающий (сделал ~ *, а также отобразил окно процессов/потоков). –

Если вы используете проверенную сборку (http://www.osronline.com/DDKx/ddtools/checked_6dir.htm) ОС, сама ОС будет бросать int 3, когда вы неправильно используете API. Вы действительно не должны использовать проверочную сборку на производственном сервере, хотя –

Еще раз спасибо Пол за ответ. Его производственный сервер, не проверенная сборка Windows 2003 Server. –

Ошибка, возможно, в другой теме. Используйте .ecxr на аварийной дампе, чтобы добраться до фактической неисправной нити. Если ~ дает вам только один поток, это означает, что процесс был почти ушел до того, как процесс дампа сбоя привязан к сервису. В этом случае вам нужно будет подключить отладчик к запущенному приложению и просто ждать, пока авария произойдет вживую.

источник

2011-01-31 17:11:34 John

У меня есть настройка windbg как отладчик JIT, поэтому, когда приложение разбило windbg, он захватил процесс. Даже если я запускаю приложение под управлением windbg, кажется, что я получу тот же результат, то есть приложение почти исчезнет к моменту, когда windbg получит контроль из-за необработанного исключения. –

С отладкой JIT существует гораздо более длинное окно времени, когда все может измениться. Если вы присоедините windbg к запущенному процессу (вы можете использовать -g -G, чтобы он работал), это окно становится намного меньше. – John

Джон, спасибо, плывите головы. я попробую –

Ошибка приложения Windows C++ в WaitForSingleObject

ответ

Смежные вопросы