Freigeben über


Einrichten eines Release zur Diagnose von Problemen nach der Bereitstellung

Um Probleme mit der Webanwendung ASP.NET nach der Bereitstellung mit IntelliTrace zu diagnostizieren, geben Sie Buildinformationen zu Ihrer Version mit an, damit Visual Studio automatisch die richtigen Quelldateien und Symboldateien findet, die für das Debuggen des IntelliTrace-Protokolls erforderlich sind.

Wenn Sie Microsoft Monitoring Agent zur Steuerung von IntelliTrace verwenden, müssen Sie Application Performance Monitoring auf dem Webserver einrichten. Auf diese Weise werden Diagnoseereignisse beim Betrieb Ihrer App gesammelt und in einer IntelliTrace-Protokolldatei gespeichert. Anschließend können Sie die Ereignisse in Visual Studio Ultimate öffnen, zum betreffenden Code springen, die aufgezeichneten Werte zum jeweiligen Zeitpunkt anzeigen und den ausgeführten Code vorwärts oder rückwärts durchlaufen. Nachdem Sie das Problem gefunden und behoben haben, wiederholen Sie den Zyklus zum Erstellen, Freigeben und Überwachen der Version, um zukünftige Probleme früher und schneller beheben zu können.

Codierung, Erstellung, Freigabe, Überwachung, Diagnose, Korrektur

Sie benötigen Folgendes:

  • Microsoft Visual Studio 2013 oder Team Foundation Server 2013, 2012 oder 2010 zum Erstellen Ihres Builds

  • Microsoft Monitoring Agent zum Überwachen der App und zum Aufzeichnen von Diagnosedaten

  • Visual Studio Ultimate 2013 zum Anzeigen von Diagnosedaten und Debuggen Ihres Codes mit IntelliTrace

Schritt 1: Aufnehmen der Buildinformationen in Ihre Version

Richten Sie den Buildprozess ein, um eine Buildmanifestdatei (BuildInfo.config) für Ihr Webprojekt zu erstellen und fügen Sie dieses Manifest in Ihre Version ein. Dieses Manifest enthält Informationen über Projekt, Quellcodeverwaltung und Buildsystem, die für die Erstellung einer bestimmten Version verwendet wurden. Mit diesen Informationen kann Visual Studio die entsprechenden Quellen und Symbole finden, nachdem Sie das IntelliTrace-Protokoll geöffnet haben, um die aufgezeichneten Ereignisse zu prüfen.

Erstellen des Buildmanifests für einen automatischen Buildvorgang mithilfe von Team Foundation Server

Führen Sie diese Schritte aus, egal ob Sie Team Foundation oder Git als Versionskontrolle verwenden.

Team Foundation Server 2013

Richten Sie Ihre Builddefinition so ein, dass diese den Ort Ihrer Quellen sowie Build und Symbole in das Buildmanifest (BuildInfo.config-Datei) schreibt. Team Foundation Build erstellt diese Datei automatisch und fügt sie in das Ausgabeverzeichnis Ihres Projekts ein.

  1. Bearbeiten Sie die Builddefinition oder erstellen Sie eine neue.

    Builddefinition in TFS 2013 anzeigen

  2. Wählen Sie die Standardvorlage (TfvcTemplate.12.xaml) oder eine eigene benutzerdefinierte Vorlage aus.

    Buildprozessvorlage auswählen – TFS 2013

  3. Geben Sie an, wo die Symboldatei (PDB) gespeichert werden soll, sodass die Quelle automatisch indiziert wird.

    Wenn Sie eine benutzerdefinierte Vorlage verwenden, vergewissern Sie sich, dass die Vorlage über eine Aktivität zum Indizieren der Quelle verfügt. Später fügen Sie ein MSBuild-Argument hinzu, um anzugeben, wo die Symboldateien gespeichert werden sollen.

    Symbolpfade in Builddefinition TFS 2013 einrichten

    Weitere Informationen über Symbole finden Sie unter Veröffentlichen von Symboldaten.

  4. Fügen Sie dieses MSBuild-Argument hinzu, um TFS und Symboldateispeicherorte zur Buildmanifestdatei hinzuzufügen:

    /p:IncludeServerNameInBuildInfo=True

    Jeder, der auf Ihren Webserver zugreifen kann, kann diese Speicherorte im Buildmanifest anzeigen. Achten Sie darauf, dass Ihr Quellserver sicher ist.

  5. Wenn Sie eine benutzerdefinierte Vorlage verwenden, fügen Sie dieses MSBuild-Argument hinzu, um anzugeben, wo die Symboldatei gespeichert werden soll:

    /p:BuildSymbolStorePath=<Pfad zu Symbolen>

    Buildserverinformationen in Builddefinition TFS 2013 einschließen

    Fügen Sie der Webprojektdatei (CSPROJ oder VBPROJ) diese Zeilen hinzu:

    <!-- Import the targets file. Change the folder location as necessary. -->
       <Import Project=""$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\BuildInfo\Microsoft.VisualStudio.ReleaseManagement.BuildInfo.targets" />
    
  6. Führen Sie einen neuen Build aus.

