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

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

2 голосов
/ 31 января 2011

У меня есть многопоточное приложение C ++, работающее на Windows Server 2003, которое каждые несколько дней сохраняет сбои.Запустив сбои через 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 сообщает только об одном потоке, который не имеет смысла относительно приложения.

Итак, в итоге

  1. кто-нибудь сталкивался с подобной проблемой при вызове WaitForSingleObject?

  2. есть ли какие-либо соображения относительно того, почемуwindbg сообщает об одной теме, когда должно быть намного больше?

Заранее благодарен за любую информацию / помощь

Ответы [ 2 ]

2 голосов
/ 31 января 2011

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

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

WinDbg просто говорит вамПоток, выдавший исключение, запускает ~*k, чтобы отобразить все из них.

1 голос
/ 31 января 2011

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

...