Debugowanie plików zrzutu w programie Visual Studio

Question

Używam Visual Studio 2010 Professional Edition i Windows Vista.

Po pierwsze, mam ten kod. Jak widać, spowoduje awarię programu!

using System; 

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

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

Program zawiesza się na instrukcji if. Teraz chcę się dowiedzieć, że rozbił się na tym stwierdzeniu.

Jeśli "Uruchom bez debugowania" z programu Visual Studio, Crash.exe ulega awarii. Wykorzystuje 1 356 kb pamięci. Dostaję opcję Vista Close Program/Debug. Jeśli wybiorę Debugowanie, mogę otworzyć nowe wystąpienie Visual Studio i wskazuje mi na NullReferenceException na instrukcji if. To jest dobre.

Teraz pozwól mi założyć, że zawiesza się na innym komputerze, a ja dostaję je do przekazania mi pliku zrzutu za pomocą Menedżera zadań. Jest 54.567kb. Dlaczego taki duży! Jest ogromny! W każdym razie, jestem mniej zainteresowany że (nieznacznie)

Gdybym otworzyć ten zrzut z WinDbg, mam bardzo mało użyteczne dla mojego niewprawnego oka:

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 

jednak jest to mniej interesujące dla mnie . O ile mogę powiedzieć, muszę napisać polecenia, aby uzyskać przydatne wyniki, a Visual Studio jest lepsze.

Otwieram go za pomocą Visual Studio. Mogę wybrać "Debuguj tylko z Native", ale dostaję wiele rzeczy, które oznaczają coś dla sprytnych ludzi takich jak ty, a ja nie jestem sprytny! Mam te dwa ekrany:

Więc moje pytanie:

Jak mogę wyświetlić Visual Studio do mojego kodu źródłowego?

Czy istnieje również sposób na uzyskanie mniejszego pliku zrzutu? Wydaje się absurdalnie duży, nawet po kompresji. Nie rozumiem, dlaczego nie może istnieć taki, który jest tylko odrobinę większy niż ślad programu, i nadal otrzymuję dobre debugowanie za pomocą kodu źródłowego.

Answer 1

Znacznie reklamowana funkcja, którą Visual Studio 2010 pozwala na debugowanie plików zrzutu pamięci i przechodzenie przez zarządzany kod źródłowy, otrzymuje komunikat: działa only for .NET 4.0 assemblies. Oto kroki:

1. Utwórz plik zrzutu awaryjnego na innym komputerze przy użyciu Menedżera zadań
2. Otwórz rozwiązanie w VS2010
3. Otwórz plik dmp (Plik-> Otwórz ...)
4. Kliknij na Debug With Mixed (Będzie to widoczne tylko dla .NET 4.0) Kod
5. Źródło otworzy i będzie mógł sprawdzić dokładną przyczynę i lokalizację wyjątkiem

miarę debugowania z natywnym jest zainteresowane tylko Visual Studio nie jest bardziej przydatna niż WinDbg.

Answer 2

Powinieneś dostarczyć odpowiedni plik pdb (baza danych programów) do debuggera, aby mógł załadować symbole. Aby uzyskać lepszy widok, użyj serwera Microsoft Public Symbol. This article zawiera informacje na ten temat.

Answer 3

Oprzyrządowanie, którego tu używasz, nigdy nie było zaprojektowane do rozwiązywania problemów z awarią zarządzanych programów. Minidumps i Windbg są tym, czego używasz, aby dowiedzieć się, co jest nie tak z kodem napisanym w języku C lub C++. Bardzo ważne narzędzia, to języki, których środowiska wykonawcze nie mają wsparcia dla tego rodzaju gadżetów, które można uzyskać z powodu awarii zarządzanego programu. Jak wyjątek ze śledzeniem stosu.

Powód, dla którego rozmiary minidumpów są tak różne, jest taki, że mini w minidump. Z założenia miało to uchwycić małą migawkę procesu. Odpowiednim argumentem jest DumpType w MiniDumpWriteDump function. W tej funkcji istnieje naprawdę sprytny kod, który pozwala zorientować się, które części stanu procesu nie muszą być rejestrowane, ponieważ nie jest prawdopodobne, że użyjesz go w sesji debuggera. Które możesz przesłonić, dostarczając dodatkowe flagi typu zrzutu. Minidump, który generuje Explorer, ma włączone wszystkie flagi, dostajesz cały zestaw i cabbage.

Co jest bardzo ważne dla zarządzanego programu. Heurystyka używana przez twórcę minizrzutu to taka, która jest odpowiednia tylko dla niezarządzanego kodu. Debugowanie zrzutów programu zarządzanego działa dobrze tylko wtedy, gdy w zrzutach znajduje się cała kupka śmieci. Tak, to będzie duży zrzut, mini już się nie stosuje.

Twój następny problem polega na tym, że dostajesz duszę widoku maszyny z danych minizrzutu. Twoje zrzuty ekranu pokazują kod maszynowy. W tych ujęciach znajdujesz się w systemie Windows, zauważ, że ntdll.dll jest na szczycie stosu. Wpisy mscorwks.dll to CLR. W dalszej kolejności, poza widokiem, powinieneś zobaczyć klatki stosu z własnego kodu. Zobaczysz jednak kod maszynowy wygenerowany przez kompilator JIT. Nie twój kod C#.

Istnieje dodatek Windbg o nazwie sos.dll, który rozszerza zestaw poleceń programu Windbg, aby umożliwić sprawdzenie zarządzanych danych. Wystarczy google "sos.dll", aby uzyskać dobre trafienia. Jest to jednak jeszcze jeden sposób na pozbycie się debugowania Visual Studio. Który jest dokładnie świadomy zarządzanego kodu, bardzo różny od Windbg lub debuggera VS, który może załadować minizrzuty. Sos był naprawdę zaprojektowany do rozwiązywania problemów z CLR.

W witrynie VS2010 nie odnotowano żadnych znaczących ulepszeń poza stroną z informacją o minidump, którą teraz widzisz. Co tak naprawdę wcale nie działa. Podejrzewam, że zespół ds. Debugowania ma to na swojej liście zadań, z pewnością istnieją pewne podstawowe problemy do przezwyciężenia. Zwłaszcza w formacie minidump i kodzie tworzenia. Skorzystaj z witryny connect.microsoft.com, aby przekazać opinię, zwrócić na nią uwagę i pozwolić, aby głosy wpłynęły na ich listę priorytetów.