Анализ файлов .dmp

Question

Я пытаюсь решить проблему ошибки времени выполнения c ++ exe, которая возникает только в рабочей среде.Я новичок в C ++ и windbg, но здесь я проиллюстрирую анализ.Я был бы очень признателен, если бы кто-нибудь указал мне на то, как и при каких условиях возникает эта ошибка, и, что более важно, как мне выяснить, какая строка кода вызывает ее.Я читаю много форумов, НО Если я открою файл dmp в VS 2008, у меня есть файл pdb локально, а исполняемый файл локально, НО я никогда не смогу включить опцию меню «Перейти к исходному коду».Быстрый ответ о том, как проанализировать этот файл .dmp и как его понять, будет высоко оценен. Спасибо!

---

• *
• Анализ исключений *
• *

  ---

Ошибка GetPageUrlData, сервер вернул HTTP-статус 404 Запрошен URL-адрес: http://watson.microsoft.com/StageOne/MYServer_exe/0_0_0_0/MyServer_exe/0_0_0_0/000194ab.htm?Retriage=1

FAULTING_IP: Myserver + 194ab 004194ab c6040100 mov байт ptr [ecx + eax], 0

EXCEPTION_RECORD: ffffffff - (.exr 0xffffffffffffffff) ExceptionAddress: 004194ab (Myserver + 0x000194ab) ExceptionCode: c0000005 (нарушение доступа) ExceptionFlags: 00000000 NumberParameters: 2 Параметр: 2 параметр [2] [параметр: 00000000 Попытка записи по адресу 00000000

DEFAULT_BUCKET_ID: NULL_POINTER_WRITE

PROCESS_NAME: Myserver.exe

ОШИБКА_КОД:: (NTSTATUS) 0xc0000renx 0 0xx 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6 6 6 6 6 6 6 6 0 0 0 6 6 6 0 0 0 0 0 0 0 0 6 0 0 0 0 0 0 0 0 0 0 6 00 000 005% в0x% 08lx.Память не может быть% s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Инструкция в 0x% 08lx ссылается на память в 0x% 08lx.Память не может быть% s.

EXCEPTION_PARAMETER1: 00000001

EXCEPTION_PARAMETER2: 00000000

WRITE_ADDRESS: 00000000

FOLLOWUP_IP: MYServer + 194404 по 440 байт на 440 байт по 440 байт на 4 400 байт по 440 байт на 440 байт по 440 байт на 4 050 4 194 байт по 450 байт на 440 байт по 440 байт на 4 400 байт по 1950 копеptr [ecx + eax], 0

MOD_LIST:

NTGLOBALFLAG: 0

APPLICATION_VERIFIER_FLAGS: 0

FAULTING_THREAD: 000004e0

PRMS: NULL_POINTER_WRITE

BUGCHECK_STR: APPLICATION_FAULT_NULL_POINTER_WRITE

LAST_CONTROL_TRANSFER: от 00418a4e до 004194ab

.Следующие кадры могут быть неправильными.087ffa74 00418a4e 0a73b070 087ffc6c 087ffd8c MYSERVER + 0x194ab 087ffb64 00410767 0a73b070 087ffd74 087ffd8c MYSERVER + 0x18a4e 087ffc6c 0041089b 0a73b0f8 0a727a78 0a73b108 MYSERVER + 0x10767 087ffd74 00433913 0a73b0f8 0a727a78 0a73b108 MYSERVER + 0x1089b 087ffe58 0042fbf3 0a73b0f8 0a727a78 00000044 MYSERVER + 0x33913 087fffb8 7d4dfe37 000006a0 00000000 00000000 MYSERVER + 0x2fbf3 087fffec 000000000042fae0 000006a0 00000000 kernel32! BaseThreadStart + 0x34

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: Myserver + 194ab

FOLLOWUP_NAME: MachineOwner

1058 * * 10571059 * IMAGE_NAME: Myserver.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4c2123df

STACK_COMMAND: ~ 86 с;.ecxr;kb

FAILURE_BUCKET_ID: NULL_POINTER_WRITE_c0000005_Myserver.exe! Неизвестно

BUCKET_ID: APPLICATION_FAULT_NULL_POINTER_WRITE_Myserver + 194ab

10 * * * *6868* 1068 *1068* 1068 *1068* 1068 *1068* 1068 *1068* 1068 *1068* 1068 *1068* 1068 *1068* 1068 *1068* 1068 *1068* 1068 *1068* 1068 * Following

Answer 1

k даст вам трассировку стека текущего остановленного в потоке.
~*kb даст вам трассировку стека всех потоков

Символы

Вам может понравитьсячтобы задать путь поиска символов для включения символов MS, это позволит улучшить трассировку стека.

Вы можете делать это каждый раз, используя .sympath srv*C:\Symbols*http://msdl.microsoft.com/download/symbols или более постоянное значение _NT_SYMBOL_PATH environment var (скажем, как системную переменную).) до srv*C:\Symbols*http://msdl.microsoft.com/download/symbols

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

.symfix+ c:\symbols
.reload /f

Crash line

EXCEPTION_RECORD: ffffffff -(.exr 0xffffffffffffffff) ExceptionAddress: 004194ab FAULTING_IP: Myserver + 194ab 004194ab c6040100 mov byte ptr [ecx + eax], 0

Если все, что вам нужно, - это строка сбоя, тогда есть приложение 'CrashFinder ', который загрузит ваше приложение и pdb и позволит вам ввести это 004194ab, чтобы сообщить о линии сбоя.

Answer 2

Если вам больше нравится VS, не сдавайтесь. Вы делаете видите разборку и стек, и вам не хватает только символов? Вы щелкаете по кадру стека, который является вашим модулем, и все еще не видите код? Можете ли вы даже увидеть кадр стека, который находится внутри вашего модуля? Вы установили доступ к публичным символам MS? (вы, вероятно, должны в любом случае, даже с WinDbg). WinDbg сообщает о символах стека? (они не указаны в фрагменте, который вы вставили здесь). Если нет, то, скорее всего, это проблема с символами. Есть способы диагностировать их как на WinDbg, так и на VS. Вы проверяли «информацию о загрузке символов» для модулей, которые вы хотите отлаживать? (Самый простой способ в VS - щелкнуть правой кнопкой мыши модуль в окне модулей).

Есть советы, которые нужно дать на основе любой комбинации ответов на этот вопрос. Если вы предоставите более подробную информацию, это поможет сфокусировать совет.

Answer 3

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

Для аварийного дампа, после того как вы установили пути к символам и исходным кодам и загрузили файл дампа, вы найдете полезную команду: !analyze -v

И из вставленного вами отчета проверьте строку: STACK_COMMAND: ~86s; .ecxr ; kb В этой строке указывается нить, вызвавшая ошибку (86). Просто пройдите эту строку в командном окне, чтобы получить стек для этого потока: ~86s; .ecxr ; kb