Handle-Leck in .NET-Anwendung ausschließlich aus Speicherabbild untersuchen

Ich muss ein Handle-Leck untersuchen, das in einer .NET-Anwendung aufgetreten ist und nur über einen Speicherabbildspeicher verfügen. Ich kann kein Live-Debugging oder Monitoring durchführen.Handle-Leck in .NET-Anwendung ausschließlich aus Speicherabbild untersuchen

Ich öffnete die Dump-Datei in Visual Studio 2015, .NET Memory Profiler und Windbg. Ich kann das 100k offene Handles in Windbg Liste, von denen die meisten Themen Griffe:

0:000> !handle 0006aaf8 f 
Handle 0006aaf8 
    Type     Thread 
    Attributes   0 
    GrantedAccess    0x1fffff: 
     Delete,ReadControl,WriteDac,WriteOwner,Synch 
     Terminate,Suspend,Alert,GetContext,SetContext,SetInfo,QueryInfo,SetToken,Impersonate,DirectImpersonate 
    HandleCount 3 
    PointerCount 5 
    Name     <none> 
    Object specific information 
    Thread Id 1f24.1ce1c 
    Priority 10 
    Base Priority 0

Danach, ich bin stecken. Ich weiß nicht, was ich mit dieser Thread-ID "1f24.1ce1c" tun soll, die nichts mit! Threads (insgesamt 74 Threads) zu tun scheint. Ich sehe auch nichts, was meinen verwalteten Speicher betrifft. Einige Handbücher empfehlen die Verwendung von! Htrace für weitere Untersuchungen, aber wenn ich mich nicht irre, funktioniert das nur, wenn ich es an einen laufenden Prozess anschließe.

Ich wäre für jeden Vorschlag dankbar.

Quelle

2016-07-18 Odsh

Ein Handle-Leck ist kein kritischer Fehler. Warum können Sie ein Debugging oder anderweitig instrumentierte Build nicht profilieren und nach Handle-Leaks suchen? Sicherlich ist es unwahrscheinlich, dass ein Handle-Leck einen Absturz ausgelöst hat, es sei denn, Sie verlieren Griffe wie * mad *. In diesem Fall wäre es ziemlich einfach, das Problem in einem Debug-Build zu reproduzieren. –

Sie sagen, dass sie Thread-Handles sind. Wer erstellt die Threads? Warum können Sie den Code, der dafür verantwortlich ist, nicht interaktiv debuggen? Ist es nicht Code, den Sie geschrieben haben oder auf den Sie Zugriff haben? –

Sie könnten versuchen, [Debug Diagnostic Tool] (https://www.microsoft.com/en-us/download/details.aspx?id=49924) auszuführen, um das Problem genau zu bestimmen. – Igor

Mit Blick auf native Handles, denke ich, dass die Thread-ID, die Sie betrachten, auch native sind. In Ihrem Beispiel wird 1f24 wahrscheinlich die Prozess-ID sein, die Sie auch sehen können, wenn Sie eine Pipe '|' eingeben, und 1ce1c die native ThreadId, die nicht mit der von Thread angezeigten verwalteten ThreadId identisch ist. Sie können sehen, ob diese ThreadId einem noch lebenden Thread entspricht, der den Befehl '~' ausführt.

Ohne Aktivieren der Tracefunktion für die Verwendung von! Htrace wird die Verfolgung der nativen Spur kompliziert. DebugDiag könnte helfen, wie andere vorgeschlagen haben, und wirkt sich weniger auf die Handle-Ablaufverfolgung aus, da es nur um das Verknüpfen von Zuordnungsfunktionen geht.

Sonst würde ich empfehlen zu versuchen, nach einigen Anhaltspunkten auf der verwalteten Seite zu suchen, wenn Sie glauben, dass das mit Ihrem .NET-Code in Verbindung stehen könnte. Können Sie dieses native Thread-Leck nicht mit einem Leck in verwalteten Objekten in Verbindung bringen? A! Dumpheap -stat zeigt nicht eine hohe Anzahl von System.Threading.Thread, System.Windows.Forms.Application + ThreadContext, System.Windows.Forms.Control + ControlNativeWindow oder so? Wenn Sie eine solche verwaltete Objektbeziehung auf Ihr systemeigenes Handle-Leck beziehen können, können Sie möglicherweise zumindest die GC-Referenzen dieser Objekte (! Gcroot) verfolgen, um weitere Hinweise zu erhalten.

Quelle

2016-07-18 17:53:15

Handle-Leck in .NET-Anwendung ausschließlich aus Speicherabbild untersuchen

Antwort

Verwandte Themen