Schritt 2: Freigeben der App

Team Foundation Server 2012 oder 2010

Führen Sie die folgenden Schritte aus, um das Buildmanifest (BuildInfo.config) für Ihr Projekt automatisch zu erstellen und in das Ausgabeverzeichnis Ihres Projekts einzufügen. Die Datei erscheint als "ProjektName.BuildInfo.config" im Ausgabeverzeichnis, wird jedoch im Bereitstellungsverzeichnis als "BuildInfo.config" umbenannt, nachdem Sie Ihre App veröffentlicht haben.

  1. Installieren Sie eine beliebige Edition von Visual Studio 2013 auf Ihrem Team Foundation Build-Server.

  2. Geben Sie in Ihrer Builddefinition an, wo die Symbole gespeichert werden sollen, sodass die Quelle automatisch indiziert wird.

    Wenn Sie eine benutzerdefinierte Vorlage verwenden, vergewissern Sie sich, dass die Vorlage über eine Aktivität zum Indizieren der Quelle verfügt.

  3. Fügen Sie der Builddefinition die folgenden MSBuild-Argumente hinzu:

    • /p:VisualStudioVersion=12.0

    • /p:MSBuildAssemblyVersion=12.0

    • /tv:12.0

    • /p:IncludeServerNameInBuildInfo=True

    • /p:BuildSymbolStorePath=<Pfad zu Symbolen>

  4. Führen Sie einen neuen Build aus.

Schritt 2: Freigeben der App

Erstellen des Buildmanifests für einen manuellen Buildvorgang mithilfe von Visual Studio 2013

Führen Sie die folgenden Schritte aus, um das Buildmanifest (BuildInfo.config) für Ihr Projekt automatisch zu erstellen und in das Ausgabeverzeichnis Ihres Projekts einzufügen. Die Datei erscheint als "ProjektName.BuildInfo.config" im Ausgabeverzeichnis, wird jedoch im Bereitstellungsverzeichnis als "BuildInfo.config" umbenannt, nachdem Sie Ihre App veröffentlicht haben.

  1. Entladen Sie das Webprojekt im Projektmappen-Explorer.

  2. Öffnen Sie die Projektdatei (.csproj, .vbproj). Fügen Sie die folgenden Zeilen ein:

    <!-- **************************************************** -->
    <!-- Build info -->
    <PropertyGroup>
       <!-- Generate the BuildInfo.config file -->
       <GenerateBuildInfoConfigFile>True</GenerateBuildInfoConfigFile>
       <!-- Include server name in build info --> 
       <IncludeServerNameInBuildInfo>True</IncludeServerNameInBuildInfo> 
       <!-- Include the symbols path so Visual Studio can find the matching deployed code when you start debugging. -->
       <BuildSymbolStorePath><path to symbols></BuildSymbolStorePath>
    </PropertyGroup>
    <!-- **************************************************** -->
    
  3. Checken Sie die aktualisierte Projektdatei ein.

  4. Führen Sie einen neuen Build aus.

Schritt 2: Freigeben der App

Erstellen des Buildmanifests für einen manuellen Buildvorgang mithilfe von MSBuild.exe

Fügen Sie diese Buildargumente beim Ausführen des Builds hinzu:

/p:GenerateBuildInfoConfigFile=True

/p:IncludeServerNameInBuildInfo=True

/p:BuildSymbolStorePath=<Pfad zu Symbolen>

Schritt 2: Freigeben der App

