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

Question

Я использую 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", но я получаю множество вещей, которые что-то значат для умных людей, таких как вы, и я не умный! Я получаю эти два экрана:

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

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

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

Answer 1

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

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

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

Answer 2

Инструменты, которые вы здесь используете, никогда не предназначались для устранения неполадок, связанных с сбоями управляемых программ. 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 для предоставления обратной связи, они обращают на нее внимание и позволяют голосам влиять на их список приоритетов.

Answer 3

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