Freigeben über


Übung 4.2 Analysieren von Kernabbilddateien auf einem anderen Computer – Verwenden von WSL zum Öffnen von Kernabbilddateien

Gilt für: .NET Core 2.1, .NET Core 3.1, .NET 5

In diesem Artikel wird erläutert, wie Sie Windows-Subsystem für Linux (WSL) Version 2 verwenden, um eine Kernabbilddatei auf einem anderen virtuellen Computer (VM) zu öffnen.

Voraussetzungen

Um diesen Abschnitt zu verfolgen und abzuschließen, sollten Sie folgendes haben:

  • Ein Windows 10-basierter Computer, um Windows-Subsystem für Linux zu aktivieren.
  • Mindestens eine Kernabbilddatei, die in einen beliebigen Ordner auf Ihren Windows-basierten Computer kopiert wird.

Ziel dieses Labors

Sie erfahren, wie Sie eine Kernabbilddatei auf einem anderen virtuellen Computer mithilfe von WSL Version 2 öffnen.

Verwenden von Windows-Subsystem für Linux

Mit WSL können Entwickler eine GNU/Linux-Umgebung direkt unter Windows ausführen, ohne dass ein herkömmlicher virtueller Computer oder ein Dual-Boot-Setup erforderlich ist.

Um WSL zu aktivieren, wechseln Sie zum Windows Server-Installationshandbuch, und führen Sie ein Upgrade auf WSL2 durch. In diesem Labor wird davon ausgegangen, dass Sie das gleiche Ubuntu 18.04 LTS wie zuvor ihr Linux-Betriebssystem ausgewählt haben. Das System wird mit WSL2 ausgeführt.

Aktualisieren Sie nach der Installation von WSL2 den Paket-Manager mithilfe der sudo apt update Befehle und sudo apt upgrade Befehle. Sie sollten mit diesen Befehlen aus den früheren Abschnitten dieser Reihe vertraut sein, wenn Sie die Linux-VM zum ersten Mal installiert haben.

  • sudo apt update

    BuggyAmb Update.

  • sudo apt upgrade

    BuggyAmb Upgrade.

Kopieren von Dateien von Windows nach Linux

Nun sollte WSL2 auf Ihrem Windows-basierten Computer ausgeführt werden. Im vorherigen Abschnitt haben Sie die Kernabbilddateien aus dem Ordner "D:\Learn\Linux\Dumps" auf Ihrem Windows-basierten Computer kopiert, und der Dateiname wurde als coredumps.tar.gz angenommen. Ihr Ziel ist jetzt, D:\Learn\Linux\Dumps\coredumps.tar.gz auf die Linux-VM zu kopieren, die in WSL2 ausgeführt wird.

Sehen Sie sich den folgenden Screenshot der Befehlszeile in WSL2 an, beachten Sie, dass das C-Laufwerk in Windows auf dem WSL2-Linux-Computer als /mnt/c zugeordnet ist. Daher können Sie ausführenll mnt/d/Learn/Linux/Dumps/, um den Inhalt des Ordners "D:\Learn\Linux\Dumps" auflisten zu können.

BugwagenAmb ll.

Kopieren und extrahieren Sie nun die coredumps.tar.gz Datei in einen Speicherabbilddateienordner im Linux-Startverzeichnis. Die Schritte sind einfach:

  1. Ändern Sie das Verzeichnis mithilfe des cd ~ Befehls in Ihr Startverzeichnis.
  2. Erstellen Sie einen Speicherabbilddateienordner, indem Sie den Ordner ausführen mkdir dumps.
  3. Extrahieren Sie die coredumps.tar.gz Datei, indem Sie ausgeführt tar -xf /mnt/d/Learn/Linux/Dumps/coredumps.tar.gz -C dumps/wird.

Der folgende Screenshot zeigt diese Befehle in Aktion.

BuggyAmb cd.

Öffnen der Kernabbilddatei mithilfe von dotnet-dump

Der Rest des Verfahrens ähnelt den früheren Problembehandlungslaboren, in denen Sie .NET Core und .NET SDK installiert haben. Dieser Abschnitt führt Sie erneut durch diese Schritte.