Wenn Sie das Web.Deploy-Paket verwenden, das vom Build-Prozess zum Bereitstellen Ihrer App erstellt wurde, wird das Buildmanifest automatisch von "ProjektName.BuildInfo.config" zu "BuildInfo.config" umbenannt und auf dem Webserver im gleichen Verzeichnis wie die Web.config-Datei Ihrer App abgelegt.

Wenn Sie eine andere Methode zum Bereitstellen Ihrer App verwenden, müssen Sie sicherstellen, dass das Buildmanifest von "ProjektName.BuildInfo.config" zu "BuildInfo.config" umbenannt und auf dem Webserver im gleichen Verzeichnis wie die Web.config-Datei Ihrer App abgelegt wird.

Schritt 3: Überwachen der App

Richten Sie Leistungsüberwachung für Ihre App auf dem Webserver ein, um Ihre App auf Probleme zu untersuchen, Diagnoseereignisse aufzuzeichnen und diese Ereignisse in einer IntelliTrace-Protokolldatei zu speichern. Siehe Überwachen Ihrer App auf Bereitstellungsprobleme.

Schritt 4: Erkennen des Problems

Sie benötigen Visual Studio Ultimate 2013 auf Ihrem Entwicklungscomputer oder einem anderen Computer, um die aufgezeichneten Ereignisse anzuzeigen und Ihren Code mit IntelliTrace zu debuggen. Sie können alternativ Tools wie CodeLens, IntelliTrace, Debuggerzuordnungen und Codezuordnungen verwenden, um das Problem zu diagnostizieren.

Öffnen des IntelliTrace-Protokolls und der entsprechenden Projektmappe

  1. Öffnen Sie das IntelliTrace-Protokoll (.iTrace-Datei) in Visual Studio Ultimate 2013. Oder doppelklicken Sie einfach auf die Datei, wenn Visual Studio Ultimate 2013 auf demselben Computer installiert ist.

  2. Wählen Sie Projektmappe öffnen aus, damit die entsprechende Projektmappe oder das Projekt automatisch in Visual Studio geöffnet wird, wenn das Projekt nicht als Teil einer Projektmappe erstellt wurde. Im IntelliTrace-Protokoll fehlen Informationen über die bereitgestellte App. Wie konnte das geschehen? Was kann ich unternehmen?

    Visual Studio legt alle ausstehenden Änderungen automatisch ab, wenn die entsprechende Projektmappe oder das Projekt geöffnet wird. Nähere Informationen zu diesem Shelvesets finden Sie im Fenster Ausgabe oder Team Explorer.

    Bevor Sie Änderungen vornehmen, sollten Sie überprüfen, ob Sie über die richtige Quelle verfügen. Wenn Sie Verzweigung verwenden kann es sein, dass die aktuelle Verzweigung von der Verzweigung abweicht, in der Visual Studio die entsprechende Quelle findet, z. B. Ihre Versionsverzweigung.

    Projektmappe über IntelliTrace-Protokoll öffnen

    Wenn Sie einen Arbeitsbereich zu dieser Lösung oder diesem Projekt zugeordnet haben, wählt Visual Studio diesen Arbeitsbereich aus, um die gesuchte Quelle einzufügen.

    Aus Quellcodeverwaltung öffnen – an zugeordneten Arbeitsbereich

    Andernfalls wählen Sie einen anderen Arbeitsbereich aus oder erstellen Sie einen neuen Arbeitsbereich. Visual Studio ordnet diesem Arbeitsbereich die gesamte Verzweigung zu.

    Aus Quellcodeverwaltung öffnen – neuen Arbeitsbereich erstellen

    Um einen Arbeitsbereich mit bestimmten Zuordnungen oder einen Namen zu erstellen, der nicht Ihrem Computernamen entspricht, wählen Sie Verwalten aus.

    Warum meldet Visual Studio, dass mein ausgewählter Arbeitsbereich ungültig ist?

    Warum kann ich den Vorgang erst fortsetzen, wenn ich eine Teamauflistung oder eine andere Auflistung ausgewählt habe?

