Подтвердить что ты не робот

Отладка файлов дампа в 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, сбой Crash.exe. Он использует 1,356 КБ памяти. Я получаю Vista вариант Close Program/Debug. Если я выберу Debug, я могу открыть новый экземпляр Visual Studio, и он указывает мне на исключение NullReferenceException в инструкции if. Это хорошо.

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

Если я открою этот дамп с помощью 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. Я могу выбрать "Debug with Native Only", но я получаю много вещей, которые означают что-то умные люди, подобные вам, и я не умный! Я получаю эти два экрана:

enter image description here

enter image description here

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

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

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

4b9b3361

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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