Das dotnet-dump-Tool erfordert .NET SDK. Daher müssen Sie vor der Installation von dotnet-dump das .NET SDK installieren. Wie bereits erwähnt, müssen Sie vor der Installation des .NET SDK den Microsoft-Paketsignaturschlüssel zur Liste der vertrauenswürdigen Schlüssel hinzufügen und dann das Paketrepository hinzufügen, wie im Installieren des SDK erläutert. Sehen Sie sich die Schritte in Aktion im folgenden Screenshot an.

BuggyAmb sudo.

Jetzt können Sie das neueste SDK erneut installieren, wie in "Installieren des SDK" erläutert. Der folgende Screenshot zeigt die Windows-Terminal, die das Ergebnis der Befehle anzeigt.

BuggyAmb SDK.

Sie öffnen die Kernabbilddatei mithilfe von dotnet-dump. Daher müssen Sie das Tool zuerst installieren. Wie bereits erwähnt, ist dotnet tool install -g dotnet-dumpder Befehl zum Installieren von dotnet-dump als globales Tool .

BuggyAmb dotnet.

Nach der Installation können Sie mit der Erkundung der Kernabbilddateien beginnen. Öffnen Sie die Kernabbilddatei mit dotnet-dump. Führen Sie wie in der vorherigen Übung den folgenden Befehl aus:

dotnet-dump analyze ~/dumps/coredump.manual.1.11724

BuggyAmb Dump.

Versuchen Sie, clrthreads die verwalteten Threads anzuzeigen. Dieser Befehl wird erwartet, dass ein Fehler auftritt und die folgende Fehlermeldung generiert wird.

Bugamb Dump2.

Die Fehlermeldung lautet wie folgt:

Mscordaccore.dll kann nicht geladen oder initialisiert werden. Die Ziellaufzeit kann nicht initialisiert werden.

Dieser Fehler tritt auf, da die erforderliche .NET Core-Laufzeit nicht auf der Linux-VM installiert ist. Wie in Debug Linux-Dumps erläutert, benötigen sowohl LLDB als auch SOS die folgenden .NET Core-Binärdateien aus der Umgebung, in der die Dumpdatei erstellt wurde:

  • libmscordaccore.so
  • libcoreclr.so
  • dotnet (der Host, der zum Starten der App verwendet wird)

Dies war in früheren Problembehandlungslaboren kein Problem, da Sie die Dumpdateien auf demselben virtuellen Computer analysiert haben, auf dem die Anwendung gehostet und ausgeführt wurde. Daher waren die Dateien bereits vorhanden. Jetzt müssen Sie entweder die richtige Version dieser Dateien von irgendwo kopieren (z. B. von der VM, auf der die Kernabbilddateien übernommen wurden), oder Sie müssen dieselbe .NET-Laufzeit auf der WSL2-Linux-VM installieren.

Es gibt mehrere Methoden, um die .NET Core-Ziellaufzeit zu ermitteln. Am einfachsten fragen Sie den Anwendungsbesitzer. Oder, wenn Sie der Besitzer sind, wissen Sie, dass die .NET Core-Ziellaufzeit der Anwendung. Was geschieht, wenn Sie diese Informationen überhaupt nicht haben? In diesem Fall können Sie einen SOS-Erweiterungsbefehl oder einen SOS-Erweiterungsbefehl verwenden, lm modulesder die systemeigenen Module auflistet, die im Prozess geladen werden. Führen Sie diesen Befehl aus, um die Version Ihrer .NET-Installation zu ermitteln.

BuggyAmb Module.

Wie in diesem Screenshot gezeigt, war die .NET Core-Laufzeitversion 3.1.10. Sie benötigen die richtige Version von libmscordaccore.so, libcoreclr.so und .NET. Sie können diese Dateien aus dem virtuellen Computer kopieren, auf dem die Kernabbilddateien generiert wurden.

Gibt es eine andere Möglichkeit, dasselbe Ergebnis zu erzielen? Können Sie z. B. .NET Core-Laufzeitversion 3.1.10 installieren, damit diese Dateien vorhanden sind? Die kurze Antwort lautet ja, Sie können. Sie können sie jedoch nicht mithilfe des sudo apt install dotnet-runtime-3.1.10 Befehls installieren.