Diagnose eines Leistungsproblems

  1. Unter Leistungsverletzungen überprüfen Sie die aufgezeichneten Leistungsereignisse, ihre Gesamtausführungszeiten und andere Ereignisinformationen. Sehen Sie sich anschließend die Details der Methoden näher an, die während eines bestimmten Leistungsereignisses aufgerufen wurden.

    Informationen zum Leistungsereignis anzeigen

    Sie können auch einfach auf das Ereignis doppelklicken.

  2. Überprüfen Sie auf der Ereignisseite die Ausführungszeiten für diese Aufrufe. Suchen Sie einen langsamen Aufruf in der Ausführungsstruktur.

    Die langsamsten Aufrufe werden in einem eigenen Bereich angezeigt, wenn Sie mehrere, geschachtelte oder andere Aufrufe haben.

    Erweitern Sie diesen Aufruf, um alle geschachtelten Aufrufe und Werte zu überprüfen, die zu diesem Zeitpunkt aufgezeichnet wurden. Starten Sie dann das Debuggen über diesen Aufruf.

    Debuggen über Methodenaufruf starten

    Sie können auch einfach auf den Aufruf doppelklicken.

    Wenn die Methode in Ihrem Anwendungscode enthalten ist, wechselt Visual Studio zu dieser Methode.

    Zum Anwendungscode von einem Leistungsereignis aus wechseln

    Jetzt können Sie andere aufgezeichnete Werte und die Aufrufliste überprüfen, den Code schrittweise durchlaufen oder das Fenster IntelliTrace verwenden, um sich zwischen anderen Methoden zeitlich rückwärts oder vorwärts zu bewegen, die während dieses Leistungsereignisses aufgerufen wurden. Was bedeuten die restlichen Ereignisse und Informationen im IntelliTrace-Protokoll? Welche weiteren Möglichkeiten gibt es hier? Wünschen Sie weitere Informationen zu Leistungsereignissen?

Diagnose einer Ausnahme

  • Überprüfen Sie unter Ausnahmedaten die aufgezeichneten Ausnahmeereignisse, deren Typen und Meldungen und wann die Ausnahmen aufgetreten sind. Um tiefer in den Code zu vorzudringen, starten Sie das Debuggen des letzten Ereignisses in einer Gruppe von Ausnahmen.

    Debuggen von einem Ausnahmeereignis aus starten

    Sie können auch einfach auf das Ereignis doppelklicken.

    Wenn die Ausnahme im Anwendungscode aufgetreten ist, wechselt Visual Studio zu der Stelle, an der die Ausnahme aufgetreten ist.

    Zum Anwendungscode von einem Ausnahmeereignis aus wechseln

    Jetzt können Sie andere aufgezeichnete Werte und die Aufrufliste überprüfen oder das Fenster IntelliTrace verwenden, um sich zwischen anderen aufgezeichneten Ereignissen, zugehörigem Code und den Werten zu bewegen, die zu diesen Zeitpunkten erfasst wurden. Was bedeuten die restlichen Ereignisse und Informationen im IntelliTrace-Protokoll?

Welche weiteren Möglichkeiten gibt es hier?

Fragen und Antworten

F: Warum sollte ich Informationen über mein Projekt, die Quellcodeverwaltung, Version und Symbole in meine Version integrieren?

Visual Studio verwendet diese Informationen, um die passende Lösung und den entsprechenden Quellcode für die Version zu finden, die Sie gerade debuggen. Nachdem Sie das IntelliTrace-Protokoll geöffnet und ein zu debuggendes Ereignis ausgewählt haben, zeigt Ihnen Visual Studio anhand der Symbole den Code, in dem das Ereignis aufgetreten ist. Anschließend können Sie die aufgezeichneten Werte anzeigen und den ausgeführten Code vorwärts und rückwärts durchlaufen.

Falls Sie TFS verwenden und Ihr Buildmanifest (Datei BuildInfo.config) diese Informationen nicht enthält, sucht Visual Studio in Ihrem aktuell verbundenen TFS nach dem passenden Quellcode und den entsprechenden Symbolen. Wenn Visual Studio das korrekte TFS oder den entsprechenden Quellcode nicht findet, werden Sie aufgefordert, ein anderes TFS auszuwählen.

F: Im IntelliTrace-Protokoll fehlen Informationen über die bereitgestellte App.Wie konnte das geschehen?Was kann ich unternehmen?

Dies kann geschehen, wenn Sie die App von Ihrem Entwicklungscomputer bereitstellen oder bei der Bereitstellung nicht mit dem TFS verbunden sind.

  1. Öffnen Sie den Bereitstellungsordner Ihres Projekts.

  2. Suchen und öffnen Sie das Buildmanifest (BuildInfo.config-Datei).

  3. Vergewissern Sie sich, dass die folgenden Informationen enthalten sind:

