Freigeben über

Behandeln von Profilerstellungsfehlern und Beheben von Problemen

Dieser Artikel enthält Lösungen für einige der häufigsten Fehler, die die Verwendung oder das Abrufen ausreichender Daten aus dem Performance Profiler in Visual Studio verhindern können.

Keine Ergebnisse

Fehler: "Es gibt keine Daten in der aktuellen Gruppe von Filtern"

Beim Öffnen einer Diagsession-Datei werden bestimmte Filter angewendet, z. B. das Ausblenden von systemeigenem Code oder das Ausblenden von Nichtbenutzercode, um die Ablaufverfolgung leichter zu verstehen. Darüber hinaus gibt es weitere Filter, die angewendet werden können, z. B. Zeitauswahl und Thread, wodurch die angezeigten Daten weiter eingegrenzt werden. Wenn diese Filter so angewendet werden, dass keine Daten angezeigt werden, wird diese Warnung angezeigt.

Beheben von Korrekturen

  • Stellen Sie sicher, dass ihre Zeitauswahl Daten enthält. Wenn Sie ihre Zeitauswahl im Diagramm oberhalb der Daten geändert haben, wählen Sie " Auswahl löschen " aus, um sie zurückzusetzen.
  • Stellen Sie als Nächstes sicher, dass alle Kategorien und Threads in ihren jeweiligen Dropdowns aktiviert sind, wenn noch keine Daten vorhanden sind.
  • Wenn die Anwendung, die Sie profilieren, systemeigener Code ist, müssen Sie die Option "Nativen Code anzeigen " in der Dropdownliste "Einstellungen " aktivieren.
  • Wenn Sie immer noch keine Daten haben, war die gesammelte Ablaufverfolgung wahrscheinlich zu kurz, damit daten vorhanden sind. Stellen Sie sicher, dass das Programm, für das Sie Daten sammeln, nicht zu schnell abgeschlossen ist (weniger als eine Sekunde).

Siehe auch: Anzeigen von externem Code

Lange Dauern, bis die Ergebnisse abgeschlossen sind

Wenn die Analyse des Heaps nach dem Laden der Sammlung langsam erscheint, lesen Sie die folgenden möglichen Lösungen, mit denen Wartezeitprobleme behoben werden können.

Beheben von Korrekturen Manchmal kann es länger dauern, wenn Sie Versuchen, Momentaufnahmen aus speicherintensiven Anwendungen zu analysieren, aber ein Upgrade auf eine neuere Version von Visual Studio sollte die Wartezeit der Analyse verringern. Wenn dieses Problem nach dem Upgrade dauerhaft ist, liegt möglicherweise ein Leistungsfehler auf dem Tool vor. Erstellen Sie ein Feedbackticket, und teilen Sie die erstellte Diagsession-Datei . Mit der Datei können wir ermitteln, warum die Daten langsam zu analysieren und zu finden, wo wir Leistungsverbesserungen vornehmen können.

Stellen Sie sicher, dass Sie eine Ablaufverfolgungs- und Heap-Speicherabbilddateien im Feedbackticket bereitstellen.

Siehe auch:

Fehler "Für diese Diagsession konnte keine Manifestdatei erstellt werden" oder "Fehler konnte keine Manifestdatei für Diagsession erstellen, Visual Studio kann diese Sitzung nicht erneut öffnen."

Dieses Problem bedeutet, dass beim Vorbereiten der Speichermomentaufnahmedaten ein Problem aufgetreten ist, die analysiert und angezeigt werden, nachdem das Sammeln von Daten beendet wurde. Es gibt mehrere mögliche Ursachen für das Auftreten des Problems, von einem Fehler beim Abrufen der richtigen Informationen von den Sammlungs-Agents zur tatsächlichen Datenverarbeitung. Daher ist es nicht möglich, zu diagnostizieren, was das Problem ohne weitere Protokollierung ist.

Beheben von Korrekturen Antworten Sie mit zusätzlichen Protokollierungsinformationen auf Ihr Feedbackticket, damit wir das Problem diagnostizieren können. Sie können die Protokollinformationen abrufen, indem Sie die folgenden Befehle an einer Eingabeaufforderung mit erhöhten Rechten ausführen:

reg add HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /v LogLevel /t REG_SZ /d All /reg:32
reg add HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /v LogDirectory /t REG_SZ /d [directory of your choice] /reg:32

Nachdem Sie diese Befehle ausgeführt haben, starten Sie Visual Studio, reproduzieren Sie Ihr Szenario, schließen Sie Visual Studio, zippen Sie dann ihr ausgewähltes DiagnosticsHub-Protokollverzeichnis, und fügen Sie es an dieses Ticket an. Ab diesem Zeitpunkt sollten wir in der Lage sein, das Geschehen besser zu diagnostizieren.

Führen Sie nach dem Hinzufügen des Protokolls zu Ihrem Ticket die folgenden Befehle aus, um die Protokollierung zu deaktivieren:

reg delete HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /f /v LogLevel /reg:32
reg delete HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /f /v LogDirectory /reg:32

Fehler: "Quellinformationen sind nicht verfügbar.".

Um Quellinformationen anzuzeigen, müssen Sie über PDBs zum Zeitpunkt der Sammlung verfügen. Wenn Sie beispielsweise eine CPU-Auslastungsdiagsession-Datei sammeln, nehmen Sie einige Änderungen an Ihrem Code vor, kompilieren (wodurch die alte PBD ersetzt wird), und öffnen Sie dann die Diagsession erneut, sie könnten wahrscheinlich keine Quellinformationen für die Module Ihres Codes sehen, die Sie aktualisiert haben.