BuggyAmb apt.

Stattdessen können Sie die .NET Core-Laufzeit 3.1 installieren. Diese Version installiert jedoch die neueste .NET Core 3.1-Version (.NET Core 3.1.15 zum Zeitpunkt, zu dem dieser Artikel geschrieben wurde).

BuggyAmb installation.

Dies funktioniert nicht, da die Kernabbilddatei für einen .NET Core 3.1.10-Prozess vorgesehen ist. Sie müssen über die übereinstimmende Version dieser erforderlichen Dateien verfügen.

Glücklicherweise gibt es ein Dotnet-Symbol-Tool , mit dem die Dateien (Symbole, DAC, Module usw.) heruntergeladen werden können, die zum Debuggen von Kernabbilddateien erforderlich sind. Sie können sich dieses Tool aus unseren früheren Abschnitten erinnern. Führen Sie den dotnet tool install -g dotnet-symbol Befehl aus, um dieses Tool zu installieren.

BuggyAmb Tool.

Jetzt müssen Sie das Dotnet-Symbol-Tool bitten, die erforderlichen Dateien herunterzuladen, die auf unsere Kernabbilddatei abzielen. Dadurch wird der Name der Kernabbilddatei und andere erforderliche Parameter übergeben: dotnet-symbol --host-only --debugging ~/dumps/coredump.manual.1.11724.

BuggyAmb-Symbol.

Sie können die letzten beiden Fehler in der Liste ignorieren. Die erforderlichen Dateien werden in den Ordner "~/dumps " heruntergeladen.

BuggyAmb ll2.

Öffnen Sie die Kernabbilddatei mithilfe von dotnet-dump, und führen Sie dieselben clrthreads Befehle aus.

KinderwagenAmb Clrthreads.

Sie sollten jetzt in der Lage sein, die Kernabbilddatei auf Ihrer Windows-VM mit WSL2 zu öffnen.

Öffnen von Dumpdateien in lldb

Diese Schritte sind identisch mit früheren Problembehandlungslaboren. Sie sollten die wichtigen Teile bereits zuvor behandelt haben, um die erforderlichen Dateien zum Debuggen von Kernabbilddateien mithilfe von dotnet-dump abzurufen. Das Verfahren ist für LLDB identisch. Wenn Sie lldb für das Debuggen installieren und verwenden möchten, überprüfen Sie die vorherigen Übungen.

Wenn dotnet-symbol die erforderlichen Dateien nicht finden kann

Dotnet-Symbol funktioniert für die meisten der Kernabbilddateien. Wenn aus irgendeinem Grund die erforderlichen Dateien nicht heruntergeladen werden können, gibt es Möglichkeiten, die Blockierung zu umgehen. Sie können die Binärdateien von der offiziellen Microsoft-Webseite herunterladen und extrahieren. Kopieren Sie dann die erforderlichen Dateien manuell in denselben Ordner, der die Kernabbilddatei enthält.

Wenn Sie z. B. die Dateien für .NET Core 3.1.10 x64 benötigen, können Sie die Binärdateien aus dieser ASP.NET Core 3.1 Runtime (v3.1.10) – Downloadseite für Linux x64-Binärdateien herunterladen und die Dateien manuell kopieren:

  • .\shared\Microsoft.NETCore.App\3.1.10\libcoreclr.so
  • .\shared\Microsoft.NETCore.App\3.1.10\libmscordaccore.so
  • .\shared\Microsoft.NETCore.App\3.1.10\libmscordbi.so
  • .\shared\Microsoft.NETCore.App\3.1.10\
  • .\dotnet

Wenn es sich bei der Ziellaufzeitversion um eine private Version handelt (denken Sie daran, dass .NET Core Open Source ist, und Sie können Ihre eigene private Version erstellen und verwenden), müssen Sie diese Dateien von der Linux-VM kopieren, auf der die Kernabbilddatei generiert wurde.

Nächste Schritte

Lab 4.3 Analysieren von Kernabbilddateien auf einem anderen Computer – Verwenden von Docker zum Öffnen von Kernabbilddateien