Feld

Bedeutung

ProjectName

Der Name Ihres Projekts in Visual Studio. Beispiel:

<ProjectName>FabrikamFiber.Extranet.Web</ProjectName>

SourceControl

Informationen über Ihr Quellcodeverwaltungssystem und die folgenden erforderlichen Eigenschaften:

  • TFS

    • ProjectCollectionUri: der URI für Ihren Team Foundation Server und Ihre Projektsammlung

    • ProjectItemSpec: der Pfad zur Projektdatei Ihrer App (.csproj oder .vbproj)

    • ProjectVersionSpec: die Version Ihres Projekts

    Beispiel:

    <SourceControl type="TFS">
       <TfsSourceControl>
          <ProjectCollectionUri>http://fabrikamfiber:8080/tfs/FabrikamFiber</ProjectCollectionUri>
          <ProjectItemSpec>$/WorkInProgress/FabrikamFiber/FabrikamFiber.CallCenter/FabrikamFiber.Web/FabrikamFiber.Web.csproj</ProjectItemSpec>
          <ProjectVersionSpec>LFabrikamFiber_BuildAndPublish_20130813@$/WorkInProgress</ProjectVersionSpec>
       </TfsSourceControl>
    </SourceControl>
  • Git

    • GitSourceControl: der Speicherort des GitSourceControl-Schemas

    • RepositoryUrl: der URI für Ihren Team Foundation Server, Ihre Projektsammlung und Ihr Git-Repository

    • ProjectPath: der Pfad zur Projektdatei Ihrer App (.csproj oder .vbproj)

    • CommitId: die ID Ihres Commits

    Beispiel:

    <SourceControl type="Git"> 
       <GitSourceControl xmlns="https://schemas.microsoft.com/visualstudio/deploymentevent_git/2013/09">
          <RepositoryUrl>http://gittf:8080/tfs/defaultcollection/_git/FabrikamFiber</RepositoryUrl>
          <ProjectPath>/FabrikamFiber.CallCenter/FabrikamFiber.Web/FabrikamFiber.Web.csproj</ProjectPath>
          <CommitId>50662c96502dddaae5cd5ced962d9f14ec5bc64d</CommitId>
       </GitSourceControl>
    </SourceControl>

Build

Informationen über Ihr Buildsystem, entweder "TeamBuild" oder "MSBuild", sowie die folgenden erforderlichen Eigenschaften:

  • BuildLabel (für TeamBuild): Buildname und -Nummer. Diese Bezeichnung wird auch als Name des Bereitstellungsereignisses verwendet. Weitere Informationen zu Buildnummern finden Sie unter Verwenden von Buildnummern, um abgeschlossene Builds mit aussagekräftigen Namen zu versehen.

  • SymbolPath (empfohlen): die Liste der URIs für die Orte Ihrer Symbole (PDB-Datei) getrennt durch Semikolons. Diese URIs können URLs oder Netzwerkpfade (UNC) sein. Dies erleichtert Visual Studio das Auffinden der entsprechenden Symbole zum Debuggen.

  • BuildReportUrl (für TeamBuild): Buildberichtsspeicherort in TFS

  • BuildId (für TeamBuild): URI für die Builddetails in TFS. Dieser URI wird auch als ID des Bereitstellungsereignisses verwendet. Diese ID muss eindeutig sein, wenn Sie TeamBuild nicht verwenden.

  • BuiltSolution: der Pfad zur Projektmappendatei, die Visual Studio zum Suchen und Öffnen der entsprechenden Projektmappe verwendet. Dies ist der Inhalt der MsBuild-Eigenschaft SolutionPath.

