Поиск по памяти в VS2017

Я открыл файл минидампа моего приложения C++ в Visual Studio 2017. Дамп представляет собой сбой программы с нарушением прав доступа. Я подозреваю повреждение кучи/стека, поэтому я провожу много времени в окне памяти/разборки, пытаясь интерпретировать стек.

Было бы очень удобно, если бы я мог искать в памяти какое-то значение (например, обратный адрес вызовов функций). Я знаю, что WinDbg может это сделать, но в настоящее время он не имеет правильно настроенных путей к символам, и я бы предпочел остаться в одном отладчике.

Я нашел эта ссылка, в которой говорится, что Visual Studio 2010 поддерживает ввод чего-то вроде .S -D 0x20B4EC L100 0x12EC9275 в непосредственном окне, но когда я пытаюсь в VS2017, я просто получаю expected an expression.

Я что-то упускаю?

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

Пояснение

  • У меня есть минидамп с включенной памятью
  • Обычный анализ работает нормально: у меня есть pdb-файлы, я могу видеть потоки, стеки, часы и так далее. Просто я подозреваю повреждение стека, так что это не имеет особого смысла. (Или так, или оптимизатор надо мной издевается)
  • Следовательно, я открыл окно памяти (нажмите Debug->Windows->Memory->Memory 1). Там я вижу (необработанную) память. Теперь я хочу найти в этой памяти определенные значения.

person Kees-Jan    schedule 28.08.2019    source источник
comment
but it currently doesn't have symbol paths set up correctly почему бы вам просто не настроить его?   -  person andresantacruz    schedule 28.08.2019
comment
Я вообще не знаком с WinDbg. Поэтому после того, как я узнал, как настраивать пути символов, мне нужно было научиться использовать его в дальнейшем. Можно, конечно, но это скорее крайняя мера. Если знакомый мне отладчик поддерживает ту же функциональность, то это было бы предпочтительнее.   -  person Kees-Jan    schedule 28.08.2019
comment
Что вам нужно, я думаю, это получить трассировку стека вашего сбоя. Я бы выбрал вариант WinDbg + файлы *.pdb. Вы можете загрузить все в WinDbg и запустить, например, команду !analyze -v. Это может помочь вам лучше понять проблему.   -  person vahancho    schedule 28.08.2019
comment
Если у вас корпоративная версия VS2017, вы можете попробовать Reverse Debugging. Я считаю, что VS называет это IntelliTrace.   -  person Mark Storer    schedule 28.08.2019
comment
Обратная отладка удобна, если вы действительно можете воспроизвести проблему. Я не могу. Я исследую аварийный дамп, созданный одним из наших клиентов. Эту проблему трудно (если вообще возможно) воспроизвести, но она возникает достаточно часто, чтобы раздражать наших клиентов. К тому же у меня только VS профессиональный   -  person Kees-Jan    schedule 29.08.2019
comment
Возможно, вам нужно использовать Dumpchk.exe чтобы проверить, правильно ли создан файл дампа.   -  person Pod Mo    schedule 03.09.2019


Ответы (1)


Вот хороший учебник: https://docs.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2019

По сути, есть некоторые жесткие требования, чтобы увидеть память в вашем дампе:

  • минидамп должен быть с кучей
  • вы должны предоставить Visual Studio .exe и его .pdb

Если они не выполняются, вы получите только трассировку стека и, возможно, некоторые переменные стека.

Изменить. Трассировка стека с часами и переменными — это та же память, которую вы хотите найти. Живой отладки нет. Это снимок крушения.

person cosmin    schedule 28.08.2019
comment
Спасибо за ваш ответ. У меня есть все эти базы покрыты. Учебник слишком прост для того, что я пытаюсь сделать. См. также разъяснение выше. - person Kees-Jan; 28.08.2019
comment
Я обновил свой ответ. Вам нужна отладка в реальном времени. То, что у вас есть, это то, что вы получаете с отвалами. - person cosmin; 29.08.2019
comment
Как указано в моем вопросе, WinDbg может это сделать (с дампами), а также VS2010 (якобы). Кроме того, при отладке в реальном времени, похоже, также нет функции поиска. (У меня такое чувство, что вы меня не понимаете) - person Kees-Jan; 30.08.2019