2012-10-23 13 views
5

Ho una perdita di handle in un programma C#. Sto provando a diagnosticarlo usando WinDbg usando! Htrace, all'incirca come presentato in this answer, ma quando eseguo! Htrace -diff in WinDbg mi vengono presentate tracce dello stack che non mostrano i nomi delle mie funzioni C# (o anche my .net assembly).Problemi di visualizzazione della traccia dello stack C# in WinDbg

Ho creato un piccolo programma di test per illustrare la mia difficoltà. Questo programma non fa altro che maniglie "leak".

class Program 
{ 
    static List<Semaphore> handles = new List<Semaphore>(); 

    static void Main(string[] args) 
    { 
     while (true) 
     { 
      Fun1(); 
      Thread.Sleep(100); 
     } 
    } 

    static void Fun1() 
    { 
     handles.Add(new Semaphore(0, 10));    
    } 
} 

ho compilato l'assemblea, e poi in WinDbg vado "File" -> "Apri eseguibile" e selezionare il mio programma (D: \ Projects \ sabbiera \ bin \ Debug \ Sandpit.exe). Continuo l'esecuzione del programma, lo interrompo ed eseguo "! Htrace -enable", quindi proseguo un po 'più a lungo, quindi interrompo ed eseguo "! Htrace -diff". Questo è ciò che ottengo:

0:004> !htrace -enable 
Handle tracing enabled. 
Handle tracing information snapshot successfully taken. 
0:004> g 
(1bd4.1c80): Break instruction exception - code 80000003 (first chance) 
eax=7ffda000 ebx=00000000 ecx=00000000 edx=77b2f17d esi=00000000 edi=00000000 
eip=77ac410c esp=0403fc20 ebp=0403fc4c iopl=0   nv up ei pl zr na pe nc 
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000    efl=00000246 
ntdll!DbgBreakPoint: 
77ac410c cc    int  3 
0:004> !htrace -diff 
Handle tracing information snapshot successfully taken. 
0xd new stack traces since the previous snapshot. 
Ignoring handles that were already closed... 
Outstanding handles opened since the previous snapshot: 
-------------------------------------- 
Handle = 0x00000250 - OPEN 
Thread ID = 0x00001b58, Process ID = 0x00001bd4 

0x77ad5704: ntdll!ZwCreateSemaphore+0x0000000c 
0x75dcdcf9: KERNELBASE!CreateSemaphoreExW+0x0000005e 
0x75f5e359: KERNEL32!CreateSemaphoreW+0x0000001d 
*** WARNING: Unable to verify checksum for C:\Windows\assembly\NativeImages_v4.0.30319_32\System\13c079cdc1f4f4cb2f8f1b66c8642faa\System.ni.dll 
0x65d7e805: System_ni+0x0020e805 
0x65d47843: System_ni+0x001d7843 
0x65d477ef: System_ni+0x001d77ef 
0x004700c9: +0x004700c9 
0x67d73dd2: clr!CallDescrWorkerInternal+0x00000034 
0x67d9cf6d: clr!CallDescrWorkerWithHandler+0x0000006b 
0x67d9d267: clr!MethodDescCallSite::CallTargetWorker+0x00000152 
0x67eb10e0: clr!RunMain+0x000001aa 
0x67eb1200: clr!Assembly::ExecuteMainMethod+0x00000124 
-------------------------------------- 
Handle = 0x0000024c - OPEN 
Thread ID = 0x00001b58, Process ID = 0x00001bd4 

0x77ad5704: ntdll!ZwCreateSemaphore+0x0000000c 
0x75dcdcf9: KERNELBASE!CreateSemaphoreExW+0x0000005e 
0x75f5e359: KERNEL32!CreateSemaphoreW+0x0000001d 
0x65d7e805: System_ni+0x0020e805 
0x65d47843: System_ni+0x001d7843 
0x65d477ef: System_ni+0x001d77ef 
0x004700c9: +0x004700c9 
0x67d73dd2: clr!CallDescrWorkerInternal+0x00000034 
0x67d9cf6d: clr!CallDescrWorkerWithHandler+0x0000006b 
0x67d9d267: clr!MethodDescCallSite::CallTargetWorker+0x00000152 
0x67eb10e0: clr!RunMain+0x000001aa 
0x67eb1200: clr!Assembly::ExecuteMainMethod+0x00000124 
... 
-------------------------------------- 
Displayed 0xd stack traces for outstanding handles opened since the previous snapshot. 

Come si può vedere, la traccia dello stack manca il mio C# nomi di funzione "Main" e "Fun1". Credo che i frame "System_ni + 0x ..." potrebbero essere i frame delle mie funzioni, ma non lo so. La mia domanda è, come faccio a ottenere WinDbg per visualizzare i nomi delle funzioni per le mie funzioni C# nello stack trace?

Ulteriori informazioni: mio WinDbg percorso di simboli di ricerca è

SRV C:/simbolihttp://msdl.microsoft.com/download/symbols;D: \ Projects \ sabbiera \ bin \ debug; SRV *

non lo faccio ottenere eventuali errori quando apro l'eseguibile in WinDbg. C'è un file chiamato "Sandpit.pdb" nella directory di output ("D: \ Projects \ Sandpit \ bin \ Debug"). Il progetto è costruito localmente quindi il file pdb deve corrispondere all'exe. Ho scaricato WinDbg from here. Ho "Abilita il debug del codice nativo" selezionato nelle impostazioni del progetto in Visual Studio.

+0

Guardando tracce dello stack non sta per dirvi che la lista sta memorizzando maniglie. Devi invece guardare l'heap. Piuttosto doloroso in Windbg, il cumulo è un'enorme manichetta antincendio. Considerare invece un profiler di memoria .NET. –

risposta

6

WinDbg tenta di interpretare lo stack di chiamate native nel miglior modo possibile, tuttavia per interpretare completamente lo stack di un'applicazione CLR, WinDbg deve utilizzare un'estensione denominata SOS. Questa estensione ha un comando separato CLRStack per la visualizzazione delle informazioni di stack degli stack CLR. Sarà necessario caricare l'estensione SOS prima però utilizzando il comando .loadby sos clr (o simili, mi ricordo ottenere la versione corretta SOS per caricare potrebbe essere un po 'di dolore)

Per ulteriori informazioni vedere

+2

Grazie! Questo spiega perché ero così confuso. Ho letto di sos.dll, ma ho assunto erroneamente che doveva essere semplicemente caricato per comandi come htrace per funzionare con CLR. Mi sono avvicinato a una soluzione usando '! Htrace' e poi'! U' con l'indirizzo dello stack. Sembrava anche che avessero problemi a camminare tra i frame di invocazione di p, quindi ho impostato un punto di interruzione su uno dei punti restituiti da htrace, e ho usato '! Clrstack' per visualizzare lo stack CLR completo. – Mike

Problemi correlati