Beispiel:

  • TFS

    <Build type="TeamBuild">
       <MsBuild>
          <BuildLabel kind="label">FabrikamFiber_BuildAndPublish_20130813.1</BuildLabel>
          <SymbolPath>\\fabrikamfiber\FabrikamFiber.CallCenter\Symbols</SymbolPath>
          <BuildReportUrl kind="informative, url" url="http://fabrikamfiber:8080/tfs/FabrikamFiber/_releasePipeline/FindRelease?buildUri=fabrikamfiber%3a%2f%2f%2fBuild%2fBuild%2f448">Build Report Url</BuildReportUrl>
          <BuildId kind="id">1c4444d2-518d-4673-a590-dce2773c7744,fabrikamfiber:///Build/Build/448</BuildId>
          <BuiltSolution>$/WorkInProgress/FabrikamFiber/FabrikamFiber.CallCenter/FabrikamFiber.CallCenter.sln</BuiltSolution>
       </MsBuild>
    </Build>
  • Git

    <Build type="MSBuild"> 
       <MSBuild>
          <SymbolPath>\\gittf\FabrikamFiber.CallCenter\Symbols</SymbolPath>
          <BuiltSolution>/FabrikamFiber.CallCenter/FabrikamFiber.CallCenter.sln</BuiltSolution>
       </MSBuild>
    </Build>

F: Warum meldet Visual Studio, dass mein ausgewählter Arbeitsbereich ungültig ist?

A: Der ausgewählte Arbeitsbereich besitzt keine Zuordnungen zwischen dem Quellverwaltungsordner und einem lokalen Ordner. Um eine Zuordnung für diesen Arbeitsbereich zu erstellen, wählen Sie Verwalten aus. Andernfalls wählen Sie einen bereits zugeordneten Arbeitsbereich aus oder erstellen Sie einen neuen Arbeitsbereich.

Aus Quellcodeverwaltung öffnen – ohne zugeordneten Arbeitsbereich

F: Warum kann ich den Vorgang erst fortsetzen, wenn ich eine Teamauflistung oder eine andere Auflistung ausgewählt habe?

A: Dies kann aus folgenden Gründen der Fall sein:

  • Visual Studio ist nicht mit dem TFS verbunden.

    Aus Quellcodeverwaltung öffnen – nicht verbunden

  • Visual Studio konnte die Projektmappe oder das Projekt nicht in der aktuellen Teamauflistung finden.

    Wenn die Buildmanifestdatei (<ProjektName>.BuildInfo.config) nicht angibt, wo Visual Studio die entsprechende Quelle finden kann, verwendet Visual Studio den aktuell verbundenen TFS, um die entsprechende Projektmappe oder das Projekt zu suchen. Wenn die aktuelle Teamauflistung nicht über die entsprechende Quelle verfügt, fordert Visual Studio Sie auf, eine Verbindung mit einer anderen Teamauflistung herzustellen.

  • Visual Studio konnte die Projektmappe oder das Projekt nicht in der von der Buildmanifestdatei (<ProjektName>.BuildInfo.config) angegeben Sammlung finden.

    Der angegebene TFS verfügt möglicherweise nicht mehr über die entsprechende Quelle oder Sie ist nicht mehr vorhanden, da Sie möglicherweise zu einem neuen TFS migriert sind. Wenn der angegebene TFS nicht vorhanden ist, kann bei Visual Studio nach etwa einer Minute ein Timeout auftreten, und Sie werden anschließend aufgefordert, eine Verbindung mit einer anderen Auflistung herzustellen. Um den Vorgang fortzusetzen, stellen Sie eine Verbindung mit dem richtigen TFS her.

    Aus Quellcodeverwaltung öffnen – migriert

F: Was ist ein Arbeitsbereich?

A: Der Arbeitsbereich speichert eine Kopie der Quelle sodass Sie sie separat entwickeln und testen können, bevor Sie die Arbeit einchecken. Wenn Sie nicht bereits über einen Arbeitsbereich verfügen, der der gefundenen Projektmappe oder dem Projekt speziell zugeordnet ist, dann werden Sie von Visual Studio aufgefordert, einen verfügbaren Arbeitsbereich auszuwählen oder einen neuen Arbeitsbereich mit Ihrem Computernamen als Standardarbeitsbereichsname zu erstellen.

F: Warum erhalte ich diese Meldung über nicht vertrauenswürdige Symbole?

Debuggen mit nicht vertrauenswürdigem Symbolpfad durchführen?

A: Diese Meldung wird angezeigt, wenn der Symbolpfad in der Buildmanifestdatei (<ProjectName>.BuildInfo.config) nicht in der Liste der vertrauenswürdigen Symbolpfade enthalten ist. Sie können den Pfad zur Liste der Symbolpfade in den Debuggeroptionen hinzufügen.