Beheben von Korrekturen Die einfachste Problemumgehung für dieses Problem besteht darin, eine neue Diagsession zu sammeln, nachdem Änderungen vorgenommen wurden. Auf diese Weise können Sie sicherstellen, dass Ihre PDBs auf dem neuesten Stand sind.

Fehler: "Fehler bei der Speicheranalyse aufgrund eines internen Fehlers.".

Nach einer langen Speicherprofilsitzung wird jeder Versuch, das Ergebnis zu analysieren, mit dem Fehler erfüllt.

Es gab einen Konflikt zwischen den Momentaufnahmeninformationen, die vom Speichertool erfasst wurden, und der des Sammlungs-Agents. Das Ergebnis bedeutet, dass das Speichertool die Heap-Zustandsdatei für eine systemeigene Momentaufnahme nicht finden konnte. Oder dieses Ergebnis konnte das Speichertool nicht mit der GC-Startzeit der Momentaufnahme mit dem in der diagsession-Datei registrierten übereinstimmen, um die GCStats abzurufen.

Beheben von Korrekturen Dieses Problem war auf einen Fehler im Tool zurückzuführen, der in Visual Studio 2022, Version 17.3, behoben wurde. Das Upgrade auf eine spätere Version sollte das Problem lösen. Wenn das Problem nach dem Upgrade noch dauerhaft ist, erstellen Sie ein Feedbackticket, und fügen Sie das Ticket an:

  • Die diagsession-Datei
  • Ein Minidump von Visual Studio
  • Screenshot der Momentaufnahmen des Speichers, die erstellt wurden.

Für dieses Problem gibt es keine Problemumgehung, und die Profilerstellungssitzung muss neu gestartet werden.

Fehler: "X-Diagnoseereignisse wurden verworfen, einige Informationen im Bericht fehlen oder ungenau"

Manchmal können Ereignisse während der Datenerfassung gelöscht werden, die dazu führen können, dass der resultierende Profilerstellungsbericht ungenau oder unbrauchbar ist. Verworfene Ereignisse können aus vielen verschiedenen Gründen auftreten, aber es tritt in erster Linie auf, wenn das System Ereignisse nicht schneller als die eingehende Rate auf dem Datenträger leeren kann.

Beheben von Korrekturen Um verworfene Ereignisse zu reduzieren, können Sie andere datenträger- und CPU-intensive Vorgänge während der Profilerstellung schließen. Durch das Schließen dieser Vorgänge kann das System weitere Ressourcen zum Leeren der eingehenden Ereignisse bereitstellen. Sie können auch versuchen, die Samplingfrequenzen für die Tools zu verringern, die diese Konfigurationseinstellungen unterstützen, z. B. das Tool für die CPU-Auslastung und das .NET-Zuordnungstool, und dadurch den Aufwand verringern.

Fehler: ETW-Ressourcen wurden erschöpft

Der Visual Studio-Profiler verwendet die Ereignisablaufverfolgung für Windows (ETW), um seine Leistungsinformationen zu sammeln. Es gibt eine begrenzte Anzahl von ETW-Sitzungen, die für die Verwendung auf einem System verfügbar sind und wenn alle Sitzungen bereits verwendet werden, erhalten Sie den folgenden Fehler: ETW resources have been exhausted Diese Sitzungen werden von anderen Programmen wie der SysInternals-Suite von Tools, anderen Profilern und anderen Diagnosetools verwendet. Sie können dieses Problem entweder beheben:

  • Schließen der Programme, die die Sitzungen verwenden, um Ressourcen freizugeben, oder

  • Wenn Sie weitere Ressourcen beiseite legen, führen Sie folgendes an einer Eingabeaufforderung mit erhöhten Rechten aus, und starten Sie dann neu:

    reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI" /v EtwMaxLoggers /t REG_DWORD /d 128

    Wenn Sie diesen Befehl ausführen, wird die Standardanzahl der Sitzungen von 64 auf 128 erhöht (256 ist die maximale Anzahl von Sitzungen, die auf einem System zulässig sind).

Fehler: Das CPU-Verwendungstool funktioniert nicht auf der VM ARM64

Der Visual Studio-Profiler verwendet die Ereignisablaufverfolgung für Windows (ETW), um seine Leistungsinformationen zu sammeln. Derzeit wird das Sammeln von Profilbeispielen mit ETW unter Windows für ARM64 nicht unterstützt, wenn sie auf einem virtuellen Computer (VM) ausgeführt wird. Um diese Einschränkung zu umgehen, können Sie entweder das CPU-Nutzungstool auf einem tatsächlichen ARM64-Gerät verwenden oder das Instrumentierungstool verwenden, um Zeitangaben zu erfassen.

Fehler: Das Tool für die Speicherauslastung funktioniert nicht unter .NET 7 und .NET Runtime 8.0.0-8.0.1 mit aktivierter Server-GC

Aufgrund eines Problems, das mit der .NET 7-Laufzeit eingeführt und an .NET 8.8-Laufzeitversionen 8.0.0 und 8.0.1 weitergegeben wurde, ist es nicht möglich, Objekte bei Verwendung der Serverbereinigung aufzählen zu können. Die Server garbage collection ist standardmäßig für ASP.NET Core-Anwendungen aktiviert.

Beheben von Korrekturen

So umgehen Sie dieses Problem:

  • Deaktivieren Sie die Garbage Collection des Servers, wenn Sie eine Momentaufnahme erstellen oder ein Abbild Ihrer Anwendung sammeln.
  • Verwenden Sie eine nicht betroffene Version der .NET-Runtime.

Siehe auch:

Verwandte Inhalte

  • Last updated on