E’ possibile creare un file minidump anche per applicazioni .NET nello stesso modo descritto nell’articolo per le applicaizoni native:

http://www.versionestabile.it/blog/dubugging-with-windbg/

Per le applicazioni .NET è più difficile avere la riga di codice esatta, soprattutto se non si è tenuto il file .pdb della versione che ha fatto il “crash” a casa del cliente e non vengono caricati correttamente anche i symboli delle classi .NET relative al Framework con cui è stato compilato il programma in question.

Per prima cosa lanciare il caricamento del framework

.loadby sos clr

Comunque anche se si dispone solo del file .dump (vedere come generarlo nell’articolo citato sopra) se lo si apre con WinDBG e si analizzano al suo interno le eccezioni con il comando

!analyze -v

Si può vedere lo stack trace che ci porta al punto di programma incriminato.

Vediamo un esempio.

Il programma C# del nostro esempio è il seguente:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace WinDbgCrashTest
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
            badMethod();
        }

        private void badMethod() {
            Object o = null;
            String s = o.ToString();
        }
    }
}

Se lo si lancia andrà in Crash immediato.

Apriamo il suo minidump con WinDBG e lanciamo !analyze -v

Lancirare WinDbg come amministratore in modo che possa scaricare (dal sito di Microsoft) nelle cartelle di sistema i simboli che eventualmente non trova in locale.

Ecco il risultato:

Anche se non è riuscito a caricare i simboli

ci dice che alla riga 2 del metodo badMethod all’interno della classe Form1 si è verificata l’eccezione!

Se diamo a WinDBG il path del .pdb e dei sorgenti che fanno riferimento a quell’eseguibile con il comando

!clrstack

Abbiamo anche più info: il file e la riga dove è avvenuta l’eccezione.