在Visual Studio中調試轉儲文件

Question

我使用的是Visual Studio 2010專業版和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,356kb的內存。 我得到了Close Program / Debug的Vista選項。 如果我選擇Debug，我可以打開一個新的Visual Studio實例，它指向if語句的NullReferenceException。 這很好。

現在讓我假設它在另一台計算機上崩潰了，我讓他們通過任務管理器給我一個轉儲文件。 它是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打開它。 我可以選擇“僅使用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 ++編寫的代碼有什么問題。 非常重要的工具，這些語言的運行時不支持您可以從崩潰的托管程序中獲得的那種好東西。 就像堆棧跟蹤的異常一樣。

minidump尺寸如此不同的原因是因為迷你小型車。 按照設計，它旨在捕獲過程的一個小快照。 相關參數是MiniDumpWriteDump函數中的 DumpType。 在這個函數中有一些非常聰明的代碼可以找出不需要記錄過程狀態的哪些部分，因為你不太可能在調試器會話中使用它。 您可以通過提供其他轉儲類型標志來覆蓋。 Explorer生成的minidump打開了所有這些標志，你得到了整個套件和cabo​​odle。

這對托管程序來說實際上非常重要。 這個minidump創建者使用的啟發式算法只適用於非托管代碼。 只有在轉儲中包含整個垃圾回收堆時，才能調試托管程序轉儲。 是的，這將是一個大型轉儲，迷你不再適用。

您的下一個問題是您從minidump數據中獲得了機器視圖的靈魂。 您的屏幕截圖顯示機器代碼。 你碰巧在這些鏡頭中位於Windows內部，注意ntdll.dll是如何在堆棧頂部的。 mscorwks.dll條目是CLR。 再往下看，你應該從你自己的代碼中看到堆棧幀。 但是，您將看到由JIT編譯器生成的機器代碼。 不是你的C＃代碼。

有一個名為sos.dll的Windbg加載項，它擴展了Windbg的命令集，以便能夠檢查托管數據。 只需谷歌“sos.dll”獲得良好的點擊率。 然而，這仍然是一個looong方式遠離那種調試經驗，你會得到了Visual Studio調試器的。 這是密切關注托管代碼的，非常不像Windbg或可以加載minidump的VS調試器。 Sos真的旨在解決CLR錯誤。

除了你現在看到的minidump信息頁面之外，VS2010沒有任何顯着的改進。 這真的沒什么用。 我懷疑Debugger團隊在他們的待辦事項清單上有這個，肯定有一些基本問題需要克服。 特別是在minidump格式和創建代碼中。 使用connect.microsoft.com提供反饋，他們會關注它並讓投票影響他們的優先級列表。

Answer 3

您應該將相關的pdb（程序數據庫）文件提供給調試器，以便它可以加載符號。 另外，要獲得更好的視圖，請使用Microsoft Public Symbol服務器。 本文包含有關它的信息。