Delen via


Diagnostische gegevens en instrumentatie

Systeemeigen AOT deelt enkele, maar niet alle, diagnostische en instrumentatiemogelijkheden met CoreCLR. Vanwege de uitgebreide selectie van diagnostische hulpprogramma's van CoreCLR is het soms geschikt om problemen in CoreCLR vast te stellen en op te sporen. Apps die compatibel zijn met trim moeten geen gedragsverschillen hebben, dus onderzoeken zijn vaak van toepassing op beide runtimes. Echter, sommige informatie kan alleen worden verzameld na publicatie, dus Systeemeigen AOT biedt ook diagnostische hulpprogramma's voor publiceren na publicatie.

Diagnostische ondersteuning voor .NET 8 Native AOT

De volgende tabel bevat een overzicht van diagnostische functies die worden ondersteund voor systeemeigen AOT-implementaties:

Functie Volledig ondersteund Gedeeltelijk ondersteund Niet ondersteund
Waarneembaarheid en telemetrie Gedeeltelijk ondersteund
Diagnostische gegevens over ontwikkelingstijd Volledig ondersteund
Systeemeigen foutopsporing Gedeeltelijk ondersteund
CPU-profilering Gedeeltelijk ondersteund
Heap-analyse Niet ondersteund

Waarneembaarheid en telemetrie

Vanaf .NET 8 ondersteunt de Native AOT-runtime EventPipe. Dit is de basislaag die wordt gebruikt door veel bibliotheken voor logboekregistratie en tracering. U kunt rechtstreeks met EventPipe interfacen via API's zoals EventSource.WriteEvent of u kunt bibliotheken gebruiken die bovenaan zijn gebouwd, zoals OpenTelemetry. Met EventPipe-ondersteuning kunnen ook diagnostische hulpprogramma's van .NET, zoals dotnet-trace, dotnet-counters en dotnet-monitor naadloos werken met systeemeigen AOT- of CoreCLR-toepassingen. EventPipe is een optioneel onderdeel in systeemeigen AOT. Als u EventPipe-ondersteuning wilt opnemen, stelt u de EventSourceSupport eigenschap MSBuild in op true.

<PropertyGroup>
    <EventSourceSupport>true</EventSourceSupport>
</PropertyGroup>

Systeemeigen AOT biedt gedeeltelijke ondersteuning voor sommige bekende gebeurtenisproviders. Niet alle runtime-gebeurtenissen worden ondersteund in systeemeigen AOT.

Diagnostische gegevens over ontwikkelingstijd

De .NET CLI-hulpprogramma's (dotnet SDK) en Visual Studio bieden afzonderlijke opdrachten voor build en publish. build (of Start in Visual Studio) maakt gebruik van CoreCLR. Er wordt alleen publish een systeemeigen AOT-toepassing gemaakt. Het publiceren van uw app als systeemeigen AOT produceert een app die vooraf is gecompileerd naar systeemeigen code. Zoals eerder vermeld, werken niet alle diagnostische hulpprogramma's naadloos met gepubliceerde Systeemeigen AOT-toepassingen in .NET 8. Alle diagnostische hulpprogramma's van .NET zijn echter beschikbaar voor ontwikkelaars tijdens de fase van het bouwen van toepassingen. We raden u aan de toepassingen zoals gewoonlijk te ontwikkelen, fouten op te sporen en te testen en de werkende app met Native AOT te publiceren als een van de laatste stappen.

Systeemeigen foutopsporing

Wanneer u uw app uitvoert tijdens de ontwikkeling, zoals in Visual Studio of met dotnet run, dotnet buildof dotnet test, wordt deze standaard uitgevoerd op CoreCLR. Als PublishAot het projectbestand aanwezig is, moet het gedrag echter hetzelfde zijn tussen CoreCLR en Systeemeigen AOT. Met dit kenmerk kunt u de standaard door Visual Studio beheerde foutopsporingsengine gebruiken voor ontwikkeling en testen.

Na publicatie zijn systeemeigen AOT-toepassingen echte systeemeigen binaire bestanden. Het beheerde foutopsporingsprogramma werkt er niet aan. De systeemeigen AOT-compiler genereert echter volledig systeemeigen uitvoerbare bestanden die systeemeigen foutopsporingsprogramma's kunnen opsporen op uw platform (bijvoorbeeld WinDbg of Visual Studio in Windows en gdb of lldb op Unix-achtige systemen).

De systeemeigen AOT-compiler genereert informatie over regelnummers, typen, lokale bevolking en parameters. Met het systeemeigen foutopsporingsprogramma kunt u stacktracering en variabelen inspecteren, in- of over bronlijnen stappen of regelonderbrekingspunten instellen.

Als u fouten in beheerde uitzonderingen wilt opsporen, stelt u een onderbrekingspunt in voor de RhThrowEx methode, die wordt aangeroepen wanneer een beheerde uitzondering wordt gegenereerd. De uitzondering wordt opgeslagen in het rcx of x0 register. Als uw foutopsporingsprogramma ondersteuning biedt voor het weergeven van C++-objecten, kunt u het register casten voor S_P_CoreLib_System_Exception* meer informatie over de uitzondering.

Het verzamelen van een dumpbestand voor een systeemeigen AOT-toepassing omvat enkele handmatige stappen in .NET 8.

Visual Studio-specifieke notities

U kunt een systeemeigen met AOT gecompileerd uitvoerbaar bestand starten onder het foutopsporingsprogramma van Visual Studio door het te openen in de Visual Studio IDE. U moet het uitvoerbare bestand zelf openen in Visual Studio.

Als u een onderbrekingspunt wilt instellen dat wordt verbroken wanneer er een uitzondering wordt gegenereerd, kiest u de optie Onderbrekingspunten in het menu Foutopsporing > in Windows. Selecteer in het nieuwe venster het onderbrekingspunt Nieuwe > functie . Geef RhThrowEx op als de functienaam en laat de optie Taal staan op Alle talen (selecteer geen C#).

Als u wilt zien welke uitzondering is opgetreden, start u foutopsporing (foutopsporing> starten of F5 opsporen), opent u het venster Controle (Fouten opsporen in > Windows > Watch) en voegt u de volgende expressie toe als een van de horloges: (S_P_CoreLib_System_Exception*)@rcx Dit mechanisme maakt gebruik van het feit dat op dat moment RhThrowEx wordt aangeroepen, de x64 CPU-register RCX de gegenereerde uitzondering bevat. U kunt de expressie ook in het venster Direct plakken. de syntaxis is hetzelfde als voor horloges.

Belang van het symboolbestand

Bij het publiceren produceert de systeemeigen AOT-compiler zowel een uitvoerbaar als een symboolbestand. Systeemeigen foutopsporing en gerelateerde activiteiten, zoals profilering, vereisen toegang tot het systeemeigen symboolbestand. Als dit bestand niet aanwezig is, hebt u mogelijk gedegradeerde of verbroken resultaten.

Zie Systeemeigen foutopsporingsgegevens voor informatie over de naam en locatie van het symboolbestand.

CPU-profilering

Platformspecifieke hulpprogramma's zoals PerfView en Perf kunnen worden gebruikt om CPU-voorbeelden van een systeemeigen AOT-toepassing te verzamelen.

Heap-analyse

Beheerde heap-analyse wordt momenteel niet ondersteund in systeemeigen AOT. Heap-analysehulpprogramma's zoals dotnet-gcdump, PerfView en Visual Studio heap-analysehulpprogramma's werken niet in systeemeigen AOT in .NET 8.