Окно дизассемблирования VS показывает весь EXE?

Клиент запускает программу моей компании, и она останавливается, прежде чем что-то получить. Они отправили эту информацию из журнала событий Windows:

faulting module program.exe, version 1.2.3.4, fault address 0x00054321.

Нам больше нечего делать, поэтому в качестве последней попытки я попытался выяснить, смогу ли я найти, где находится эта позиция в дизассемблере. Я запускаю программу через Visual Studio, ставлю ее на паузу, смотрю на окно Disassembly и пытаюсь прокрутить до этого адреса, но все, что я там получаю, это:

00054321  ???              
00054322  ???              
00054323  ???              
00054324  ???              
00054325  ???              
00054326  ???              
00054327  ???              
00054328  ???              
00054329  ???              
0005432A  ???

Это может быть связано с тем, что Visual Studio дизассемблирует только часть EXE рядом с позицией паузы или что-то в этом роде? Мне трудно просмотреть, сколько на самом деле разобрано, потому что полоса прокрутки работает не полностью. (Я не могу захватить и переместить положение прокрутки; мне нужно прокручивать построчно или по страницам.)

Спасибо за любое понимание, которое у вас может быть!


visual-studio disassembly
person Owen    schedule 29.01.2009    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Адрес ошибки также может быть вызван проблемой повреждения стека, т.е. обратный адрес может быть скомпрометирован и возвращен на неправильный адрес @ 0x54321. Кроме того, в зависимости от используемой технологии (Java, .NET) код может менять свое положение между запусками.

Visual Studio производит разбор всего пространства процесса. ???? означает, что позиция недоступна.

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

person QbProg    schedule 29.01.2009
comment
Спасибо! Есть ли простой способ заставить пользователя получить такой дамп ядра? У меня нет доступа к их машине. - person Owen; 30.01.2009
comment
Это не очень просто, особенно на Vista. И вам нужно иметь именно PDB-файлы поставляемой версии. Лучше попробуйте воспроизвести баг на своей машине, если он станет частым. - person QbProg; 31.01.2009

arrow_upward
2
arrow_downward

WinDbg может быть вашим другом здесь, там вы можете загрузить свой исполняемый файл и символы (.pdb), если вы можете получить (мини) дамп, как говорит QbProg, это определенно облегчит поиск. Но у меня был опыт, когда это было проще сделать в WinDbg.

person Fredrik Jansson    schedule 29.01.2009
comment
WinDbg был великолепен; Спасибо за совет. Мы отправили им .pdb и отладочный .exe и попросили их запустить его, и это дало достаточно информации, чтобы решить проблему. - person Owen; 07.02.2009

arrow_upward
1
arrow_downward

Что вы ожидаете увидеть в окне разборки? Такой подход не сработает. Если вы можете восстановить ту же конфигурацию сборки, что и ваш клиент, вы можете включить файл /MAP в параметрах ссылки проекта. Это создаст файл, который сопоставляет символы с адресами и позволит вам увидеть, какая функция выполнялась, когда произошел сбой. Возможно, вам придется немного посчитать, чтобы сместить необработанный сопоставленный адрес с адресом, по которому модуль был загружен на ПК клиента.

Как говорит Фредрик, WinDbg тоже может помочь, особенно если вы можете получить аварийный дамп с ПК вашего клиента.

person Stu Mackellar    schedule 29.01.2009
comment
Я надеялся, что адрес уже будет относиться к модулю, так как он указывает, что это за модуль. Но я полагаю, я надеялся неправильно. Я не вижу /MAP в командной строке компоновщика, но параметров уже достаточно, чтобы увидеть исходный код в тех местах, которым он соответствует. - person Owen; 30.01.2009
comment
Это зависит от того, какую версию VS вы используете, но все они похожи. В версии 2008 вы можете перейти в Project Properties->Linker->Debugging и установить для параметра Generate Map File значение true и, при желании, задать имя файла. - person Stu Mackellar; 30.01.2009