Отладка файлов дампа в Visual Studio - PullRequest
49 голосов
/ 15 января 2011

Я использую Visual Studio 2010 Professional Edition и Windows Vista.

Во-первых, у меня есть этот код.Как вы можете видеть, это приведет к аварийному завершению программы!

using System;

namespace Crash
{
    class Program
    {
        static void Main(string[] args)
        {
            string a = null;

            if (a.Length == 12)
            {
                // ^^ Crash
            }
        }
    }
}

Программа завершится с ошибкой в ​​операторе if.Теперь я хочу выяснить, что он потерпел неудачу в этом заявлении if.

Если я запускаю без отладки из Visual Studio, происходит сбой Crash.exe.Он использует 1356 КБ памяти.Я получаю опцию Vista «Закрыть программу / Отладка».Если я выберу «Отладка», я могу открыть новый экземпляр Visual Studio, и он указывает на исключение NullReferenceException в операторе if.Это хорошо.

Теперь позвольте мне предположить, что он зависает на другом компьютере, и я заставляю их передавать мне файл дампа через диспетчер задач.Это 54 567 КБ.Почему такой большой!Это обширно!В любом случае, я менее заинтересован в этом (немного)

Если я открою этот дамп с помощью Windbg, я получу очень мало пользы для моего неподготовленного глаза:

Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\Richard\Desktop\Crash.DMP]
User Mini Dump File with Full Memory: Only application data is available

Symbol search path is: SRV*C:\SYMBOLS*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows Server 2008/Windows Vista Version 6002 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS Personal
Machine Name:
Debug session time: Sat Jan 15 11:07:36.000 2011 (UTC + 0:00)
System Uptime: 0 days 4:24:57.783
Process Uptime: 0 days 0:00:05.000
........................
eax=002afd40 ebx=77afa6b4 ecx=002afd48 edx=00000001 esi=001cdaa4 edi=00000000
eip=77bf5e74 esp=001cda5c ebp=001cdacc iopl=0         nv up ei ng nz ac pe cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000297
ntdll!KiFastSystemCallRet:
77bf5e74 c3              ret

Однако этоменьше интереса для меня.Насколько я могу судить, мне нужно написать команды, чтобы получить полезный вывод, и Visual Studio лучше.

Итак, я открываю его в Visual Studio.Я могу выбрать «Отладка только с помощью Native Only», но я получаю множество вещей, которые что-то значат для умных людей, таких как ты, и я не умен!Я получаю эти два экрана:

enter image description here

enter image description here

Итак, мой вопрос:

Как мнепоказать Visual Studio для моего исходного кода?

Кроме того, есть ли способ получить меньший файл дампа?Это кажется смехотворно большим, даже после сжатия.Я не понимаю, почему не может быть такого, который всего лишь чуть-чуть больше, чем занимает программа, и все же получает хорошую отладку с исходным кодом.

Ответы [ 3 ]

44 голосов
/ 15 января 2011

Особо рекламируемая функция Visual Studio 2010 позволяет отлаживать файлы аварийных дампов и проходить через управляемый исходный код с хитростями: она работает только для сборок .NET 4.0 . Вот шаги:

  1. Создание файла аварийного дампа на другом компьютере с помощью диспетчера задач
  2. Откройте решение в VS2010
  3. Открыть файл .DMP (Файл-> Открыть ...)
  4. Нажмите Debug With Mixed (Это будет видно только для .NET 4.0)
  5. Откроется исходный код, и вы сможете проверить точную причину и место исключения

Что касается отладки только с помощью native, Visual Studio не более полезен, чем WinDbg.

41 голосов
/ 15 января 2011

Используемые здесь инструменты никогда не предназначались для устранения неполадок, возникающих при сбое управляемых программ. Minidumps и Windbg - это то, что вы используете, чтобы узнать, что не так с кодом, написанным на C или C ++. Довольно важные инструменты, это языки, среды выполнения которых не поддерживают те лакомства, которые вы можете получить из аварийной управляемой программы. Как исключение с трассировкой стека.

Причина, по которой размеры мини-дампов такие разные, заключается в мини-мини-дампах. По замыслу он должен был сделать небольшой снимок процесса. Соответствующим аргументом является DumpType в функции MiniDumpWriteDump . В этой функции есть действительно умный код, который может выяснить, какие части состояния процесса не нужно записывать, потому что вы вряд ли будете использовать его в сеансе отладчика. Который вы можете переопределить, предоставив дополнительные флаги типа дампа. Мини-дамп, который генерирует Explorer, включает все эти флаги, вы получаете весь комплект и кабачок.

Что на самом деле очень важно для управляемой программы. Эвристика, используемая этим создателем мини-дампов, подходит только для неуправляемого кода. Отладка дампа управляемой программы работает хорошо только тогда, когда вы включаете в него всю кучу мусора. Да, это будет большая свалка, мини больше не применяется.

Ваша следующая проблема заключается в том, что вы получаете представление о машине из данных минидампа. Ваши снимки экрана показывают машинный код. На этих снимках вы оказались внутри Windows, обратите внимание, как ntdll.dll находится на вершине стека. Записи mscorwks.dll являются CLR. Далее, вне поля зрения, вы должны видеть кадры стека из своего собственного кода. Однако вы увидите машинный код, сгенерированный компилятором JIT. Не ваш код C #.

Существует надстройка Windbg под названием sos.dll, которая расширяет набор команд Windbg для возможности проверки управляемых данных. Просто Google "sos.dll", чтобы получить хорошие хиты. Однако это все еще очень далеко от способа отладки, который вы получаете от отладчика Visual Studio. Который хорошо осведомлен об управляемом коде, очень в отличие от Windbg или отладчика VS, который может загружать мини-дампы. Sos действительно был разработан для устранения ошибок CLR.

В VS2010 не было никаких существенных улучшений, кроме информации о мини-дампе, которую вы сейчас видите. Что на самом деле мало что делает. Я подозреваю, что команда отладчика внесла это в свой список задач, и, безусловно, есть некоторые фундаментальные проблемы, которые нужно преодолеть. Особенно в формате минидампа и кода создания. Используйте connect.microsoft.com для предоставления обратной связи, они обращают на нее внимание и позволяют голосам влиять на их список приоритетов.

5 голосов
/ 15 января 2011

Вы должны предоставить соответствующий файл pdb (программная база данных) отладчику, чтобы он мог загружать символы.Также для лучшего обзора используйте сервер Microsoft Public Symbol. Эта статья содержит информацию об этом.

...