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,356kbのメモリを使用します。 Close Program/DebugのVistaオプションがあります。 [デバッグ]を選択すると、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で開きます。 「ネイティブのみでデバッグする」を選択できますが、あなたのような賢い人にとって何かを意味するものがたくさんありますが、私は賢くありません!次の2つの画面が表示されます。
だから、私の質問:
Visual Studioをソースコードに表示するにはどうすればよいですか?
また、より小さいダンプファイルを取得する方法はありますか?圧縮した後でも、途方もなく大きいようです。なぜプログラムのフットプリントよりほんの少しだけ大きいものがありえないのか理解できませんが、それでもソースコードで素晴らしいデバッグを得ることができます。
Visual Studio 2010では、クラッシュダンプファイルをデバッグし、マネージソースコードをステップスルーできるという非常に宣伝されている機能があります: 。NET 4.0アセンブリのみ 。手順は次のとおりです。
Debug With Mixed
(これは.NET 4.0でのみ表示されます)ネイティブのみでのデバッグに関する限り、Visual StudioはWinDbgほど有用ではありません。
ここで使用しているツールは、マネージプログラムのクラッシュをトラブルシューティングするようには設計されていません。ミニダンプとWindbgは、CまたはC++で記述されたコードの何が問題なのかを見つけるために使用するものです。非常に重要なツールです。これらは、クラッシュしたマネージプログラムから抜け出すことができる種類のサポートをランタイムがサポートしていない言語です。スタックトレースの例外のように。
ミニダンプのサイズが非常に異なる理由は、ミニダンプのミニが原因です。設計では、プロセスの小さなスナップショットをキャプチャすることを目的としていました。関連する引数は、 MiniDumpWriteDump関数 のDumpTypeです。この関数には、デバッガセッションで使用する可能性が低いため、プロセス状態のどの部分を記録する必要がないかを把握できる、本当に巧妙なコードがあります。追加のダンプタイプフラグを指定することでオーバーライドできます。 Explorerが生成するミニダンプでは、これらのフラグがすべてオンになっているため、キット全体とcaboodleが取得されます。
これは、実際にはマネージプログラムにとって非常に重要です。このミニダンプ作成者が使用するヒューリスティックは、アンマネージコードにのみ適しています。マネージプログラムダンプのデバッグは、ガベージコレクションされたヒープ全体をダンプに含める場合にのみ機能します。はい、それは大きなダンプになります。miniはもう適用されません。
次の問題は、ミニダンプデータからマシンビューのソウルを取得していることです。スクリーンショットにはマシンコードが表示されています。これらのショットでは、Windowsの内部にいることがあります。ntdll.dllがスタックの一番上にあることに注意してください。 mscorwks.dllエントリはCLRです。さらに下に、ビューから、あなたはあなた自身のコードからスタックフレームを見るべきです。ただし、JITコンパイラーによって生成されたマシンコードは表示されます。 C#コードではありません。
管理されたデータを検査できるようにWindbgのコマンドセットを拡張するsos.dllと呼ばれるWindbgアドインがあります。 「sos.dll」をグーグルで検索して、良いヒットを得てください。ただし、これはVisual Studioデバッガーから得られるデバッグの経験から離れたlooong方法です。 WindbgやミニダンプをロードできるVSデバッガーとは非常に異なり、マネージコードをよく認識しています。 Sosは、CLRのバグをトラブルシューティングするために設計されました。
VS2010には、現在表示されているミニダンプ情報ページ以外に劇的な改善はありませんでした。これは実際にはほとんど何もしません。私はデバッガーチームがこれをtodoリストに載せているのではないかと疑っています。確かに、克服すべき基本的な問題がいくつかあります。特にミニダンプ形式と作成コード。 connect.Microsoft.comを使用してフィードバックを提供し、それに注意を払い、投票が優先順位リストに影響を与えるようにします。
関連するpdb(プログラムデータベース)ファイルをデバッガに提供して、シンボルをロードできるようにする必要があります。また、より良いビューを取得するには、Microsoft Public Symbolサーバーを使用します。 この記事 に情報が含まれています。