Отладка файлов дампа в Visual Studio

Я использую 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, сбой.ехе падает. Он использует 1,356 КБ памяти. Я получаю опцию Vista закрыть программу / отладку. Если я выберу Debug, я могу открыть новый экземпляр 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:UsersRichardDesktopCrash.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", но я получаю много вещей, которые что-то значат для умных людей, таких как вы, и я не умный! Я получаю эти два экрана:

enter image description here

enter image description here

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

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

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

3 ответов


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

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

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


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

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

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

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

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

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


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