Общие сведения о дампе сбоя из приложения Visual C ++

ОБНОВЛЕНИЕ

Благодаря обратной связи, приведенной ниже, я смог сосредоточиться на ADPlus.vbs, который является частью инструментов отладки для Windows.

Не забудьте настроить _NT_SYMBOL_PATH перед его запуском.

Используя это, мы смогли увидеть приложение гораздо яснее и яснее, чем когда-либо при использовании обычных дампов, создаваемых Windows при сбое приложения.

Большое спасибо всем за ответы.

ОРИГИНАЛЬНЫЙ ВОПРОС

У нас есть серверное приложение, написанное на Visual C ++, которое несколько раз (относительно редко) дает сбой на сайтах клиентов. Мы не смогли понять, почему это происходит, на основе просмотра наших собственных файлов журналов, поэтому следующим шагом будет рассмотрение аварийных дампов.

Мы только что намеренно добавили ошибку в наше приложение (нулевой указатель), чтобы мы могли сгенерировать аварийный дамп и проверить ценность созданных дампов, но пока я не могу понять, что я собой представляю. видя.

Я думаю, что мой первый вопрос заключается в том, правильно ли я настроил WinDbg (другой разработчик загружает дамп в Visual Studio 2010 и видит те же ошибки, поэтому я предполагаю, что все в порядке, или мы оба ошибаемся: )) - а затем следующий вопрос: как мне понять, что он мне говорит.

Основная путаница заключается в том, что дамп, кажется, сообщает мне, что достиг точки останова, что кажется мне странным, поскольку отладчик не был подключен.

Когда произошел сбой, приложение работало в системе Windows Server 2003. Я считаю, что правильно указал WinDbg на файл PDB для DLL и EXE.

FAULTING_IP: 
ntdll!DbgBreakPoint+0
7c81a3e1 cc              int     3

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 7c81a3e1 (ntdll!DbgBreakPoint)
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 3
   Parameter[0]: 00000000
   Parameter[1]: 8779fdb0
   Parameter[2]: 00000003

DEFAULT_BUCKET_ID:  STATUS_BREAKPOINT

PROCESS_NAME:  CallPlusServerLauncher.exe

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

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

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  8779fdb0

EXCEPTION_PARAMETER3:  00000003

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

ADDITIONAL_DEBUG_TEXT:  Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[ffffffff]

FAULTING_THREAD:  ffffffff

PRIMARY_PROBLEM_CLASS:  STATUS_BREAKPOINT

BUGCHECK_STR:  APPLICATION_FAULT_STATUS_BREAKPOINT

STACK_TEXT:  
1bd0ffc8 7c83fe08 00000005 00000004 00000001 ntdll!DbgBreakPoint
1bd0fff4 00000000 00000000 00000000 00000000 ntdll!DbgUiRemoteBreakin+0x36


FOLLOWUP_IP: 
ntdll!DbgBreakPoint+0
7c81a3e1 cc              int     3

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  ntdll!DbgBreakPoint+0

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: ntdll

IMAGE_NAME:  ntdll.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  49900d60

STACK_COMMAND:  ddS 1bd10000 1bd0c000 ; dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ~439s; .ecxr ; kb

BUCKET_ID:  MANUAL_BREAKIN

FAILURE_BUCKET_ID:  STATUS_BREAKPOINT_80000003_ntdll.dll!DbgBreakPoint

WATSON_STAGEONE_URL:      http://watson.microsoft.com/StageOne/CallPlusServerLauncher_exe/0_0_0_0/4df87414/ntdll_dll/5_2_3790_4455/49900d60/80000003/0001a3e1.htm?Retriage=1

Followup: MachineOwner

c++ crash-dumps
person Matt Peddlesden    schedule 15.06.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

DbgBreakPoint - мне кажется, что вы прервали выполнение с помощью удаленного отладчика.

Если вы этого не сделали, то я видел, как DbgBreakPoint появляется, когда у вас включены кодовые страницы (Edit: я имел в виду page heap) (вы должны знать, сделали ли вы это) и было обнаружено недопустимый доступ к памяти.

person Dennis    schedule 15.06.2011
comment
Определенно не было вызвано удаленным отладчиком. Мы не знаем, что мы включили кодовые страницы, нет, однако обнаружение недействительного доступа к памяти, по-видимому, не будет слишком далеким от истины с продолжающейся ссылкой на нулевой указатель? Есть ли способ получить дамп, чтобы мы могли понять, где имел место недействительный доступ к памяти? - person Matt Peddlesden; 15.06.2011
comment
@Matt Peddlesden - Включите кодовые страницы и запустите их с ADPlus.exe в аварийном режиме. После этого ADPlus должен сгенерировать полный дамп при возникновении недействительного доступа. - person Dennis; 15.06.2011
comment
Честно говоря, не совсем уверен, что вы имеете в виду в отношении кодовых страниц - разве дело не в наборе символов? Например. 1250 - это европа, 437 - это США? - person Matt Peddlesden; 15.06.2011
comment
Извините, куча страниц, а не кодовых страниц! Неудивительно, что вы запутались. В основном добавляет ограничивающие области известных шестнадцатеричных шаблонов в начало и конец выделенных областей памяти. Ознакомьтесь с этими ресурсами support.microsoft.com/kb/286470 и msdn.microsoft.com/en-us/library/ff549561%28v = vs.85% 29.aspx. ADplus является частью инструментов отладки для Windows, он у вас уже должен быть, учитывая, что вы используете WinDBG. - person Dennis; 15.06.2011
comment
Ага, хорошо, да, я нашел adplus - я сейчас прочитаю кучу страниц, спасибо, Деннис! - person Matt Peddlesden; 15.06.2011
comment
Использование ADPlus кажется лучшим вариантом, он указал нам прямо на то, где находится наша фальшивая ошибка, поэтому мы продолжим в этом направлении. Спасибо за помощь, Деннис! - person Matt Peddlesden; 15.06.2011
comment
Хорошая вещь. Надеюсь, что это работает для вас. Даже использование этих инструментов может не выявить первопричину, а укажет только на то место, где плохая память может вызвать проблемы. - person Dennis; 15.06.2011

arrow_upward
0
arrow_downward

Утверждения также могут вызывать исключение точки останова. Например, я (слишком часто) видел, как они выходили из кучи, проверяя удаление, когда куча была повреждена двойным удалением или переполнением. Но только со средой выполнения отладки, которую я подумал, разве это то, что вы развернули?

person Pete    schedule 15.06.2011
comment
Хорошо это или плохо, но, по крайней мере, в нашем коде нет утверждений, а ошибка, которую мы ввели, была простой проблемой с нулевым указателем. Спасибо за ответ. - person Matt Peddlesden; 15.06.2011