Diagnostik och instrumentation

Artikel
10/18/2023

Intern AOT delar vissa, men inte alla, diagnostik- och instrumentationsfunktioner med CoreCLR. På grund av CoreCLR:s omfattande urval av diagnostikverktyg är det ibland lämpligt att diagnostisera och felsöka problem i CoreCLR. Appar som är trimkompatibla bör inte ha beteendeskillnader, så undersökningar gäller ofta för båda körningarna. En del information kan dock bara samlas in efter publicering, så intern AOT tillhandahåller även diagnostikverktyg efter publicering.

.NET 8 Inbyggt AOT-diagnostikstöd

I följande tabell sammanfattas diagnostikfunktioner som stöds för interna AOT-distributioner:

Funktion	Stöds fullt ut	Delvis stöd	Stöds inte
Observerbarhet och telemetri		Delvis stöd
Diagnostik för utvecklingstid	Stöds fullt ut
Intern felsökning		Delvis stöd
CPU-profilering		Delvis stöd
Heapanalys			Stöds ej

Observerbarhet och telemetri

Från och med .NET 8 stöder den interna AOT-körningen EventPipe, som är basskiktet som används av många loggnings- och spårningsbibliotek. Du kan gränssnitt med EventPipe direkt via API:er som EventSource.WriteEvent eller så kan du använda bibliotek som bygger på toppen, till exempel OpenTelemetry. EventPipe-stöd tillåter också att .NET-diagnostikverktyg som dotnet-trace, dotnet-counters och dotnet-monitor fungerar sömlöst med interna AOT- eller CoreCLR-program. EventPipe är en valfri komponent i intern AOT. Om du vill inkludera EventPipe-stöd anger du EventSourceSupport egenskapen MSBuild till true.

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

Intern AOT ger delvis stöd för vissa välkända händelseprovidrar. Alla körningshändelser stöds inte i intern AOT.

Diagnostik för utvecklingstid

.NET CLI-verktygen (dotnet SDK) och Visual Studio erbjuder separata kommandon för build och publish. build (eller Start i Visual Studio) använder CoreCLR. Skapar endast publish ett internt AOT-program. När du publicerar din app som intern AOT skapas en app som har kompilerats i förväg (AOT) till inbyggd kod. Som tidigare nämnts fungerar inte alla diagnostikverktyg sömlöst med publicerade interna AOT-program i .NET 8. Alla .NET-diagnostikverktyg är dock tillgängliga för utvecklare under programskapandefasen. Vi rekommenderar att du utvecklar, felsöker och testar programmen som vanligt och publicerar arbetsappen med intern AOT som ett av de sista stegen.

Intern felsökning

När du kör din app under utvecklingen, till exempel i Visual Studio, eller med dotnet run, dotnet buildeller dotnet test, körs den som standard på CoreCLR. Men om PublishAot finns i projektfilen bör beteendet vara detsamma mellan CoreCLR och intern AOT. Med den här egenskapen kan du använda visual studio-standardmotorn för hanterad felsökning för utveckling och testning.

Efter publiceringen är interna AOT-program sanna interna binärfiler. Det hanterade felsökningsprogrammet fungerar inte på dem. Den interna AOT-kompilatorn genererar dock helt inbyggda körbara filer som interna felsökningsprogram kan felsöka på valfri plattform (till exempel WinDbg eller Visual Studio i Windows och gdb eller lldb på Unix-liknande system).

Den interna AOT-kompilatorn genererar information om radnummer, typer, lokalbefolkningen och parametrar. Med det interna felsökningsprogrammet kan du inspektera stackspårning och variabler, gå in i eller över källlinjer eller ange radbrytningspunkter.

Om du vill felsöka hanterade undantag anger du en brytpunkt för RhThrowEx metoden, som anropas när ett hanterat undantag utlöses. Undantaget lagras i rcx eller x0 registreras. Om felsökningsprogrammet stöder visning av C++-objekt kan du skicka registret till S_P_CoreLib_System_Exception* för att se mer information om undantaget.

Insamling av en dumpfil för ett internt AOT-program omfattar några manuella steg i .NET 8.

Visual Studio-specifika anteckningar

Du kan starta en intern AOT-kompilerad körbar fil under Visual Studio-felsökningsprogrammet genom att öppna den i Visual Studio IDE. Du måste öppna själva körbara filen i Visual Studio.

Om du vill ange en brytpunkt som bryts när ett undantag utlöses väljer du alternativet Brytpunkter på Menyn Felsöka > Windows . I det nya fönstret väljer du Ny > funktions brytpunkt. Ange RhThrowEx som funktionsnamn och lämna alternativet Språk på Alla språk (välj inte C#).

Om du vill se vilket undantag som utlöstes börjar du felsöka (Felsök > startfelsökning eller F5), öppnar bevakningsfönstret (Felsök > Windows > Watch) och lägger till följande uttryck som en av klockorna: (S_P_CoreLib_System_Exception*)@rcx. Den här mekanismen utnyttjar det faktum att vid den tidpunkten RhThrowEx anropas innehåller x64 CPU-registret RCX undantaget som genereras. Du kan också klistra in uttrycket i fönstret Omedelbart. syntaxen är densamma som för klockor.

Symbolfilens betydelse

När du publicerar skapar den interna AOT-kompilatorn både en körbar fil och en symbolfil. Intern felsökning och relaterade aktiviteter som profilering kräver åtkomst till den interna symbolfilen. Om den här filen inte finns kan du ha försämrat eller brutit resultat.

Information om symbolfilens namn och plats finns i Intern felsökningsinformation.

CPU-profilering

Plattformsspecifika verktyg som PerfView och Perf kan användas för att samla in CPU-exempel på ett internt AOT-program.

Heapanalys

Hanterad heapanalys stöds för närvarande inte i intern AOT. Analysverktyg för heapanalys som dotnet-gcdump, PerfView och Visual Studio fungerar inte i intern AOT i .NET 8.

Dela via