Как открыть дамп памяти в visual studio
Обновлено: 07.07.2024
Я использую Visual Studio 2010 Professional Edition и Windows Vista.
во-первых, у меня есть этот код. Как вы можете видеть, это приведет к сбою программы!
программа аварийно завершит работу над инструкцией if. Теперь я хочу узнать, что он разбился на этом заявлении if.
Если я "начну без отладки" из Visual Studio, сбой.ехе падает. Он использует 1,356 КБ памяти. Я получаю опцию Vista закрыть программу / отладку. Если я выберу Debug, я могу открыть новый экземпляр Visual Studio, и он указывает мне на исключение NullReferenceException в инструкции if. Это хорошо.
теперь позвольте мне предположить, что он падает на другом компьютере, и я получаю их, чтобы дать мне файл дампа через Диспетчер задач. Это 54,567 КБ. Почему такой большой? Он огромен! Во всяком случае, меня это меньше интересует (немного)
Если я открою эту свалку с Windbg, я получу очень мало пользы для моего нетренированного глаза:
однако это представляет для меня меньший интерес. Же далеко как я могу сказать, мне нужно писать команды, чтобы получить полезный результат, и Visual Studio лучше.
поэтому я открываю его с помощью Visual Studio. Я могу выбрать "отлаживать только с Native", но я получаю много вещей, которые что-то значат для умных людей, таких как вы, и я не умный! Я получаю эти два экрана:
Итак, мой вопрос:
Как показать Visual Studio в исходном коде?
также, есть ли способ получить файл дампа меньшего размера? Кажется невероятно большим, даже после сжатия. Я не понимаю, почему не может быть такого, который только немного больше, чем след программы, и все равно получить хорошую отладку с исходным кодом.
что касается отладки только с native, Visual Studio не более полезна, чем WinDbg.
инструмент, который вы используете здесь, никогда не был разработан для устранения сбоев управляемых программ. Minidumps и Windbg-это то, что вы используете, чтобы узнать, что не так с кодом, написанным на C или c++. Довольно важные инструменты, это языки, в которых время выполнения не поддерживает те лакомства, которые вы можете получить из сбоя управляемой программы. Как исключение с трассировкой стека.
причина размеры minidump настолько различны из-за mini в minidump. Намеренно, он должен был запечатлеть небольшой моментальный снимок процесса. Соответствующий аргумент DumpType в функция MiniDumpWriteDump. В этой функции есть очень умный код, который может выяснить, какие части состояния процесса не нужно записывать, потому что вы вряд ли будете использовать его в сеансе отладчика. Который можно переопределить, предоставив дополнительные флаги типа дампа. Minidump, который генерирует Explorer, имеет все эти флаги, вы получаете весь комплект и компания.
что на самом деле очень важно для управляемой программы. Эвристика, используемая этим создателем minidump, подходит только для неуправляемого кода. Отладка управляемого дампа программы работает только тогда, когда вы включаете всю собранную кучу мусора в дамп. Да, это будет большая свалка, mini больше не применяется.
есть надстройка Windbg под названием sos.dll, которая расширяет набор команд Windbg, чтобы иметь возможность проверять управляемые данные. Просто google " sos.dll " to получай хорошие удары. Это, однако, все еще столько вдали от отладочного опыта, который вы получите из отладчика Visual Studio. Который хорошо знает управляемый код, в отличие от Windbg или отладчика VS, который может загружать мини-дампы. Sos был действительно разработан для устранения ошибок CLR.
вы должны предоставить соответствующий файл pdb (program database) отладчику, чтобы он мог загружать символы. Кроме того, чтобы получить лучшее представление, используйте Microsoft Public Symbol server. в этой статье содержит информацию об этом.
В примере, описанном в этой статье, проблема заключается в том, что приложение не отвечает на запросы своевременно.
Открытие дампа памяти в Visual Studio
Откройте дамп памяти в Visual Studio с помощью команды меню Файл > Открыть > Файл и выберите дамп памяти.
Обратите внимание, что на странице сводки дампа памяти в разделе Действие отображается пункт Выполнить диагностический анализ.
Выберите это действие, чтобы запустить отладчик и открыть новую страницу Диагностический анализ со списком доступных параметров анализатора, упорядоченных по базовым симптомам.
Выбор и выполнение анализаторов для дампа
Для изучения этих симптомов в разделе Скорость реагирования процесса доступны варианты, которые наиболее точно соответствуют проблеме в нашем примере.
Анализатор представит результаты на основе сведений о процессе и данных CLR, полученных в дампе памяти.
Просмотр результатов анализатора
В нашем примере анализатор обнаружил две ошибки. Выберите результат анализатора, чтобы просмотреть сводку анализа и предлагаемое исправление.
В разделе Сводка анализа указано, что пул потоков CLR испытывает нехватку ресурсов. Согласно этой информации предполагается, что среда CLR использовала все доступные потоки пула потоков. Это означает, что служба не сможет отвечать на новые запросы, пока поток не будет освобожден.
Исправление в нашем примере — это рекомендация не выполнять синхронное ожидание мониторов, событий, задач или других объектов, которые могут блокировать поток, и проверить, можно ли обновить метод как асинхронный.
Переход к проблемному коду
Следующим заданием является поиск проблемного кода.
Когда вы щелкнете ссылку Показать стек вызовов, Visual Studio немедленно переключится на потоки, которые демонстрируют это поведение.
В окне Стек вызовов отобразятся методы, которые могут быстро отличить пользовательский код (SyncOverAsyncExmple. ) от кода платформы (System. ).
Каждый кадр стека вызовов соответствует методу. Когда вы дважды щелкнете кадр стека, Visual Studio перейдет к коду, выполнение которого приводит непосредственно к описанному сценарию в этом потоке.
В нашем примере нет символов или кода, но на странице Символы не загружены можно выбрать вариант Декомпилировать исходный код .
В декомпилированном источнике ниже асинхронная задача (ConsumeThreadPoolThread) вызывает синхронную блокирующую функцию.
Метод DoSomething() содержит метод WaitHandle.WaitOne, который блокирует текущий поток пула потоков до получения сигнала.
Чтобы ускорить реагирование приложений, важно снять блокировку синхронного кода из всех асинхронных контекстов.
Перевод с Visaul Studio 2010 на Visaul Studio 2005
нужно перевести програмку с Visaul studio 2010 на Visaul studio 2005, тоесть изменит 2 строчки, а я.
Visaul Studio Code для PHP
Привет, всем сейчас пользуюсь я Sublime Text 3 для написание кода на PHP, скажите кто пользовался.
Авторазмещение кода в Visaul Studio 2013
Здравствуйте,проблема вот такая: Обычно скажем если кликнуть два раза по кнопке на форме то в .h.
В поле дампа памяти вывести на экран содержимое данной памяти [bx+di]
Имеется функция IDIV word ptr . Но предварительно мы записываем значение в данную область памяти.
Решение
плюс дизассемблер тебе может помочь atl + G
Добавлено через 1 минуту
XSasha, пкм в данной области ->
И как видно из меню это числа в 16-ой системе счисления.
plzvtl, нет, то, что это 16-чная сс это понятно - я про то, что эти сочетания значат.
Например, у меня есть структура, состоящая из двух указателей на точно такие же структуры, числа типа int и массива из пяти элементов типа double. Вот, что я вижу в памяти по адресу, где данная структура расположена:
0x006CAF28 00 00 00 00 c0 ae 6c 00 64 00 00 00 cd cd cd cd 00 00 00 00 00 00 32 40 00 00 00 00 00 00 32 40 00 00 00 00 00 00 32 40 00 00 00 00 00 00 32 40 00 00 00 00 00 00 32 40 fd fd fd fd dd dd dd dd 35 11 5b 6c 3b 1b
Первые 8 байт под два указателя (по 4 байт каждый), дальше идёт целое число 100 (64 в 16-чной), а вот дальше что идут за 4 cd? После этого идут 40 байт под массив (кстати, я инициализировал все 5 элементов в 18, но не понял, почему тут 32 40), а дальше снова хз что идёт до самого конца (70 столбцов выставил).
Добавлено через 2 минуты
Сори, что долго. Киберфорум ночью плохо грузит, иногда не зайти сюда. По крайней мере у меня так
В блоге Microsoft недавно была опубликована статья, которую написал Билл Рэндольф, старший инженер-программист Blizzard, занимающийся разработкой Diablo IV. В этой статье раскрыты некоторые особенности работы над Diablo IV и, в частности, рассказано об использовании Visual Studio для отладки кода, рассчитанного на Linux. Сегодня мы предлагаем вашему вниманию перевод этого материала.
Введение
Мы, работая над Diablo IV, пишем весь код в Windows, а потом компилируем его для разных платформ. Это относится и к нашим серверам, которые работают под управлением Linux. (Код включает в себя директивы условной компиляции и, там, где это нужно, в нём есть фрагменты, написанные специально для конкретной платформы.) Наша работа организована именно так по многим причинам. Для начала — ключевые профессиональные навыки нашей команды относятся к Windows. Даже наши серверные программисты лучше всего знакомы именно с Windows-разработкой. Мы ценим возможность применения одних и тех же инструментов и одной и той же базы знаний всеми программистами нашей команды.
Ещё одна, самая важная причина того, что мы занимаемся разработкой на Windows, заключается в возможности пользоваться высокофункциональным и надёжным набором инструментов, который даёт нам Visual Studio. И даже если бы мы разрабатывали что-то в Linux, то я могу сказать, что в мире Linux нет ничего такого, что можно было бы хотя бы сравнить с Visual Studio.
Правда, из-за этого мы сталкиваемся с некоторыми сложностями, которые возникают тогда, когда сервер даёт сбой и нам надо отладить дамп памяти. У нас есть возможность удалённого входа в виртуальную машину (или, точнее — в контейнер), который дал сбой, мы можем запустить gdb для выяснения причин произошедшего. Но у такого подхода есть множество недостатков. Например — мы не разворачиваем бинарные файлы вместе с исходным кодом — в результате при работе с виртуальной машиной или с контейнером исходный код в gdb-сессии недоступен.
Ещё одна сложность кроется в самом gdb. Дело в том, что если не пользоваться этим инструментом постоянно, на регулярной основе, его нельзя освоить на таком уровне, который бы нас устраивал. Проще говоря, наши разработчики гораздо охотнее пользовались бы знакомыми инструментами для отладки кода. Так как только 2-3 из наших разработчиков очень хорошо знают gdb, то, когда что-то идёт не так, поисками проблемы занимаются именно они. А это нельзя назвать оптимальным распределением нагрузки на программистов.
Нам всегда хотелось найти такой способ отладки Linux-кода, который отличался бы интуитивной понятностью. Именно поэтому нас так восхищает возможность использования новой возможности Visual Studio, которая позволяет нам решать именно эту задачу в знакомой среде! И вовсе не преувеличением будет сказать, что благодаря этому наша мечта сбылась.
О применяемом нами процессе отладки кода
Отладка Linux-кода в Visual Studio возможна лишь в том случае, если в системе установлена подсистема Windows для Linux (WSL), или тогда, когда в менеджере подключений (Connection Manager) настроено подключение к Linux. Все наши серверные разработчики установили WSL, используя дистрибутив, на котором мы разворачиваем наш проект. Мы запускаем написанный мной скрипт, который устанавливает все инструменты разработки и вспомогательные библиотеки, необходимые для сборки нашего сервера в WSL.
(Ненадолго отвлекусь от нашей основной темы. Мне хотелось бы подчеркнуть, что мы пришли к выводу о том, что WSL — это лучшее из существующих окружений, позволяющих разработчикам тестировать изменения в Linux-сборках. Крайне удобно выглядит такая схема работы: переход в WSL, использование команды cd для входа в общую директорию с кодом и сборка проекта прямо оттуда. Это — гораздо лучшее решение, чем использование виртуальной машины или даже контейнера. Если вы собираете проекты с использованием CMake, это значит, что вы, кроме того, можете задействовать встроенную в Visual Studio поддержку WSL.)
Немного расскажу о наших сборках. Мы разрабатываем код в Windows и у нас есть Windows-версия нашего сервера, рассчитанная на работу в этой ОС. Это приносит нам пользу при работе над обычными возможностями проекта. Но мы разворачиваем наш серверный код в среде Linux, что требует выполнения сборок на Linux. Linux-сборки создаются на сборочной ферме. Там используется система сборки, работающая на Linux-компьютере. С её помощью собирается наш серверный проект и соответствующий контейнер, который в дальнейшем и развёртывается. Исполняемые файлы, рассчитанные на Linux, разворачиваются только в контейнерах. Обычно у разработчиков нет доступа к этим контейнерам.
Когда один из серверов нашей инфраструктуры даёт сбой, нас об этом уведомляет специальный скрипт, после чего файлы дампа записываются в общую сетевую папку. Для отладки этих файлов, либо в Linux, либо в Visual Studio, необходима работающая программа. При отладке полезно использовать в точности те общие библиотеки, которые применялись в развёрнутом контейнере. Для получения этих файлов мы используем другой скрипт. Сначала мы копируем дамп на локальную машину, а потом запускаем скрипт и передаём ему сведения об этом дампе. Скрипт загружает контейнер Docker, который был собран для исследуемой версии кода, извлекает из него исполняемые файлы нашего сервера, а так же — определённые общие библиотеки времени выполнения. Всё это нужно для gdb. (Это, при работе с gdb, позволяет избежать проблем с совместимостью, которые могут возникнуть в том случае, если WSL-версия системы не является точно такой же, как её развёрнутая Linux-версия.) Скрипт, настраивая отладочную сессию, пишет данные в
/.gdbinit , указывая, что общие библиотеки являются системными библиотеками.
Потом мы переходим в Visual Studio, где и начинается самое интересное. Мы загружаем решение для сборки Windows-версии наших серверов. Затем мы открываем новое диалоговое окно отладки, воспользовавшись командой Debug -> Other Debug Targets -> Debug Linux Core Dump with Native Only . Мы устанавливаем флажок Debug on WSL и вводим пути к файлам дампа и к серверным бинарникам (предназначенным для WSL!). После этого достаточно нажать на кнопку Debug и наблюдать за происходящим.
Запуск отладки в Visual Studio
Visual Studio самостоятельно запускает gdb в WSL. После того, как некоторое время система поработает с диском, выводится стек вызовов программы, давшей сбой, а указатель инструкций устанавливается на соответствующую строку кода. Это, воистину, дивный новый мир!
Дальше мы занимаемся идентификацией самого сбоя. У нас есть обработчик сбоев, который перехватывает соответствующее событие для выполнения некоторых служебных процедур. Поэтому сведения о самом сбое расположены, на однопоточном сервере, глубже в стеке вызовов. Но некоторые из наших серверов многопоточны. И сбой может произойти в любом из их потоков. Обработчик сбоев логирует сведения о коде сбойного файла и о номере строки. Поэтому исследование этих данных даёт нам первую подсказку. Мы ищем то место в стеке вызовов, которое соответствует выполнению этого кода.
В давние времена, а именно, несколько недель назад, мы применили бы gdb для обратной трассировки всех потоков, а после этого просмотрели бы получившийся список в поиске потока, в стеке вызовов которого, вероятнее всего, произошёл сбой. Например, если поток находился в спящем состоянии, то сбой в нём, скорее всего, не происходил. Нам нужен стек, в котором есть нечто большее, чем несколько кадров и сведения о том, что мы имеем дело со спящим потоком. Далее, нам надо исследовать код для того чтобы понять, что перед нами за проблема. Если это что-то простое — это можно увидеть прямо в коде. Если же перед нами проблема посложнее — придётся прибегать к возможностям gdb для исследования состояния процесса.
А вот Visual Studio даёт нам значительно более мощные возможности, чем имелись у нас раньше. В многопоточных средах можно открыть в отладочной сессии окно Threads и, пощёлкав по потокам, посмотреть их стеки. Это, правда, очень похоже на подход, используемый в gdb. Поэтому, если надо изучить, скажем, 50 потоков, это может превратиться в довольно трудоёмкую и скучную задачу. К счастью, в Visual Studio есть инструмент, значительно упрощающий эту задачу. Речь идёт об окне Parallel Stacks.
Признаю: большинство из нас не знали о Parallel Stacks до тех пор, пока Эрика Свит и её команда не сказали нам об этом. Если во время работы отладочной сессии выполнить команду Debug -> Windows -> Parallel Stacks — будет открыто новое окно, которое выводит сведения о стеке вызовов каждого потока в исследуемом процессе. Это нечто вроде вида с высоты птичьего полёта на всё пространство процесса. По любому кадру стека любого потока можно сделать двойной щелчок. После этого Visual Studio перейдёт в этот кадр и в окне исходного кода, и в окне стека вызовов. Это очень сильно помогает нам экономить время.
После того, как мы видим код, находящийся поблизости от места сбоя, мы можем исследовать переменные с использованием мыши, с помощью QuickWatch, или применив любой другой из множества инструментов Visual Studio. Конечно, в релизных сборках многие переменные подвергаются оптимизации, но, в то же время, многие не подвергаются! Мы, применяя интерфейс Visual Studio, можем выявить проблему гораздо быстрее, чем раньше, используя gdb.
Итоги
Наша команда просто счастлива возможностью отлаживать дампы из Linux в Visual Studio, в окружении, в котором мы занимаемся разработкой. Для нас это — серьёзное улучшение, так как это позволяет гораздо большему количеству разработчиков, чем раньше, диагностировать проблемы в естественных условиях их возникновения. Это позволяет всем нам пользоваться мощными отладочными инструментами Visual Studio. После того, как завершена предварительная подготовка рабочей среды, оказаться в отладочной сессии Visual Studio можно буквально за считанные минуты. Эта возможность значительно повышает скорость нахождения проблем и эффективность нашей работы. Благодарю Эрику и её команду за помощь.
Читайте также: