Felsöka ASP.NET Core i Azure App Service och IIS

Den här artikeln innehåller information om vanliga startfel för appar och instruktioner om hur du diagnostiserar fel när en app distribueras till Azure App Service eller IIS:

Startfel för appar
Förklarar vanliga scenarier för HTTP-statuskod för start.

Felsöka i Azure App Service
Ger felsökningsråd för appar som distribuerats till Azure App Service.

Felsöka på IIS
Ger felsökningsråd för appar som distribueras till IIS eller körs lokalt i IIS Express. Vägledningen gäller för både Windows Server- och Windows-skrivbordsdistributioner.

Rensa paketcacheminnen
Förklarar vad du ska göra när inkonsekventa paket bryter en app när du utför större uppgraderingar eller ändrar paketversioner.

Additional resources
Visar ytterligare felsökningsavsnitt.

Fel vid start av app

I Visual Studio är Kestrelstandardservern för ASP.NET Core-projektet . Visual Studio kan konfigureras för att använda IIS Express. Ett 502.5 – Processfel eller 500.30 – Startfel som inträffar när felsökning lokalt med IIS Express kan diagnostiseras med hjälp av råden i det här avsnittet.

403.14 Forbidden

Det går inte att starta appen. Följande fel loggas:

The Web server is configured to not list the contents of this directory.

Felet orsakas vanligtvis av en trasig distribution på värdsystemet, vilket omfattar något av följande scenarier:

• Appen distribueras till fel mapp i värdsystemet.
• Distributionsprocessen kunde inte flytta alla appens filer och mappar till distributionsmappen i värdsystemet.
• Den web.config filen saknas i distributionen, eller så är web.config filinnehållet felaktigt.

Utför följande steg:

1. Ta bort alla filer och mappar från distributionsmappen i värdsystemet.
2. Distribuera om innehållet i appens publiceringsmapp till värdsystemet med din normala distributionsmetod, till exempel Visual Studio, PowerShell eller manuell distribution:
   • Bekräfta att web.config filen finns i distributionen och att dess innehåll är korrekt.
   • När du är värd för Azure App Service kontrollerar du att appen har distribuerats till D:\home\site\wwwroot mappen.
   • När appen hanteras av IIS kontrollerar du att appen har distribuerats till den fysiska IIS-sökvägen som visas i IIS-hanterarensgrundläggande inställningar.
3. Bekräfta att alla appens filer och mappar distribueras genom att jämföra distributionen i värdsystemet med innehållet i projektets publiceringsmapp .

Mer information om layouten för en publicerad ASP.NET Core-app finns i ASP.NET Core-katalogstruktur. Mer information om filenweb.config finns i ASP.NET Core Module (ANCM) för IIS.

500 Internt fel på servern

Appen startar, men ett fel hindrar servern från att uppfylla begäran.

Det här felet uppstår i appens kod under starten eller när du skapar ett svar. Svaret får inte innehålla något innehåll, eller så kan svaret visas som ett 500 internt serverfel i webbläsaren. Programhändelseloggen anger vanligtvis att appen startade normalt. Från serverns perspektiv stämmer det. Appen startade, men den kan inte generera ett giltigt svar. Kör appen i en kommandotolk på servern eller aktivera stdout-loggen för ASP.NET Core Module för att felsöka problemet.

Det här felet kan också inträffa när .NET-värdpaketet inte är installerat eller är skadat. Om du installerar eller reparerar installationen av .NET Hosting Bundle (för IIS) eller Visual Studio (för IIS Express) kan problemet åtgärdas.

500.0 In-Process hanterarens inläsningsfel

Arbetsprocessen misslyckas. Appen startar inte.

Ett okänt fel uppstod när ASP.NET Core Module-komponenter skulle läsas in. Välj en av följande åtgärder:

• Kontakta Microsoft Support (välj Utvecklarverktyg och sedan ASP.NET Core).
• Ställ en fråga om Stack Overflow.
• Skapa ett problem på vår GitHub-lagringsplats.

500.30 In-Process startfel

Arbetsprocessen misslyckas. Appen startar inte.

ASP.NET Core-modulen försöker starta .NET CLR i processen, men det går inte att starta. Orsaken till ett processstartfel kan vanligtvis fastställas från poster i programhändelseloggen och stdout-loggen för ASP.NET Core-modulen.

Vanliga feltillstånd:

• Appen är felkonfigurerad på grund av att den riktar in sig på en version av det delade ASP.NET Core-ramverket som inte finns. Kontrollera vilka versioner av det delade ASP.NET Core-ramverket som är installerade på måldatorn.
• Med Hjälp av Azure Key Vault saknas behörigheter till Key Vault. Kontrollera åtkomstprinciperna i det riktade Nyckelvalvet för att säkerställa att rätt behörigheter beviljas.

500.31 ANCM kunde inte hitta interna beroenden

Arbetsprocessen misslyckas. Appen startar inte.

ASP.NET Core-modulen försöker starta .NET-körningen i processen, men den startar inte. Den vanligaste orsaken till det här startfelet är när körningen Microsoft.NETCore.App eller Microsoft.AspNetCore.App inte är installerad. Om appen distribueras till målet ASP.NET Core 3.0 och den versionen inte finns på datorn uppstår det här felet. Ett exempel på ett felmeddelande följer:

The specified framework 'Microsoft.NETCore.App', version '3.0.0' was not found.
  - The following frameworks were found:
      2.2.1 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview5-27626-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27713-13 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27714-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27723-08 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]

Felmeddelandet visar alla installerade .NET-versioner och den version som begärs av appen. Åtgärda det här felet genom att antingen:

• Installera lämplig version av .NET på datorn.
• Ändra appen så att den riktar in sig på en version av .NET som finns på datorn.
• Publicera appen som en fristående distribution.

När du kör under utveckling ( ASPNETCORE_ENVIRONMENT miljövariabeln är inställd på Development) skrivs det specifika felet till HTTP-svaret. Orsaken till ett processstartfel finns också i programhändelseloggen.

500.32 ANCM kunde inte läsa in dll

Arbetsprocessen misslyckas. Appen startar inte.

Den vanligaste orsaken till det här felet är att appen publiceras för en inkompatibel processorarkitektur. Om arbetsprocessen körs som en 32-bitarsapp och appen har publicerats som mål för 64-bitars, uppstår det här felet.

Åtgärda det här felet genom att antingen:

• Publicera om appen för samma processorarkitektur som arbetsprocessen.
• Publicera appen som en ramverksberoende distribution.

Inläsningsfel för 500.33 ANCM-begärandehanterare

Arbetsprocessen misslyckas. Appen startar inte.

Appen refererade inte till ramverket Microsoft.AspNetCore.App . Endast appar som är riktade mot ramverket Microsoft.AspNetCore.App kan hanteras av ASP.NET Core-modulen.

Om du vill åtgärda det här felet kontrollerar du att appen riktar in sig på ramverket Microsoft.AspNetCore.App . Kontrollera det .runtimeconfig.json ramverk som appen har som mål.

500.34 ANCM Mixed Hosting Models stöds inte

Arbetsprocessen kan inte köra både en processbaserad app och en out-of-process-app i samma process.

Du kan åtgärda det här felet genom att köra appar i separata IIS-programpooler.

500.35 ANCM Flera In-Process program i samma process

Arbetsprocessen kan inte köra flera pågående appar i samma process.

Du kan åtgärda det här felet genom att köra appar i separata IIS-programpooler.

500.36 ANCM out-Of-Process handler load failure (500.36 ANCM Out-Of-Process Handler Load Failure)

Hanteraren för out-of-process-begäran, aspnetcorev2_outofprocess.dll, är inte bredvid filenaspnetcorev2.dll . Detta indikerar en skadad installation av ASP.NET Core-modulen.

Åtgärda det här felet genom att reparera installationen av .NET Hosting Bundle (för IIS) eller Visual Studio (för IIS Express).

500.37 ANCM kunde inte starta inom starttidsgränsen

ANCM kunde inte starta inom den angivna starttiden. Som standard är tidsgränsen 120 sekunder.

Det här felet kan inträffa när du startar ett stort antal appar på samma dator. Sök efter toppar i cpu-/minnesanvändningen på servern under starten. Du kan behöva ändra startprocessen för flera appar.

500.38 ANCM-program-DLL hittades inte

ANCM kunde inte hitta programmets DLL, som ska vara bredvid den körbara filen.

Det här felet uppstår när du är värd för en app som paketeras som en körbar fil med hjälp av den processbaserade värdmodellen. In-processmodellen kräver att ANCM läser in .NET-appen i den befintliga IIS-processen. Det här scenariot stöds inte av distributionsmodellen med en fil. Använd någon av följande metoder i appens projektfil för att åtgärda det här felet:

1. Inaktivera publicering med en fil genom att ange PublishSingleFile egenskapen MSBuild till false.
2. Växla till den färdiga värdmodellen genom att ange AspNetCoreHostingModel egenskapen MSBuild till OutOfProcess.

502.5 processfel

Arbetsprocessen misslyckas. Appen startar inte.

ASP.NET Core-modulen försöker starta arbetsprocessen, men den startar inte. Orsaken till ett processstartfel kan vanligtvis fastställas från poster i programhändelseloggen och stdout-loggen för ASP.NET Core-modulen.

Ett vanligt feltillstånd är att appen är felkonfigurerad på grund av att den riktar in sig på en version av det delade ASP.NET Core-ramverket som inte finns. Kontrollera vilka versioner av det delade ASP.NET Core-ramverket som är installerade på måldatorn. Det delade ramverket är uppsättningen sammansättningar (.dll filer) som installeras på datorn och refereras av ett metapaket som Microsoft.AspNetCore.App. Metapackage-referensen kan ange en lägsta version som krävs. Mer information finns i Det delade ramverket.

Felsidan för processfel i 502.5 returneras när en värd- eller appfelkonfiguration gör att arbetsprocessen misslyckas:

Det gick inte att starta programmet (ErrorCode "0x800700c1")

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

Det gick inte att starta appen eftersom det inte gick att läsa in appens sammansättning (.dll).

Det här felet uppstår när det finns en bitnessmatchning mellan den publicerade appen och w3wp/iisexpress-processen.

Kontrollera att apppoolens 32-bitarsinställning är korrekt:

1. Välj apppoolen i IIS-hanterarens programpooler.
2. Välj Avancerade inställningar under Redigera programpool på panelen Åtgärder .
3. Ange Aktivera 32-bitarsprogram:
   • Om du distribuerar en 32-bitarsapp (x86) anger du värdet till True.
   • Om du distribuerar en 64-bitarsapp (x64) anger du värdet till False.

Bekräfta att det inte finns någon konflikt mellan en <Platform> MSBuild-egenskap i projektfilen och appens publicerade bitness.

Det gick inte att starta programmet (ErrorCode "0x800701b1")

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/3/ROOT', ErrorCode '0x800701b1'.

Det gick inte att starta appen eftersom en Windows-tjänst inte kunde läsas in.

En vanlig tjänst som måste aktiveras är "null"-tjänsten. Följande kommando aktiverar null Windows-tjänsten:

sc.exe start null

Connection reset

Om ett fel uppstår efter att rubrikerna har skickats är det för sent för servern att skicka ett 500 internt serverfel när ett fel inträffar. Detta inträffar ofta när ett fel inträffar under serialiseringen av komplexa objekt för ett svar. Den här typen av fel visas som ett anslutningsåterställningsfel på klienten. Programloggning kan hjälpa dig att felsöka dessa typer av fel.

Standardbegränsningar för start

ASP.NET Core-modulen konfigureras med en standardstartTimeLimit på 120 sekunder. När den lämnas kvar vid standardvärdet kan det ta upp till två minuter innan modulen loggar ett processfel. Information om hur du konfigurerar modulen finns i Attribut för aspNetCore-elementet.

Felsöka i Azure App Service

Azure App Services-loggström

Azure App Services-loggen strömmar logginformation när den inträffar. Så här visar du strömmande loggar:

1. Öppna appen i App Services i Azure-portalen.
2. I den vänstra rutan går du till Övervaka>App Service-loggar.
3. Välj Filsystem för webbserverloggning. Du kan också aktivera programloggning.
4. I den vänstra rutan går du till Övervakningsloggström> och väljer sedan Programloggar eller Webbserverloggar.

Följande bilder visar utdata från programloggarna:

Strömmande loggar har viss svarstid och kanske inte visas omedelbart.

Programhändelselogg (Azure App Service)

Om du vill komma åt programhändelseloggen använder du bladet Diagnostisera och lösa problem i Azure-portalen:

1. Öppna appen i App Services i Azure-portalen.
2. Välj Diagnostisera och lösa problem.
3. Välj rubriken Diagnostikverktyg .
4. Under Supportverktyg väljer du knappen Programhändelser .
5. Granska det senaste felet från posten IIS AspNetCoreModule eller IIS AspNetCoreModule V2 i kolumnen Källa .

Ett alternativ till att använda bladet Diagnostisera och lösa problem är att undersöka programhändelseloggfilen direkt med Kudu:

1. Öppna Avancerade verktyg i området Utvecklingsverktyg . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
2. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
3. Öppna mappen LogFiles.
4. Välj pennikonen bredvid eventlog.xml filen.
5. Granska loggen. Rulla längst ned i loggen för att se de senaste händelserna.

Kör appen i Kudu-konsolen

Många startfel genererar inte användbar information i programhändelseloggen. Du kan köra appen i Kudu-fjärrkörningskonsolen för att upptäcka felet:

1. Öppna Avancerade verktyg i området Utvecklingsverktyg . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
2. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.

Testa en 32-bitars app (x86)

Current release

1. cd d:\home\site\wwwroot
2. Kör appen:

   • Om appen är en ramverksberoende distribution:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Om appen är en fristående distribution:

     {ASSEMBLY NAME}.exe
     

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

Ramverksberoende distribution som körs på en förhandsversion

Kräver installation av ASP.NET Core {VERSION} (x86) Runtime-webbplatstillägget.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} är körningsversionen)
2. Kör appen: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

Testa en 64-bitars app (x64)

Current release

• Om appen är en 64-bitars (x64) ramverksberoende distribution:
  1. cd D:\Program Files\dotnet
  2. Kör appen: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Om appen är en fristående distribution:
  1. cd D:\home\site\wwwroot
  2. Kör appen: {ASSEMBLY NAME}.exe

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

Ramverksberoende distribution som körs på en förhandsversion

Kräver installation av webbplatstillägget ASP.NET Core {VERSION} (x64).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} är körningsversionen)
2. Kör appen: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

ASP.NET Core Module stdout-logg (Azure App Service)

Den ASP.NET Core Module stdout-loggen registrerar ofta användbara felmeddelanden som inte hittades i programhändelseloggen. Så här aktiverar och visar du stdout-loggar:

1. Gå till webbappen i Azure-portalen.
2. På bladet App Service anger du kudu i sökrutan.
3. Välj Avancerade verktyg>Gå.
4. Välj Felsök konsolens > CMD.
5. Navigera till webbplats/wwwroot
6. Välj pennikonen för att redigera filenweb.config .
7. I elementet <aspNetCore /> anger stdoutLogEnabled="true" du och väljer Spara.

Inaktivera stdout-loggning när felsökningen är klar genom att ange stdoutLogEnabled="false".

Mer information finns i ASP.NET Core Module (ANCM) för IIS.

felsökningslogg för ASP.NET Core Module (Azure App Service)

Felsökningsloggen ASP.NET Core Module ger ytterligare, djupare loggning från ASP.NET Core-modulen. Så här aktiverar och visar du stdout-loggar:

1. Om du vill aktivera den förbättrade diagnostikloggen utför du något av följande:
   • Följ anvisningarna i Utökade diagnostikloggar för att konfigurera appen för en förbättrad diagnostikloggning. Omdistribuera appen.
   • Lägg till det <handlerSettings> som visas i Utökade diagnostikloggar i liveappens web.config-fil med hjälp av Kudu-konsolen:
     1. Öppna Avancerade verktyg i området Utvecklingsverktyg . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
     2. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
     3. Öppna mapparna till sökvägswebbplatsen>wwwroot. Redigera filenweb.config genom att välja pennknappen. Lägg till avsnittet enligt beskrivningen <handlerSettings> i Utökade diagnostikloggar. Välj Spara-knappen.
2. Öppna Avancerade verktyg i området Utvecklingsverktyg . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
3. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
4. Öppna mapparna till sökvägswebbplatsen>wwwroot. Om du inte angav någon sökväg för aspnetcore-debug.log-filen visas filen i listan. Om du angav en sökväg navigerar du till loggfilens plats.
5. Öppna loggfilen med pennknappen bredvid filnamnet.

Inaktivera felsökningsloggning när felsökningen är klar:

Om du vill inaktivera den förbättrade felsökningsloggen utför du något av följande:

• <handlerSettings> Ta bort filen från web.config lokalt och distribuera om appen.
• Använd Kudu-konsolen för att redigera web.config-filen och ta bort <handlerSettings> avsnittet. Spara filen.

Mer information finns i Skapa och omdirigera loggar med ASP.NET Core-modulen.

Långsam eller icke-svarar-app (Azure App Service)

När en app svarar långsamt eller inte svarar på en begäran kan du läsa Felsöka långsamma prestandaproblem för webbappar i Azure App Service.

Monitoring blades

Övervakningsblad ger en alternativ felsökningsupplevelse till de metoder som beskrevs tidigare i ämnet. Dessa blad kan användas för att diagnostisera fel i 500-serien.

Bekräfta att ASP.NET Core Extensions är installerade. Om tilläggen inte är installerade installerar du dem manuellt:

1. I bladet UTVECKLINGSVERKTYG väljer du bladet Tillägg .
2. ASP.NET Core Extensions bör visas i listan.
3. Om tilläggen inte är installerade väljer du knappen Lägg till .
4. Välj ASP.NET Core Extensions i listan.
5. Välj OK för att acceptera de juridiska villkoren.
6. Välj OK på bladet Lägg till tillägg .
7. Ett informationsmeddelande anger när tilläggen har installerats.

Om stdout-loggning inte är aktiverat följer du dessa steg:

1. I Azure-portalen väljer du bladet Avancerade verktyg i området UTVECKLINGSVERKTYG . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
2. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
3. Öppna mapparna till sökvägswebbplatsen>wwwroot och rulla nedåt för att visa web.config filen längst ned i listan.
4. Klicka på pennikonen bredvid filenweb.config .
5. Ange stdoutLogEnabled till true och ändra stdoutLogFile-sökvägen till: \\?\%home%\LogFiles\stdout.
6. Välj Spara för att spara den uppdaterade web.config filen.

Fortsätt med att aktivera diagnostikloggning:

1. I Azure-portalen väljer du bladet Diagnostikloggar .
2. Välj växeln På för Programloggning (Filsystem) och Detaljerade felmeddelanden. Välj knappen Spara överst på bladet.
3. Om du vill inkludera spårning av misslyckade begäranden, även kallat LOGGning av händelsebuffertning för misslyckade begäranden (FREB), väljer du växeln På för Spårning av misslyckade begäranden.
4. Välj bladet Loggström , som visas direkt under bladet Diagnostikloggar i portalen.
5. Skicka en begäran till appen.
6. I loggströmsdata anges orsaken till felet.

Se till att inaktivera stdout-loggning när felsökningen är klar.

Så här visar du spårningsloggarna för misslyckade förfrågningar (FREB-loggar):

1. Gå till bladet Diagnostisera och lösa problem i Azure-portalen.
2. Välj Spårningsloggar för misslyckade begäranden från området SUPPORTVERKTYG i sidofältet.

Se avsnittet Spårning av misslyckade begäranden i avsnittet Aktivera diagnostikloggning för webbappar i Azure App Service och vanliga frågor och svar om programprestanda för Web Apps i Azure: Hur aktiverar jag spårning av misslyckade förfrågningar? för mer information.

Mer information finns i Aktivera diagnostikloggning för webbappar i Azure App Service.

Felsöka på IIS

Programhändelselogg (IIS)

Öppna programhändelseloggen:

1. Öppna Start-menyn, sök efter Händelseloggoch välj appen Händelselogg.
2. I Loggbokenöppnar du noden Windows-loggar.
3. Välj program för att öppna programhändelseloggen.
4. Sök efter fel som är associerade med den misslyckade appen. Fel har värdet IIS AspNetCore-modul ellerIIS Express AspNetCore-modul i kolumnen Källa .

Kör appen i en kommandotolk

Många startfel genererar inte användbar information i programhändelseloggen. Du kan hitta orsaken till vissa fel genom att köra appen i en kommandotolk på värdsystemet.

Framework-dependent deployment

Om appen är en ramverksberoende distribution:

1. I en kommandotolk navigerar du till distributionsmappen och kör appen genom att köra appens sammansättning med dotnet.exe. I följande kommando ersätter du namnet på appens sammansättning med <assembly_name>: dotnet .\<assembly_name>.dll.
2. Konsolens utdata från appen, som visar eventuella fel, skrivs till konsolfönstret.
3. Om felen uppstår när du skickar en begäran till appen skickar du en begäran till värden och porten där Kestrel lyssnar. Använd standardvärden och skicka en begäran till http://localhost:5000/. Om appen svarar normalt på slutpunktsadressen Kestrel är problemet mer sannolikt relaterat till värdkonfigurationen och mindre troligt i appen.

Self-contained deployment

Om appen är en fristående distribution:

1. I en kommandotolk navigerar du till distributionsmappen och kör appens körbara fil. I följande kommando ersätter du namnet på appens sammansättning med <assembly_name>: <assembly_name>.exe.
2. Konsolens utdata från appen, som visar eventuella fel, skrivs till konsolfönstret.
3. Om felen uppstår när du skickar en begäran till appen skickar du en begäran till värden och porten där Kestrel lyssnar. Använd standardvärden och skicka en begäran till http://localhost:5000/. Om appen svarar normalt på slutpunktsadressen Kestrel är problemet mer sannolikt relaterat till värdkonfigurationen och mindre troligt i appen.

ASP.NET Core Module stdout log (IIS)

Så här aktiverar och visar du stdout-loggar:

1. Gå till platsens distributionsmapp i värdsystemet.
2. Om loggmappen inte finns skapar du mappen. Anvisningar om hur du aktiverar MSBuild för att skapa loggmappen i distributionen automatiskt finns i avsnittet Katalogstruktur .
3. Redigera filen web.config. Ange stdoutLogEnabled till true och ändra sökvägen stdoutLogFile så att den pekar på loggmappen (till exempel .\logs\stdout). stdout i sökvägen finns prefixet för loggfilens namn. En tidsstämpel, process-ID och filnamnstillägg läggs till automatiskt när loggen skapas. Med hjälp av stdout filnamnsprefixet heter en typisk loggfil stdout_20180205184032_5412.log.
4. Kontrollera att programpoolens identitet har skrivbehörighet till loggmappen.
5. Spara den uppdaterade filen web.config .
6. Skicka en begäran till appen.
7. Gå till loggmappen. Hitta och öppna den senaste stdout-loggen.
8. Studera loggen efter fel.

Inaktivera stdout-loggning när felsökningen är klar:

1. Redigera filen web.config.
2. Ange stdoutLogEnabled till false.
3. Spara filen.

Mer information finns i ASP.NET Core Module (ANCM) för IIS.

felsökningslogg för ASP.NET Core Module (IIS)

Lägg till följande hanteringsinställningar i appens web.config-fil för att aktivera felsökningsloggen för ASP.NET Core Module:

<aspNetCore ...>
  <handlerSettings>
    <handlerSetting name="debugLevel" value="file" />
    <handlerSetting name="debugFile" value="c:\temp\ancm.log" />
  </handlerSettings>
</aspNetCore>

Bekräfta att sökvägen som angetts för loggen finns och att apppoolens identitet har skrivbehörighet till platsen.

Mer information finns i Skapa och omdirigera loggar med ASP.NET Core-modulen.

Aktivera undantagssidan för utvecklare

Miljövariabeln ASPNETCORE_ENVIRONMENTkan läggas till i web.config för att köra appen i utvecklingsmiljön. Så länge miljön inte åsidosätts i appstarten av på värdverktyget, tillåter inställningen av UseEnvironment miljövariabeln att undantagssidan för utvecklare visas när appen körs.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout"
      hostingModel="InProcess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  </environmentVariables>
</aspNetCore>

Att ange miljövariabeln för ASPNETCORE_ENVIRONMENT rekommenderas endast för användning på mellanlagrings- och testservrar som inte exponeras för Internet. Ta bort miljövariabeln från filen web.config efter felsökning. Information om hur du anger miljövariabler i web.configfinns i environmentVariables underordnade element i aspNetCore.

Hämta data från en app

Om en app kan svara på begäranden hämtar du begäran, anslutning och ytterligare data från appen med hjälp av terminalens infogade mellanprogram. Mer information och exempelkod finns i Felsöka och felsöka ASP.NET Core-projekt.

Långsam eller icke-svarande app (IIS)

En kraschdump är en ögonblicksbild av systemets minne och kan hjälpa dig att fastställa orsaken till en appkrasch, ett startfel eller en långsam app.

Appen kraschar eller stöter på ett undantag

Hämta och analysera en dump från Windows Error Reporting (WER):

1. Skapa en mapp för att lagra kraschdumpfiler på c:\dumps. Apppoolen måste ha skrivbehörighet till mappen.

2. Kör PowerShell-skriptet EnableDumps:

   • Om appen använder den processbaserade värdmodellen kör du skriptet för w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • Om appen använder en out-of-process-värdmodell kör du skriptet för dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Kör appen under de förhållanden som orsakar kraschen.

4. När kraschen har inträffat kör du DisableDumps PowerShell-skriptet:

   • Om appen använder den processbaserade värdmodellen kör du skriptet för w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • Om appen använder en out-of-process-värdmodell kör du skriptet för dotnet.exe:

     .\DisableDumps dotnet.exe
     

När en app kraschar och dumpsamlingen har slutförts kan appen avslutas normalt. PowerShell-skriptet konfigurerar WER för att samla in upp till fem dumpar per app.

Appen svarar inte, misslyckas vid start eller körs normalt

När en app slutar svara men inte kraschar, misslyckas vid start eller körs normalt kan du läsa User-Mode Dump Files: Välja det bästa verktyget för att välja ett lämpligt verktyg för att skapa dumpen.

Analysera datadumpen

En dump kan analyseras med flera metoder. Mer information finns i Analysera en User-Mode dumpfil.

Rensa paketcache

En fungerande app kan misslyckas omedelbart efter att ha uppgraderat .NET SDK på utvecklingsdatorn eller ändrat paketversioner i appen. I vissa fall kan osammanhängande paket skada en app vid genomförande av större uppgraderingar. De flesta av dessa problem kan åtgärdas genom att följa dessa instruktioner:

1. Ta bort bin och obj mappar.

2. Rensa paketcacheminnena genom att köra dotnet nuget locals all --clear från ett kommandogränssnitt.

   Du kan också rensa paketcacheminnen med verktyget nuget.exe och köra kommandot nuget locals all -clear. nuget.exe är inte en paketerad installation med Windows-skrivbordsoperativsystemet och måste hämtas separat från NuGet-webbplatsen.

3. Återställa och återskapa projektet.

4. Ta bort alla filer i distributionsmappen på servern innan du distribuerar om appen.

Additional resources

• Felsöka .NET- och ASP.NET Core-källkod med Visual Studio
• Felsök och avbugga ASP.NET Core-projekt
• Vanliga fel vid felsökning för Azure App Service och IIS med ASP.NET Core
• Hantera fel i ASP.NET Core
• ASP.NET Core Module (ANCM) för IIS

Azure documentation

• Application Insights för ASP.NET Core
• Avsnittet Fjärrfelsökning av webbappar i Felsöka en webbapp i Azure App Service med hjälp av Visual Studio
• Översikt över Azure App Service-diagnostik
• Anvisningar: Övervaka appar i Azure App Service
• Felsöka en webbapp i Azure App Service med Visual Studio
• Felsöka HTTP-fel med "502 felaktig gateway" och "503-tjänsten är inte tillgänglig" i dina Azure-webbappar
• Felsöka problem med prestanda och långsamma webbappar i Azure App Service
• Vanliga frågor och svar om programprestanda för Web Apps i Azure
• Sandbox-miljö för Azure Web App (körningsbegränsningar för App Service)

Dokumentation om Visual Studio

• Fjärrfelsöka ASP.NET Core på IIS i Azure i Visual Studio 2017
• Fjärrfelsöka ASP.NET Core på en fjärr-IIS-dator i Visual Studio 2017
• Lär dig att felsöka med Visual Studio

Visual Studio Code-dokumentation

• Felsökning med Visual Studio Code

Den här artikeln innehåller information om vanliga startfel för appar och instruktioner om hur du diagnostiserar fel när en app distribueras till Azure App Service eller IIS:

Startfel för appar
Förklarar vanliga scenarier för HTTP-statuskod för start.

Felsöka i Azure App Service
Ger felsökningsråd för appar som distribuerats till Azure App Service.

Felsöka på IIS
Ger felsökningsråd för appar som distribueras till IIS eller körs lokalt i IIS Express. Vägledningen gäller för både Windows Server- och Windows-skrivbordsdistributioner.

Rensa paketcacheminnen
Förklarar vad du ska göra när inkonsekventa paket bryter en app när du utför större uppgraderingar eller ändrar paketversioner.

Additional resources
Visar ytterligare felsökningsavsnitt.

Fel vid start av app

I Visual Studio är ett ASP.NET Core-projekt som standard IIS Express-värd under felsökning. 502.5 – Processfel eller 500.30 – Startfel som inträffar när felsökning lokalt kan diagnostiseras med hjälp av råden i det här avsnittet.

403.14 Forbidden

Det går inte att starta appen. Följande fel loggas:

The Web server is configured to not list the contents of this directory.

Felet orsakas vanligtvis av en trasig distribution på värdsystemet, vilket omfattar något av följande scenarier:

• Appen distribueras till fel mapp i värdsystemet.
• Distributionsprocessen kunde inte flytta alla appens filer och mappar till distributionsmappen i värdsystemet.
• Den web.config filen saknas i distributionen, eller så är web.config filinnehållet felaktigt.

Utför följande steg:

1. Ta bort alla filer och mappar från distributionsmappen i värdsystemet.
2. Distribuera om innehållet i appens publiceringsmapp till värdsystemet med din normala distributionsmetod, till exempel Visual Studio, PowerShell eller manuell distribution:
   • Bekräfta att web.config filen finns i distributionen och att dess innehåll är korrekt.
   • När du är värd för Azure App Service kontrollerar du att appen har distribuerats till D:\home\site\wwwroot mappen.
   • När appen hanteras av IIS kontrollerar du att appen har distribuerats till den fysiska IIS-sökvägen som visas i IIS-hanterarensgrundläggande inställningar.
3. Bekräfta att alla appens filer och mappar distribueras genom att jämföra distributionen i värdsystemet med innehållet i projektets publiceringsmapp .

Mer information om layouten för en publicerad ASP.NET Core-app finns i ASP.NET Core-katalogstruktur. Mer information om filenweb.config finns i ASP.NET Core Module (ANCM) för IIS.

500 Internt fel på servern

Appen startar, men ett fel hindrar servern från att uppfylla begäran.

Det här felet uppstår i appens kod under starten eller när du skapar ett svar. Svaret får inte innehålla något innehåll, eller så kan svaret visas som ett 500 internt serverfel i webbläsaren. Programhändelseloggen anger vanligtvis att appen startade normalt. Från serverns perspektiv stämmer det. Appen startade, men den kan inte generera ett giltigt svar. Kör appen i en kommandotolk på servern eller aktivera stdout-loggen för ASP.NET Core Module för att felsöka problemet.

Det här felet kan också inträffa när .NET Core-värdpaketet inte är installerat eller är skadat. Du kan lösa problemet genom att installera eller reparera installationen av .NET Core Hosting Bundle (för IIS) eller Visual Studio (för IIS Express).

500.0 In-Process hanterarens inläsningsfel

Arbetsprocessen misslyckas. Appen startar inte.

ASP.NET Core-modulen hittar inte .NET Core CLR och hittar hanteraren för pågående begäranden (aspnetcorev2_inprocess.dll). Check that:

• Appen riktar sig antingen till NuGet-paketet Microsoft.AspNetCore.Server.IIS eller Microsoft.AspNetCore.App metapackage.
• Den version av det delade ASP.NET Core-ramverket som appen riktar in sig på är installerad på måldatorn.

500.0 Out-Of-Process handler load failure (500.0 Out-Of-Process Handler Load Failure)

Arbetsprocessen misslyckas. Appen startar inte.

ASP.NET Core-modulen kan inte hitta den out-of-process som hanterar värdbegäran. Kontrollera att aspnetcorev2_outofprocess.dll finns i en undermapp bredvid aspnetcorev2.dll.

502.5 processfel

Arbetsprocessen misslyckas. Appen startar inte.

ASP.NET Core-modulen försöker starta arbetsprocessen, men den startar inte. Orsaken till ett processstartfel kan vanligtvis fastställas från poster i programhändelseloggen och stdout-loggen för ASP.NET Core-modulen.

Ett vanligt feltillstånd är att appen är felkonfigurerad på grund av att den riktar in sig på en version av det delade ASP.NET Core-ramverket som inte finns. Kontrollera vilka versioner av det delade ASP.NET Core-ramverket som är installerade på måldatorn. Det delade ramverket är uppsättningen sammansättningar (.dll filer) som installeras på datorn och refereras av ett metapaket som Microsoft.AspNetCore.App. Metapackage-referensen kan ange en lägsta version som krävs. Mer information finns i Det delade ramverket.

Felsidan för processfel i 502.5 returneras när en värd- eller appfelkonfiguration gör att arbetsprocessen misslyckas:

Det gick inte att starta programmet (ErrorCode "0x800700c1")

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

Det gick inte att starta appen eftersom det inte gick att läsa in appens sammansättning (.dll).

Det här felet uppstår när det finns en bitnessmatchning mellan den publicerade appen och w3wp/iisexpress-processen.

Kontrollera att apppoolens 32-bitarsinställning är korrekt:

1. Välj apppoolen i IIS-hanterarens programpooler.
2. Välj Avancerade inställningar under Redigera programpool på panelen Åtgärder .
3. Ange Aktivera 32-bitarsprogram:
   • Om du distribuerar en 32-bitarsapp (x86) anger du värdet till True.
   • Om du distribuerar en 64-bitarsapp (x64) anger du värdet till False.

Bekräfta att det inte finns någon konflikt mellan en <Platform> MSBuild-egenskap i projektfilen och appens publicerade bitness.

Connection reset

Om ett fel uppstår efter att rubrikerna har skickats är det för sent för servern att skicka ett 500 internt serverfel när ett fel inträffar. Detta inträffar ofta när ett fel inträffar under serialiseringen av komplexa objekt för ett svar. Den här typen av fel visas som ett anslutningsåterställningsfel på klienten. Programloggning kan hjälpa dig att felsöka dessa typer av fel.

Standardbegränsningar för start

ASP.NET Core-modulen konfigureras med en standardstartTimeLimit på 120 sekunder. När den lämnas kvar vid standardvärdet kan det ta upp till två minuter innan modulen loggar ett processfel. Information om hur du konfigurerar modulen finns i Attribut för aspNetCore-elementet.

Felsöka i Azure App Service

Programhändelselogg (Azure App Service)

Om du vill komma åt programhändelseloggen använder du bladet Diagnostisera och lösa problem i Azure-portalen:

1. Öppna appen i App Services i Azure-portalen.
2. Välj Diagnostisera och lösa problem.
3. Välj rubriken Diagnostikverktyg .
4. Under Supportverktyg väljer du knappen Programhändelser .
5. Granska det senaste felet från posten IIS AspNetCoreModule eller IIS AspNetCoreModule V2 i kolumnen Källa .

Ett alternativ till att använda bladet Diagnostisera och lösa problem är att undersöka programhändelseloggfilen direkt med Kudu:

1. Öppna Avancerade verktyg i området Utvecklingsverktyg . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
2. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
3. Öppna mappen LogFiles.
4. Välj pennikonen bredvid eventlog.xml filen.
5. Granska loggen. Rulla längst ned i loggen för att se de senaste händelserna.

Kör appen i Kudu-konsolen

Många startfel genererar inte användbar information i programhändelseloggen. Du kan köra appen i Kudu-fjärrkörningskonsolen för att upptäcka felet:

1. Öppna Avancerade verktyg i området Utvecklingsverktyg . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
2. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.

Testa en 32-bitars app (x86)

Current release

1. cd d:\home\site\wwwroot
2. Kör appen:

   • Om appen är en ramverksberoende distribution:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Om appen är en fristående distribution:

     {ASSEMBLY NAME}.exe
     

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

Ramverksberoende distribution som körs på en förhandsversion

Kräver installation av ASP.NET Core {VERSION} (x86) Runtime-webbplatstillägget.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} är körningsversionen)
2. Kör appen: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

Testa en 64-bitars app (x64)

Current release

• Om appen är en 64-bitars (x64) ramverksberoende distribution:
  1. cd D:\Program Files\dotnet
  2. Kör appen: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Om appen är en fristående distribution:
  1. cd D:\home\site\wwwroot
  2. Kör appen: {ASSEMBLY NAME}.exe

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

Ramverksberoende distribution som körs på en förhandsversion

Kräver installation av webbplatstillägget ASP.NET Core {VERSION} (x64).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} är körningsversionen)
2. Kör appen: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

ASP.NET Core Module stdout-logg (Azure App Service)

Den ASP.NET Core Module stdout-loggen registrerar ofta användbara felmeddelanden som inte hittades i programhändelseloggen. Så här aktiverar och visar du stdout-loggar:

1. Gå till bladet Diagnostisera och lösa problem i Azure-portalen.
2. Under VÄLJ PROBLEMKATEGORI väljer du knappen Webbapp nedåt .
3. Under Föreslagna lösningar>Aktivera omdirigering av Stdout-logg väljer du knappen för att öppna Kudu-konsolen för att redigera Web.Config.
4. I Kudu-diagnostikkonsolen öppnar du mapparna till sökvägswebbplatsen>wwwroot. Rulla nedåt för att visa filenweb.config längst ned i listan.
5. Klicka på pennikonen bredvid filenweb.config .
6. Ange stdoutLogEnabled till true och ändra stdoutLogFile-sökvägen till: \\?\%home%\LogFiles\stdout.
7. Välj Spara för att spara den uppdaterade web.config filen.
8. Skicka en begäran till appen.
9. Gå tillbaka till Azure-portalen. Välj bladet Avancerade verktyg i området UTVECKLINGSVERKTYG . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
10. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
11. Välj mappen LogFiles .
12. Granska kolumnen Ändrad och välj pennikonen för att redigera stdout-loggen med det senaste ändringsdatumet.
13. När loggfilen öppnas visas felet.

Inaktivera stdout-loggning när felsökningen är klar:

1. I Kudu-diagnostikkonsolen går du tillbaka till sökvägswebbplatsen>wwwroot för att visa filenweb.config . Öppna filenweb.config igen genom att välja pennikonen.
2. Ange stdoutLogEnabled till false.
3. Spara filen genom att välja Spara .

Mer information finns i ASP.NET Core Module (ANCM) för IIS.

felsökningslogg för ASP.NET Core Module (Azure App Service)

Felsökningsloggen ASP.NET Core Module ger ytterligare, djupare loggning från ASP.NET Core-modulen. Så här aktiverar och visar du stdout-loggar:

1. Om du vill aktivera den förbättrade diagnostikloggen utför du något av följande:
   • Följ anvisningarna i Utökade diagnostikloggar för att konfigurera appen för en förbättrad diagnostikloggning. Omdistribuera appen.
   • Lägg till det <handlerSettings> som visas i Utökade diagnostikloggar i liveappens web.config-fil med hjälp av Kudu-konsolen:
     1. Öppna Avancerade verktyg i området Utvecklingsverktyg . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
     2. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
     3. Öppna mapparna till sökvägswebbplatsen>wwwroot. Redigera filenweb.config genom att välja pennknappen. Lägg till avsnittet enligt beskrivningen <handlerSettings> i Utökade diagnostikloggar. Välj Spara-knappen.
2. Öppna Avancerade verktyg i området Utvecklingsverktyg . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
3. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
4. Öppna mapparna till sökvägswebbplatsen>wwwroot. Om du inte angav någon sökväg för aspnetcore-debug.log-filen visas filen i listan. Om du angav en sökväg navigerar du till loggfilens plats.
5. Öppna loggfilen med pennknappen bredvid filnamnet.

Inaktivera felsökningsloggning när felsökningen är klar:

Om du vill inaktivera den förbättrade felsökningsloggen utför du något av följande:

• <handlerSettings> Ta bort filen från web.config lokalt och distribuera om appen.
• Använd Kudu-konsolen för att redigera web.config-filen och ta bort <handlerSettings> avsnittet. Spara filen.

Mer information finns i Skapa och omdirigera loggar med ASP.NET Core-modulen.

Långsam eller icke-svarande app (Azure App Service)

När en app svarar långsamt eller inte svarar på en begäran kan du läsa följande artiklar:

• Felsöka problem med prestanda och långsamma webbappar i Azure App Service
• Använda Crash Diagnoser Site Extension för att avbilda dumpar för tillfälliga undantagsproblem eller prestandaproblem i Azure Web App

Monitoring blades

Övervakningsblad ger en alternativ felsökningsupplevelse till de metoder som beskrevs tidigare i ämnet. Dessa blad kan användas för att diagnostisera fel i 500-serien.

Bekräfta att ASP.NET Core Extensions är installerade. Om tilläggen inte är installerade installerar du dem manuellt:

1. I bladet UTVECKLINGSVERKTYG väljer du bladet Tillägg .
2. ASP.NET Core Extensions bör visas i listan.
3. Om tilläggen inte är installerade väljer du knappen Lägg till .
4. Välj ASP.NET Core Extensions i listan.
5. Välj OK för att acceptera de juridiska villkoren.
6. Välj OK på bladet Lägg till tillägg .
7. Ett informationsmeddelande anger när tilläggen har installerats.

Om stdout-loggning inte är aktiverat följer du dessa steg:

1. I Azure-portalen väljer du bladet Avancerade verktyg i området UTVECKLINGSVERKTYG . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
2. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
3. Öppna mapparna till sökvägswebbplatsen>wwwroot och rulla nedåt för att visa web.config filen längst ned i listan.
4. Klicka på pennikonen bredvid filenweb.config .
5. Ange stdoutLogEnabled till true och ändra stdoutLogFile-sökvägen till: \\?\%home%\LogFiles\stdout.
6. Välj Spara för att spara den uppdaterade web.config filen.

Fortsätt med att aktivera diagnostikloggning:

1. I Azure-portalen väljer du bladet Diagnostikloggar .
2. Välj växeln På för Programloggning (Filsystem) och Detaljerade felmeddelanden. Välj knappen Spara överst på bladet.
3. Om du vill inkludera spårning av misslyckade begäranden, även kallat LOGGning av händelsebuffertning för misslyckade begäranden (FREB), väljer du växeln På för Spårning av misslyckade begäranden.
4. Välj bladet Loggström , som visas direkt under bladet Diagnostikloggar i portalen.
5. Skicka en begäran till appen.
6. I loggströmsdata anges orsaken till felet.

Se till att inaktivera stdout-loggning när felsökningen är klar.

Så här visar du spårningsloggarna för misslyckade förfrågningar (FREB-loggar):

1. Gå till bladet Diagnostisera och lösa problem i Azure-portalen.
2. Välj Spårningsloggar för misslyckade begäranden från området SUPPORTVERKTYG i sidofältet.

Se avsnittet Spårning av misslyckade begäranden i avsnittet Aktivera diagnostikloggning för webbappar i Azure App Service och vanliga frågor och svar om programprestanda för Web Apps i Azure: Hur aktiverar jag spårning av misslyckade förfrågningar? för mer information.

Mer information finns i Aktivera diagnostikloggning för webbappar i Azure App Service.

Felsöka på IIS

Programhändelselogg (IIS)

Öppna programhändelseloggen:

1. Öppna Start-menyn, sök efter Händelseloggoch välj appen Händelselogg.
2. I Loggbokenöppnar du noden Windows-loggar.
3. Välj program för att öppna programhändelseloggen.
4. Sök efter fel som är associerade med den misslyckade appen. Fel har värdet IIS AspNetCore-modul ellerIIS Express AspNetCore-modul i kolumnen Källa .

Kör appen i en kommandotolk

Många startfel genererar inte användbar information i programhändelseloggen. Du kan hitta orsaken till vissa fel genom att köra appen i en kommandotolk på värdsystemet.

Framework-dependent deployment

Om appen är en ramverksberoende distribution:

1. I en kommandotolk navigerar du till distributionsmappen och kör appen genom att köra appens sammansättning med dotnet.exe. I följande kommando ersätter du namnet på appens sammansättning med <assembly_name>: dotnet .\<assembly_name>.dll.
2. Konsolens utdata från appen, som visar eventuella fel, skrivs till konsolfönstret.
3. Om felen uppstår när du skickar en begäran till appen skickar du en begäran till värden och porten där Kestrel lyssnar. Använd standardvärden och skicka en begäran till http://localhost:5000/. Om appen svarar normalt på slutpunktsadressen Kestrel är problemet mer sannolikt relaterat till värdkonfigurationen och mindre troligt i appen.

Self-contained deployment

Om appen är en fristående distribution:

1. I en kommandotolk navigerar du till distributionsmappen och kör appens körbara fil. I följande kommando ersätter du namnet på appens sammansättning med <assembly_name>: <assembly_name>.exe.
2. Konsolens utdata från appen, som visar eventuella fel, skrivs till konsolfönstret.
3. Om felen uppstår när du skickar en begäran till appen skickar du en begäran till värden och porten där Kestrel lyssnar. Använd standardvärden och skicka en begäran till http://localhost:5000/. Om appen svarar normalt på slutpunktsadressen Kestrel är problemet mer sannolikt relaterat till värdkonfigurationen och mindre troligt i appen.

ASP.NET Core Module stdout log (IIS)

Så här aktiverar och visar du stdout-loggar:

1. Gå till platsens distributionsmapp i värdsystemet.
2. Om loggmappen inte finns skapar du mappen. Anvisningar om hur du aktiverar MSBuild för att skapa loggmappen i distributionen automatiskt finns i avsnittet Katalogstruktur .
3. Redigera filen web.config. Ange stdoutLogEnabled till true och ändra sökvägen stdoutLogFile så att den pekar på loggmappen (till exempel .\logs\stdout). stdout i sökvägen finns prefixet för loggfilens namn. En tidsstämpel, process-ID och filnamnstillägg läggs till automatiskt när loggen skapas. Med hjälp av stdout filnamnsprefixet heter en typisk loggfil stdout_20180205184032_5412.log.
4. Kontrollera att programpoolens identitet har skrivbehörighet till loggmappen.
5. Spara den uppdaterade filen web.config .
6. Skicka en begäran till appen.
7. Gå till loggmappen. Hitta och öppna den senaste stdout-loggen.
8. Studera loggen efter fel.

Inaktivera stdout-loggning när felsökningen är klar:

1. Redigera filen web.config.
2. Ange stdoutLogEnabled till false.
3. Spara filen.

Mer information finns i ASP.NET Core Module (ANCM) för IIS.

felsökningslogg för ASP.NET Core Module (IIS)

Lägg till följande hanteringsinställningar i appens web.config-fil för att aktivera felsökningsloggen för ASP.NET Core Module:

<aspNetCore ...>
  <handlerSettings>
    <handlerSetting name="debugLevel" value="file" />
    <handlerSetting name="debugFile" value="c:\temp\ancm.log" />
  </handlerSettings>
</aspNetCore>

Bekräfta att sökvägen som angetts för loggen finns och att apppoolens identitet har skrivbehörighet till platsen.

Mer information finns i Skapa och omdirigera loggar med ASP.NET Core-modulen.

Aktivera undantagssidan för utvecklare

Miljövariabeln ASPNETCORE_ENVIRONMENTkan läggas till i web.config för att köra appen i utvecklingsmiljön. Så länge miljön inte åsidosätts i appstarten av på värdverktyget, tillåter inställningen av UseEnvironment miljövariabeln att undantagssidan för utvecklare visas när appen körs.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout"
      hostingModel="InProcess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  </environmentVariables>
</aspNetCore>

Att ange miljövariabeln för ASPNETCORE_ENVIRONMENT rekommenderas endast för användning på mellanlagrings- och testservrar som inte exponeras för Internet. Ta bort miljövariabeln från filen web.config efter felsökning. Information om hur du anger miljövariabler i web.configfinns i environmentVariables underordnade element i aspNetCore.

Hämta data från en app

Om en app kan svara på begäranden hämtar du begäran, anslutning och ytterligare data från appen med hjälp av terminalens infogade mellanprogram. Mer information och exempelkod finns i Felsöka och felsöka ASP.NET Core-projekt.

Långsam eller icke-svarande app (IIS)

En kraschdump är en ögonblicksbild av systemets minne och kan hjälpa dig att fastställa orsaken till en appkrasch, ett startfel eller en långsam app.

Appen kraschar eller stöter på ett undantag

Hämta och analysera en dump från Windows Error Reporting (WER):

1. Skapa en mapp för att lagra kraschdumpfiler på c:\dumps. Apppoolen måste ha skrivbehörighet till mappen.

2. Kör PowerShell-skriptet EnableDumps:

   • Om appen använder den processbaserade värdmodellen kör du skriptet för w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • Om appen använder en out-of-process-värdmodell kör du skriptet för dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Kör appen under de förhållanden som orsakar kraschen.

4. När kraschen har inträffat kör du DisableDumps PowerShell-skriptet:

   • Om appen använder den processbaserade värdmodellen kör du skriptet för w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • Om appen använder en out-of-process-värdmodell kör du skriptet för dotnet.exe:

     .\DisableDumps dotnet.exe
     

När en app kraschar och dumpsamlingen har slutförts kan appen avslutas normalt. PowerShell-skriptet konfigurerar WER för att samla in upp till fem dumpar per app.

Appen svarar inte, misslyckas vid start eller körs normalt

När en app slutar svara men inte kraschar, misslyckas vid start eller körs normalt kan du läsa User-Mode Dump Files: Välja det bästa verktyget för att välja ett lämpligt verktyg för att skapa dumpen.

Analysera datadumpen

En dump kan analyseras med flera metoder. Mer information finns i Analysera en User-Mode dumpfil.

Rensa paketcache

En fungerande app kan misslyckas omedelbart efter att ha uppgraderat .NET Core SDK på utvecklingsdatorn eller ändrat paketversioner i appen. I vissa fall kan osammanhängande paket skada en app vid genomförande av större uppgraderingar. De flesta av dessa problem kan åtgärdas genom att följa dessa instruktioner:

1. Ta bort bin och obj mappar.

2. Rensa paketcacheminnena genom att köra dotnet nuget locals all --clear från ett kommandogränssnitt.

   Du kan också rensa paketcacheminnen med verktyget nuget.exe och köra kommandot nuget locals all -clear. nuget.exe är inte en paketerad installation med Windows-skrivbordsoperativsystemet och måste hämtas separat från NuGet-webbplatsen.

3. Återställa och återskapa projektet.

4. Ta bort alla filer i distributionsmappen på servern innan du distribuerar om appen.

Additional resources

• Felsök och avbugga ASP.NET Core-projekt
• Vanliga fel vid felsökning för Azure App Service och IIS med ASP.NET Core
• Hantera fel i ASP.NET Core
• ASP.NET Core Module (ANCM) för IIS

Azure documentation

• Application Insights för ASP.NET Core
• Avsnittet Fjärrfelsökning av webbappar i Felsöka en webbapp i Azure App Service med hjälp av Visual Studio
• Översikt över Azure App Service-diagnostik
• Anvisningar: Övervaka appar i Azure App Service
• Felsöka en webbapp i Azure App Service med Visual Studio
• Felsöka HTTP-fel med "502 felaktig gateway" och "503-tjänsten är inte tillgänglig" i dina Azure-webbappar
• Felsöka problem med prestanda och långsamma webbappar i Azure App Service
• Vanliga frågor och svar om programprestanda för Web Apps i Azure
• Sandbox-miljö för Azure Web App (körningsbegränsningar för App Service)

Dokumentation om Visual Studio

• Fjärrfelsöka ASP.NET Core på IIS i Azure i Visual Studio 2017
• Fjärrfelsöka ASP.NET Core på en fjärr-IIS-dator i Visual Studio 2017
• Lär dig att felsöka med Visual Studio

Visual Studio Code-dokumentation

• Felsökning med Visual Studio Code

Den här artikeln innehåller information om vanliga startfel för appar och instruktioner om hur du diagnostiserar fel när en app distribueras till Azure App Service eller IIS:

Startfel för appar
Förklarar vanliga scenarier för HTTP-statuskod för start.

Felsöka i Azure App Service
Ger felsökningsråd för appar som distribuerats till Azure App Service.

Felsöka på IIS
Ger felsökningsråd för appar som distribueras till IIS eller körs lokalt i IIS Express. Vägledningen gäller för både Windows Server- och Windows-skrivbordsdistributioner.

Rensa paketcacheminnen
Förklarar vad du ska göra när inkonsekventa paket bryter en app när du utför större uppgraderingar eller ändrar paketversioner.

Additional resources
Visar ytterligare felsökningsavsnitt.

Fel vid start av app

I Visual Studio är ett ASP.NET Core-projekt som standard IIS Express-värd under felsökning. Ett 502.5-processfel som inträffar vid felsökning lokalt kan diagnostiseras med hjälp av råden i det här avsnittet.

403.14 Forbidden

Det går inte att starta appen. Följande fel loggas:

The Web server is configured to not list the contents of this directory.

Felet orsakas vanligtvis av en trasig distribution på värdsystemet, vilket omfattar något av följande scenarier:

• Appen distribueras till fel mapp i värdsystemet.
• Distributionsprocessen kunde inte flytta alla appens filer och mappar till distributionsmappen i värdsystemet.
• Den web.config filen saknas i distributionen, eller så är web.config filinnehållet felaktigt.

Utför följande steg:

1. Ta bort alla filer och mappar från distributionsmappen i värdsystemet.
2. Distribuera om innehållet i appens publiceringsmapp till värdsystemet med din normala distributionsmetod, till exempel Visual Studio, PowerShell eller manuell distribution:
   • Bekräfta att web.config filen finns i distributionen och att dess innehåll är korrekt.
   • När du är värd för Azure App Service kontrollerar du att appen har distribuerats till D:\home\site\wwwroot mappen.
   • När appen hanteras av IIS kontrollerar du att appen har distribuerats till den fysiska IIS-sökvägen som visas i IIS-hanterarensgrundläggande inställningar.
3. Bekräfta att alla appens filer och mappar distribueras genom att jämföra distributionen i värdsystemet med innehållet i projektets publiceringsmapp .

Mer information om layouten för en publicerad ASP.NET Core-app finns i ASP.NET Core-katalogstruktur. Mer information om filenweb.config finns i ASP.NET Core Module (ANCM) för IIS.

500 Internt fel på servern

Appen startar, men ett fel hindrar servern från att uppfylla begäran.

Det här felet uppstår i appens kod under starten eller när du skapar ett svar. Svaret får inte innehålla något innehåll, eller så kan svaret visas som ett 500 internt serverfel i webbläsaren. Programhändelseloggen anger vanligtvis att appen startade normalt. Från serverns perspektiv stämmer det. Appen startade, men den kan inte generera ett giltigt svar. Kör appen i en kommandotolk på servern eller aktivera stdout-loggen för ASP.NET Core Module för att felsöka problemet.

Det här felet kan också inträffa när .NET Core-värdpaketet inte är installerat eller är skadat. Du kan lösa problemet genom att installera eller reparera installationen av .NET Core Hosting Bundle (för IIS) eller Visual Studio (för IIS Express).

502.5 processfel

Arbetsprocessen misslyckas. Appen startar inte.

ASP.NET Core-modulen försöker starta arbetsprocessen, men den startar inte. Orsaken till ett processstartfel kan vanligtvis fastställas från poster i programhändelseloggen och stdout-loggen för ASP.NET Core-modulen.

Ett vanligt feltillstånd är att appen är felkonfigurerad på grund av att den riktar in sig på en version av det delade ASP.NET Core-ramverket som inte finns. Kontrollera vilka versioner av det delade ASP.NET Core-ramverket som är installerade på måldatorn. Det delade ramverket är uppsättningen sammansättningar (.dll filer) som installeras på datorn och refereras av ett metapaket som Microsoft.AspNetCore.App. Metapackage-referensen kan ange en lägsta version som krävs. Mer information finns i Det delade ramverket.

Felsidan för processfel i 502.5 returneras när en värd- eller appfelkonfiguration gör att arbetsprocessen misslyckas:

Det gick inte att starta programmet (ErrorCode "0x800700c1")

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

Det gick inte att starta appen eftersom det inte gick att läsa in appens sammansättning (.dll).

Det här felet uppstår när det finns en bitnessmatchning mellan den publicerade appen och w3wp/iisexpress-processen.

Kontrollera att apppoolens 32-bitarsinställning är korrekt:

1. Välj apppoolen i IIS-hanterarens programpooler.
2. Välj Avancerade inställningar under Redigera programpool på panelen Åtgärder .
3. Ange Aktivera 32-bitarsprogram:
   • Om du distribuerar en 32-bitarsapp (x86) anger du värdet till True.
   • Om du distribuerar en 64-bitarsapp (x64) anger du värdet till False.

Bekräfta att det inte finns någon konflikt mellan en <Platform> MSBuild-egenskap i projektfilen och appens publicerade bitness.

Connection reset

Om ett fel uppstår efter att rubrikerna har skickats är det för sent för servern att skicka ett 500 internt serverfel när ett fel inträffar. Detta inträffar ofta när ett fel inträffar under serialiseringen av komplexa objekt för ett svar. Den här typen av fel visas som ett anslutningsåterställningsfel på klienten. Programloggning kan hjälpa dig att felsöka dessa typer av fel.

Standardbegränsningar för start

ASP.NET Core-modulen konfigureras med en standardstartTimeLimit på 120 sekunder. När den lämnas kvar vid standardvärdet kan det ta upp till två minuter innan modulen loggar ett processfel. Information om hur du konfigurerar modulen finns i Attribut för aspNetCore-elementet.

Felsöka i Azure App Service

Programhändelselogg (Azure App Service)

Om du vill komma åt programhändelseloggen använder du bladet Diagnostisera och lösa problem i Azure-portalen:

1. Öppna appen i App Services i Azure-portalen.
2. Välj Diagnostisera och lösa problem.
3. Välj rubriken Diagnostikverktyg .
4. Under Supportverktyg väljer du knappen Programhändelser .
5. Granska det senaste felet från posten IIS AspNetCoreModule eller IIS AspNetCoreModule V2 i kolumnen Källa .

Ett alternativ till att använda bladet Diagnostisera och lösa problem är att undersöka programhändelseloggfilen direkt med Kudu:

1. Öppna Avancerade verktyg i området Utvecklingsverktyg . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
2. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
3. Öppna mappen LogFiles.
4. Välj pennikonen bredvid eventlog.xml filen.
5. Granska loggen. Rulla längst ned i loggen för att se de senaste händelserna.

Kör appen i Kudu-konsolen

Många startfel genererar inte användbar information i programhändelseloggen. Du kan köra appen i Kudu-fjärrkörningskonsolen för att upptäcka felet:

1. Öppna Avancerade verktyg i området Utvecklingsverktyg . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
2. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.

Testa en 32-bitars app (x86)

Current release

1. cd d:\home\site\wwwroot
2. Kör appen:

   • Om appen är en ramverksberoende distribution:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Om appen är en fristående distribution:

     {ASSEMBLY NAME}.exe
     

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

Ramverksberoende distribution som körs på en förhandsversion

Kräver installation av ASP.NET Core {VERSION} (x86) Runtime-webbplatstillägget.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} är körningsversionen)
2. Kör appen: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

Testa en 64-bitars app (x64)

Current release

• Om appen är en 64-bitars (x64) ramverksberoende distribution:
  1. cd D:\Program Files\dotnet
  2. Kör appen: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Om appen är en fristående distribution:
  1. cd D:\home\site\wwwroot
  2. Kör appen: {ASSEMBLY NAME}.exe

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

Ramverksberoende distribution som körs på en förhandsversion

Kräver installation av webbplatstillägget ASP.NET Core {VERSION} (x64).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} är körningsversionen)
2. Kör appen: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

ASP.NET Core Module stdout-logg (Azure App Service)

Den ASP.NET Core Module stdout-loggen registrerar ofta användbara felmeddelanden som inte hittades i programhändelseloggen. Så här aktiverar och visar du stdout-loggar:

1. Gå till bladet Diagnostisera och lösa problem i Azure-portalen.
2. Under VÄLJ PROBLEMKATEGORI väljer du knappen Webbapp nedåt .
3. Under Föreslagna lösningar>Aktivera omdirigering av Stdout-logg väljer du knappen för att öppna Kudu-konsolen för att redigera Web.Config.
4. I Kudu-diagnostikkonsolen öppnar du mapparna till sökvägswebbplatsen>wwwroot. Rulla nedåt för att visa filenweb.config längst ned i listan.
5. Klicka på pennikonen bredvid filenweb.config .
6. Ange stdoutLogEnabled till true och ändra stdoutLogFile-sökvägen till: \\?\%home%\LogFiles\stdout.
7. Välj Spara för att spara den uppdaterade web.config filen.
8. Skicka en begäran till appen.
9. Gå tillbaka till Azure-portalen. Välj bladet Avancerade verktyg i området UTVECKLINGSVERKTYG . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
10. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
11. Välj mappen LogFiles .
12. Granska kolumnen Ändrad och välj pennikonen för att redigera stdout-loggen med det senaste ändringsdatumet.
13. När loggfilen öppnas visas felet.

Inaktivera stdout-loggning när felsökningen är klar:

1. I Kudu-diagnostikkonsolen går du tillbaka till sökvägswebbplatsen>wwwroot för att visa filenweb.config . Öppna filenweb.config igen genom att välja pennikonen.
2. Ange stdoutLogEnabled till false.
3. Spara filen genom att välja Spara .

Mer information finns i ASP.NET Core Module (ANCM) för IIS.

Långsam eller icke-svarande app (Azure App Service)

När en app svarar långsamt eller inte svarar på en begäran kan du läsa följande artiklar:

• Felsöka problem med prestanda och långsamma webbappar i Azure App Service
• Använda Crash Diagnoser Site Extension för att avbilda dumpar för tillfälliga undantagsproblem eller prestandaproblem i Azure Web App

Monitoring blades

Övervakningsblad ger en alternativ felsökningsupplevelse till de metoder som beskrevs tidigare i ämnet. Dessa blad kan användas för att diagnostisera fel i 500-serien.

Bekräfta att ASP.NET Core Extensions är installerade. Om tilläggen inte är installerade installerar du dem manuellt:

1. I bladet UTVECKLINGSVERKTYG väljer du bladet Tillägg .
2. ASP.NET Core Extensions bör visas i listan.
3. Om tilläggen inte är installerade väljer du knappen Lägg till .
4. Välj ASP.NET Core Extensions i listan.
5. Välj OK för att acceptera de juridiska villkoren.
6. Välj OK på bladet Lägg till tillägg .
7. Ett informationsmeddelande anger när tilläggen har installerats.

Om stdout-loggning inte är aktiverat följer du dessa steg:

1. I Azure-portalen väljer du bladet Avancerade verktyg i området UTVECKLINGSVERKTYG . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
2. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
3. Öppna mapparna till sökvägswebbplatsen>wwwroot och rulla nedåt för att visa web.config filen längst ned i listan.
4. Klicka på pennikonen bredvid filenweb.config .
5. Ange stdoutLogEnabled till true och ändra stdoutLogFile-sökvägen till: \\?\%home%\LogFiles\stdout.
6. Välj Spara för att spara den uppdaterade web.config filen.

Fortsätt med att aktivera diagnostikloggning:

1. I Azure-portalen väljer du bladet Diagnostikloggar .
2. Välj växeln På för Programloggning (Filsystem) och Detaljerade felmeddelanden. Välj knappen Spara överst på bladet.
3. Om du vill inkludera spårning av misslyckade begäranden, även kallat LOGGning av händelsebuffertning för misslyckade begäranden (FREB), väljer du växeln På för Spårning av misslyckade begäranden.
4. Välj bladet Loggström , som visas direkt under bladet Diagnostikloggar i portalen.
5. Skicka en begäran till appen.
6. I loggströmsdata anges orsaken till felet.

Se till att inaktivera stdout-loggning när felsökningen är klar.

Så här visar du spårningsloggarna för misslyckade förfrågningar (FREB-loggar):

1. Gå till bladet Diagnostisera och lösa problem i Azure-portalen.
2. Välj Spårningsloggar för misslyckade begäranden från området SUPPORTVERKTYG i sidofältet.

Se avsnittet Spårning av misslyckade begäranden i avsnittet Aktivera diagnostikloggning för webbappar i Azure App Service och vanliga frågor och svar om programprestanda för Web Apps i Azure: Hur aktiverar jag spårning av misslyckade förfrågningar? för mer information.

Mer information finns i Aktivera diagnostikloggning för webbappar i Azure App Service.

Felsöka på IIS

Programhändelselogg (IIS)

Öppna programhändelseloggen:

1. Öppna Start-menyn, sök efter Händelseloggoch välj appen Händelselogg.
2. I Loggbokenöppnar du noden Windows-loggar.
3. Välj program för att öppna programhändelseloggen.
4. Sök efter fel som är associerade med den misslyckade appen. Fel har värdet IIS AspNetCore-modul ellerIIS Express AspNetCore-modul i kolumnen Källa .

Kör appen i en kommandotolk

Många startfel genererar inte användbar information i programhändelseloggen. Du kan hitta orsaken till vissa fel genom att köra appen i en kommandotolk på värdsystemet.

Framework-dependent deployment

Om appen är en ramverksberoende distribution:

1. I en kommandotolk navigerar du till distributionsmappen och kör appen genom att köra appens sammansättning med dotnet.exe. I följande kommando ersätter du namnet på appens sammansättning med <assembly_name>: dotnet .\<assembly_name>.dll.
2. Konsolens utdata från appen, som visar eventuella fel, skrivs till konsolfönstret.
3. Om felen uppstår när du skickar en begäran till appen skickar du en begäran till värden och porten där Kestrel lyssnar. Använd standardvärden och skicka en begäran till http://localhost:5000/. Om appen svarar normalt på slutpunktsadressen Kestrel är problemet mer sannolikt relaterat till värdkonfigurationen och mindre troligt i appen.

Self-contained deployment

Om appen är en fristående distribution:

1. I en kommandotolk navigerar du till distributionsmappen och kör appens körbara fil. I följande kommando ersätter du namnet på appens sammansättning med <assembly_name>: <assembly_name>.exe.
2. Konsolens utdata från appen, som visar eventuella fel, skrivs till konsolfönstret.
3. Om felen uppstår när du skickar en begäran till appen skickar du en begäran till värden och porten där Kestrel lyssnar. Använd standardvärden och skicka en begäran till http://localhost:5000/. Om appen svarar normalt på slutpunktsadressen Kestrel är problemet mer sannolikt relaterat till värdkonfigurationen och mindre troligt i appen.

ASP.NET Core Module stdout log (IIS)

Så här aktiverar och visar du stdout-loggar:

1. Gå till platsens distributionsmapp i värdsystemet.
2. Om loggmappen inte finns skapar du mappen. Anvisningar om hur du aktiverar MSBuild för att skapa loggmappen i distributionen automatiskt finns i avsnittet Katalogstruktur .
3. Redigera filen web.config. Ange stdoutLogEnabled till true och ändra sökvägen stdoutLogFile så att den pekar på loggmappen (till exempel .\logs\stdout). stdout i sökvägen finns prefixet för loggfilens namn. En tidsstämpel, process-ID och filnamnstillägg läggs till automatiskt när loggen skapas. Med hjälp av stdout filnamnsprefixet heter en typisk loggfil stdout_20180205184032_5412.log.
4. Kontrollera att programpoolens identitet har skrivbehörighet till loggmappen.
5. Spara den uppdaterade filen web.config .
6. Skicka en begäran till appen.
7. Gå till loggmappen. Hitta och öppna den senaste stdout-loggen.
8. Studera loggen efter fel.

Inaktivera stdout-loggning när felsökningen är klar:

1. Redigera filen web.config.
2. Ange stdoutLogEnabled till false.
3. Spara filen.

Mer information finns i ASP.NET Core Module (ANCM) för IIS.

Aktivera undantagssidan för utvecklare

Miljövariabeln ASPNETCORE_ENVIRONMENTkan läggas till i web.config för att köra appen i utvecklingsmiljön. Så länge miljön inte åsidosätts i appstarten av på värdverktyget, tillåter inställningen av UseEnvironment miljövariabeln att undantagssidan för utvecklare visas när appen körs.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  </environmentVariables>
</aspNetCore>

Att ange miljövariabeln för ASPNETCORE_ENVIRONMENT rekommenderas endast för användning på mellanlagrings- och testservrar som inte exponeras för Internet. Ta bort miljövariabeln från filen web.config efter felsökning. Information om hur du anger miljövariabler i web.configfinns i environmentVariables underordnade element i aspNetCore.

Hämta data från en app

Om en app kan svara på begäranden hämtar du begäran, anslutning och ytterligare data från appen med hjälp av terminalens infogade mellanprogram. Mer information och exempelkod finns i Felsöka och felsöka ASP.NET Core-projekt.

Långsam eller icke-svarande app (IIS)

En kraschdump är en ögonblicksbild av systemets minne och kan hjälpa dig att fastställa orsaken till en appkrasch, ett startfel eller en långsam app.

Appen kraschar eller stöter på ett undantag

Hämta och analysera en dump från Windows Error Reporting (WER):

1. Skapa en mapp för att lagra kraschdumpfiler på c:\dumps. Apppoolen måste ha skrivbehörighet till mappen.

2. Kör PowerShell-skriptet EnableDumps:

   • Om appen använder den processbaserade värdmodellen kör du skriptet för w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • Om appen använder en out-of-process-värdmodell kör du skriptet för dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Kör appen under de förhållanden som orsakar kraschen.

4. När kraschen har inträffat kör du DisableDumps PowerShell-skriptet:

   • Om appen använder den processbaserade värdmodellen kör du skriptet för w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • Om appen använder en out-of-process-värdmodell kör du skriptet för dotnet.exe:

     .\DisableDumps dotnet.exe
     

När en app kraschar och dumpsamlingen har slutförts kan appen avslutas normalt. PowerShell-skriptet konfigurerar WER för att samla in upp till fem dumpar per app.

Appen svarar inte, misslyckas vid start eller körs normalt

När en app slutar svara men inte kraschar, misslyckas vid start eller körs normalt kan du läsa User-Mode Dump Files: Välja det bästa verktyget för att välja ett lämpligt verktyg för att skapa dumpen.

Analysera datadumpen

En dump kan analyseras med flera metoder. Mer information finns i Analysera en User-Mode dumpfil.

Rensa paketcache

En fungerande app kan misslyckas omedelbart efter att ha uppgraderat .NET Core SDK på utvecklingsdatorn eller ändrat paketversioner i appen. I vissa fall kan osammanhängande paket skada en app vid genomförande av större uppgraderingar. De flesta av dessa problem kan åtgärdas genom att följa dessa instruktioner:

1. Ta bort bin och obj mappar.

2. Rensa paketcacheminnena genom att köra dotnet nuget locals all --clear från ett kommandogränssnitt.

   Du kan också rensa paketcacheminnen med verktyget nuget.exe och köra kommandot nuget locals all -clear. nuget.exe är inte en paketerad installation med Windows-skrivbordsoperativsystemet och måste hämtas separat från NuGet-webbplatsen.

3. Återställa och återskapa projektet.

4. Ta bort alla filer i distributionsmappen på servern innan du distribuerar om appen.

Additional resources

• Felsök och avbugga ASP.NET Core-projekt
• Vanliga fel vid felsökning för Azure App Service och IIS med ASP.NET Core
• Hantera fel i ASP.NET Core
• ASP.NET Core Module (ANCM) för IIS

Azure documentation

• Application Insights för ASP.NET Core
• Avsnittet Fjärrfelsökning av webbappar i Felsöka en webbapp i Azure App Service med hjälp av Visual Studio
• Översikt över Azure App Service-diagnostik
• Anvisningar: Övervaka appar i Azure App Service
• Felsöka en webbapp i Azure App Service med Visual Studio
• Felsöka HTTP-fel med "502 felaktig gateway" och "503-tjänsten är inte tillgänglig" i dina Azure-webbappar
• Felsöka problem med prestanda och långsamma webbappar i Azure App Service
• Vanliga frågor och svar om programprestanda för Web Apps i Azure
• Sandbox-miljö för Azure Web App (körningsbegränsningar för App Service)

Dokumentation om Visual Studio

• Fjärrfelsöka ASP.NET Core på IIS i Azure i Visual Studio 2017
• Fjärrfelsöka ASP.NET Core på en fjärr-IIS-dator i Visual Studio 2017
• Lär dig att felsöka med Visual Studio

Visual Studio Code-dokumentation

• Felsökning med Visual Studio Code

Den här artikeln innehåller information om vanliga startfel för appar och instruktioner om hur du diagnostiserar fel när en app distribueras till Azure App Service eller IIS:

Startfel för appar
Förklarar vanliga scenarier för HTTP-statuskod för start.

Felsöka i Azure App Service
Ger felsökningsråd för appar som distribuerats till Azure App Service.

Felsöka på IIS
Ger felsökningsråd för appar som distribueras till IIS eller körs lokalt i IIS Express. Vägledningen gäller för både Windows Server- och Windows-skrivbordsdistributioner.

Rensa paketcacheminnen
Förklarar vad du ska göra när inkonsekventa paket bryter en app när du utför större uppgraderingar eller ändrar paketversioner.

Additional resources
Visar ytterligare felsökningsavsnitt.

Fel vid start av app

I Visual Studio är Kestrelstandardservern för ASP.NET Core-projektet . Visual Studio kan konfigureras för att använda IIS Express. Ett 502.5 – Processfel eller 500.30 – Startfel som inträffar när felsökning lokalt med IIS Express kan diagnostiseras med hjälp av råden i det här avsnittet.

403.14 Forbidden

Det går inte att starta appen. Följande fel loggas:

The Web server is configured to not list the contents of this directory.

Felet orsakas vanligtvis av en trasig distribution på värdsystemet, vilket omfattar något av följande scenarier:

• Appen distribueras till fel mapp i värdsystemet.
• Distributionsprocessen kunde inte flytta alla appens filer och mappar till distributionsmappen i värdsystemet.
• Den web.config filen saknas i distributionen, eller så är web.config filinnehållet felaktigt.

Utför följande steg:

1. Ta bort alla filer och mappar från distributionsmappen i värdsystemet.
2. Distribuera om innehållet i appens publiceringsmapp till värdsystemet med din normala distributionsmetod, till exempel Visual Studio, PowerShell eller manuell distribution:
   • Bekräfta att web.config filen finns i distributionen och att dess innehåll är korrekt.
   • När du är värd för Azure App Service kontrollerar du att appen har distribuerats till D:\home\site\wwwroot mappen.
   • När appen hanteras av IIS kontrollerar du att appen har distribuerats till den fysiska IIS-sökvägen som visas i IIS-hanterarensgrundläggande inställningar.
3. Bekräfta att alla appens filer och mappar distribueras genom att jämföra distributionen i värdsystemet med innehållet i projektets publiceringsmapp .

Mer information om layouten för en publicerad ASP.NET Core-app finns i ASP.NET Core-katalogstruktur. Mer information om filenweb.config finns i ASP.NET Core Module (ANCM) för IIS.

500 Internt fel på servern

Appen startar, men ett fel hindrar servern från att uppfylla begäran.

Det här felet uppstår i appens kod under starten eller när du skapar ett svar. Svaret får inte innehålla något innehåll, eller så kan svaret visas som ett 500 internt serverfel i webbläsaren. Programhändelseloggen anger vanligtvis att appen startade normalt. Från serverns perspektiv stämmer det. Appen startade, men den kan inte generera ett giltigt svar. Kör appen i en kommandotolk på servern eller aktivera stdout-loggen för ASP.NET Core Module för att felsöka problemet.

Det här felet kan också inträffa när .NET-värdpaketet inte är installerat eller är skadat. Om du installerar eller reparerar installationen av .NET Hosting Bundle (för IIS) eller Visual Studio (för IIS Express) kan problemet åtgärdas.

500.0 In-Process hanterarens inläsningsfel

Arbetsprocessen misslyckas. Appen startar inte.

Ett okänt fel uppstod när ASP.NET Core Module-komponenter skulle läsas in. Välj en av följande åtgärder:

• Kontakta Microsoft Support (välj Utvecklarverktyg och sedan ASP.NET Core).
• Ställ en fråga om Stack Overflow.
• Skapa ett problem på vår GitHub-lagringsplats.

500.30 In-Process startfel

Arbetsprocessen misslyckas. Appen startar inte.

ASP.NET Core-modulen försöker starta .NET CLR i processen, men det går inte att starta. Orsaken till ett processstartfel kan vanligtvis fastställas från poster i programhändelseloggen och stdout-loggen för ASP.NET Core-modulen.

Vanliga feltillstånd:

• Appen är felkonfigurerad på grund av att den riktar in sig på en version av det delade ASP.NET Core-ramverket som inte finns. Kontrollera vilka versioner av det delade ASP.NET Core-ramverket som är installerade på måldatorn.
• Med Hjälp av Azure Key Vault saknas behörigheter till Key Vault. Kontrollera åtkomstprinciperna i det riktade Nyckelvalvet för att säkerställa att rätt behörigheter beviljas.

500.31 ANCM kunde inte hitta interna beroenden

Arbetsprocessen misslyckas. Appen startar inte.

ASP.NET Core-modulen försöker starta .NET-körningen i processen, men den startar inte. Den vanligaste orsaken till det här startfelet är när körningen Microsoft.NETCore.App eller Microsoft.AspNetCore.App inte är installerad. Om appen distribueras till målet ASP.NET Core 3.0 och den versionen inte finns på datorn uppstår det här felet. Ett exempel på ett felmeddelande följer:

The specified framework 'Microsoft.NETCore.App', version '3.0.0' was not found.
  - The following frameworks were found:
      2.2.1 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview5-27626-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27713-13 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27714-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27723-08 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]

Felmeddelandet visar alla installerade .NET-versioner och den version som begärs av appen. Åtgärda det här felet genom att antingen:

• Installera lämplig version av .NET på datorn.
• Ändra appen så att den riktar in sig på en version av .NET som finns på datorn.
• Publicera appen som en fristående distribution.

När du kör under utveckling ( ASPNETCORE_ENVIRONMENT miljövariabeln är inställd på Development) skrivs det specifika felet till HTTP-svaret. Orsaken till ett processstartfel finns också i programhändelseloggen.

500.32 ANCM kunde inte läsa in dll

Arbetsprocessen misslyckas. Appen startar inte.

Den vanligaste orsaken till det här felet är att appen publiceras för en inkompatibel processorarkitektur. Om arbetsprocessen körs som en 32-bitarsapp och appen har publicerats som mål för 64-bitars, uppstår det här felet.

Åtgärda det här felet genom att antingen:

• Publicera om appen för samma processorarkitektur som arbetsprocessen.
• Publicera appen som en ramverksberoende distribution.

Inläsningsfel för 500.33 ANCM-begärandehanterare

Arbetsprocessen misslyckas. Appen startar inte.

Appen refererade inte till ramverket Microsoft.AspNetCore.App . Endast appar som är riktade mot ramverket Microsoft.AspNetCore.App kan hanteras av ASP.NET Core-modulen.

Om du vill åtgärda det här felet kontrollerar du att appen riktar in sig på ramverket Microsoft.AspNetCore.App . Kontrollera det .runtimeconfig.json ramverk som appen har som mål.

500.34 ANCM Mixed Hosting Models stöds inte

Arbetsprocessen kan inte köra både en processbaserad app och en out-of-process-app i samma process.

Du kan åtgärda det här felet genom att köra appar i separata IIS-programpooler.

500.35 ANCM Flera In-Process program i samma process

Arbetsprocessen kan inte köra flera pågående appar i samma process.

Du kan åtgärda det här felet genom att köra appar i separata IIS-programpooler.

500.36 ANCM out-Of-Process handler load failure (500.36 ANCM Out-Of-Process Handler Load Failure)

Hanteraren för out-of-process-begäran, aspnetcorev2_outofprocess.dll, är inte bredvid filenaspnetcorev2.dll . Detta indikerar en skadad installation av ASP.NET Core-modulen.

Åtgärda det här felet genom att reparera installationen av .NET Hosting Bundle (för IIS) eller Visual Studio (för IIS Express).

500.37 ANCM kunde inte starta inom starttidsgränsen

ANCM kunde inte starta inom den angivna starttiden. Som standard är tidsgränsen 120 sekunder.

Det här felet kan inträffa när du startar ett stort antal appar på samma dator. Sök efter toppar i cpu-/minnesanvändningen på servern under starten. Du kan behöva ändra startprocessen för flera appar.

500.38 ANCM-program-DLL hittades inte

ANCM kunde inte hitta programmets DLL, som ska vara bredvid den körbara filen.

Det här felet uppstår när du är värd för en app som paketeras som en körbar fil med hjälp av den processbaserade värdmodellen. In-processmodellen kräver att ANCM läser in .NET-appen i den befintliga IIS-processen. Det här scenariot stöds inte av distributionsmodellen med en fil. Använd någon av följande metoder i appens projektfil för att åtgärda det här felet:

1. Inaktivera publicering med en fil genom att ange PublishSingleFile egenskapen MSBuild till false.
2. Växla till den färdiga värdmodellen genom att ange AspNetCoreHostingModel egenskapen MSBuild till OutOfProcess.

502.5 processfel

Arbetsprocessen misslyckas. Appen startar inte.

ASP.NET Core-modulen försöker starta arbetsprocessen, men den startar inte. Orsaken till ett processstartfel kan vanligtvis fastställas från poster i programhändelseloggen och stdout-loggen för ASP.NET Core-modulen.

Ett vanligt feltillstånd är att appen är felkonfigurerad på grund av att den riktar in sig på en version av det delade ASP.NET Core-ramverket som inte finns. Kontrollera vilka versioner av det delade ASP.NET Core-ramverket som är installerade på måldatorn. Det delade ramverket är uppsättningen sammansättningar (.dll filer) som installeras på datorn och refereras av ett metapaket som Microsoft.AspNetCore.App. Metapackage-referensen kan ange en lägsta version som krävs. Mer information finns i Det delade ramverket.

Felsidan för processfel i 502.5 returneras när en värd- eller appfelkonfiguration gör att arbetsprocessen misslyckas:

Det gick inte att starta programmet (ErrorCode "0x800700c1")

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

Det gick inte att starta appen eftersom det inte gick att läsa in appens sammansättning (.dll).

Det här felet uppstår när det finns en bitnessmatchning mellan den publicerade appen och w3wp/iisexpress-processen.

Kontrollera att apppoolens 32-bitarsinställning är korrekt:

1. Välj apppoolen i IIS-hanterarens programpooler.
2. Välj Avancerade inställningar under Redigera programpool på panelen Åtgärder .
3. Ange Aktivera 32-bitarsprogram:
   • Om du distribuerar en 32-bitarsapp (x86) anger du värdet till True.
   • Om du distribuerar en 64-bitarsapp (x64) anger du värdet till False.

Bekräfta att det inte finns någon konflikt mellan en <Platform> MSBuild-egenskap i projektfilen och appens publicerade bitness.

Det gick inte att starta programmet (ErrorCode "0x800701b1")

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/3/ROOT', ErrorCode '0x800701b1'.

Det gick inte att starta appen eftersom en Windows-tjänst inte kunde läsas in.

En vanlig tjänst som måste aktiveras är "null"-tjänsten. Följande kommando aktiverar null Windows-tjänsten:

sc.exe start null

Connection reset

Om ett fel uppstår efter att rubrikerna har skickats är det för sent för servern att skicka ett 500 internt serverfel när ett fel inträffar. Detta inträffar ofta när ett fel inträffar under serialiseringen av komplexa objekt för ett svar. Den här typen av fel visas som ett anslutningsåterställningsfel på klienten. Programloggning kan hjälpa dig att felsöka dessa typer av fel.

Standardbegränsningar för start

ASP.NET Core-modulen konfigureras med en standardstartTimeLimit på 120 sekunder. När den lämnas kvar vid standardvärdet kan det ta upp till två minuter innan modulen loggar ett processfel. Information om hur du konfigurerar modulen finns i Attribut för aspNetCore-elementet.

Felsöka i Azure App Service

Azure App Services-loggström

Azure App Services-loggen strömmar logginformation när den inträffar. Så här visar du strömmande loggar:

1. Öppna appen i App Services i Azure-portalen.
2. I den vänstra rutan går du till Övervaka>App Service-loggar.
3. Välj Filsystem för webbserverloggning. Du kan också aktivera programloggning.
4. I den vänstra rutan går du till Övervakningsloggström> och väljer sedan Programloggar eller Webbserverloggar.

Följande bilder visar utdata från programloggarna:

Strömmande loggar har viss svarstid och kanske inte visas omedelbart.

Programhändelselogg (Azure App Service)

Om du vill komma åt programhändelseloggen använder du bladet Diagnostisera och lösa problem i Azure-portalen:

1. Öppna appen i App Services i Azure-portalen.
2. Välj Diagnostisera och lösa problem.
3. Välj rubriken Diagnostikverktyg .
4. Under Supportverktyg väljer du knappen Programhändelser .
5. Granska det senaste felet från posten IIS AspNetCoreModule eller IIS AspNetCoreModule V2 i kolumnen Källa .

Ett alternativ till att använda bladet Diagnostisera och lösa problem är att undersöka programhändelseloggfilen direkt med Kudu:

1. Öppna Avancerade verktyg i området Utvecklingsverktyg . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
2. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
3. Öppna mappen LogFiles.
4. Välj pennikonen bredvid eventlog.xml filen.
5. Granska loggen. Rulla längst ned i loggen för att se de senaste händelserna.

Kör appen i Kudu-konsolen

Många startfel genererar inte användbar information i programhändelseloggen. Du kan köra appen i Kudu-fjärrkörningskonsolen för att upptäcka felet:

1. Öppna Avancerade verktyg i området Utvecklingsverktyg . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
2. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.

Testa en 32-bitars app (x86)

Current release

1. cd d:\home\site\wwwroot
2. Kör appen:

   • Om appen är en ramverksberoende distribution:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Om appen är en fristående distribution:

     {ASSEMBLY NAME}.exe
     

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

Ramverksberoende distribution som körs på en förhandsversion

Kräver installation av ASP.NET Core {VERSION} (x86) Runtime-webbplatstillägget.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} är körningsversionen)
2. Kör appen: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

Testa en 64-bitars app (x64)

Current release

• Om appen är en 64-bitars (x64) ramverksberoende distribution:
  1. cd D:\Program Files\dotnet
  2. Kör appen: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Om appen är en fristående distribution:
  1. cd D:\home\site\wwwroot
  2. Kör appen: {ASSEMBLY NAME}.exe

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

Ramverksberoende distribution som körs på en förhandsversion

Kräver installation av webbplatstillägget ASP.NET Core {VERSION} (x64).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} är körningsversionen)
2. Kör appen: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Konsolens utdata från appen som visar eventuella fel, skickas till Kudu-konsolen.

ASP.NET Core Module stdout-logg (Azure App Service)

Den ASP.NET Core Module stdout-loggen registrerar ofta användbara felmeddelanden som inte hittades i programhändelseloggen. Så här aktiverar och visar du stdout-loggar:

1. Gå till webbappen i Azure-portalen.
2. På bladet App Service anger du kudu i sökrutan.
3. Välj Avancerade verktyg>Gå.
4. Välj Felsök konsolens > CMD.
5. Navigera till webbplats/wwwroot
6. Välj pennikonen för att redigera filenweb.config .
7. I elementet <aspNetCore /> anger stdoutLogEnabled="true" du och väljer Spara.

Inaktivera stdout-loggning när felsökningen är klar genom att ange stdoutLogEnabled="false".

Mer information finns i ASP.NET Core Module (ANCM) för IIS.

felsökningslogg för ASP.NET Core Module (Azure App Service)

Felsökningsloggen ASP.NET Core Module ger ytterligare, djupare loggning från ASP.NET Core-modulen. Så här aktiverar och visar du stdout-loggar:

1. Om du vill aktivera den förbättrade diagnostikloggen utför du något av följande:
   • Följ anvisningarna i Utökade diagnostikloggar för att konfigurera appen för en förbättrad diagnostikloggning. Omdistribuera appen.
   • Lägg till det <handlerSettings> som visas i Utökade diagnostikloggar i liveappens web.config-fil med hjälp av Kudu-konsolen:
     1. Öppna Avancerade verktyg i området Utvecklingsverktyg . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
     2. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
     3. Öppna mapparna till sökvägswebbplatsen>wwwroot. Redigera filenweb.config genom att välja pennknappen. Lägg till avsnittet enligt beskrivningen <handlerSettings> i Utökade diagnostikloggar. Välj Spara-knappen.
2. Öppna Avancerade verktyg i området Utvecklingsverktyg . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
3. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
4. Öppna mapparna till sökvägswebbplatsen>wwwroot. Om du inte angav någon sökväg för aspnetcore-debug.log-filen visas filen i listan. Om du angav en sökväg navigerar du till loggfilens plats.
5. Öppna loggfilen med pennknappen bredvid filnamnet.

Inaktivera felsökningsloggning när felsökningen är klar:

Om du vill inaktivera den förbättrade felsökningsloggen utför du något av följande:

• <handlerSettings> Ta bort filen från web.config lokalt och distribuera om appen.
• Använd Kudu-konsolen för att redigera web.config-filen och ta bort <handlerSettings> avsnittet. Spara filen.

Mer information finns i Skapa och omdirigera loggar med ASP.NET Core-modulen.

Långsam eller icke-svarande app (Azure App Service)

När en app svarar långsamt eller inte svarar på en begäran kan du läsa Felsöka långsamma prestandaproblem för webbappar i Azure App Service.

Monitoring blades

Övervakningsblad ger en alternativ felsökningsupplevelse till de metoder som beskrevs tidigare i ämnet. Dessa blad kan användas för att diagnostisera fel i 500-serien.

Bekräfta att ASP.NET Core Extensions är installerade. Om tilläggen inte är installerade installerar du dem manuellt:

1. I bladet UTVECKLINGSVERKTYG väljer du bladet Tillägg .
2. ASP.NET Core Extensions bör visas i listan.
3. Om tilläggen inte är installerade väljer du knappen Lägg till .
4. Välj ASP.NET Core Extensions i listan.
5. Välj OK för att acceptera de juridiska villkoren.
6. Välj OK på bladet Lägg till tillägg .
7. Ett informationsmeddelande anger när tilläggen har installerats.

Om stdout-loggning inte är aktiverat följer du dessa steg:

1. I Azure-portalen väljer du bladet Avancerade verktyg i området UTVECKLINGSVERKTYG . Välj knappen Go→ . Kudu-konsolen öppnas i en ny webbläsarflik eller ett nytt fönster.
2. Med hjälp av navigeringsfältet överst på sidan öppnar du Felsökningskonsolen och väljer CMD.
3. Öppna mapparna till sökvägswebbplatsen>wwwroot och rulla nedåt för att visa web.config filen längst ned i listan.
4. Klicka på pennikonen bredvid filenweb.config .
5. Ange stdoutLogEnabled till true och ändra stdoutLogFile-sökvägen till: \\?\%home%\LogFiles\stdout.
6. Välj Spara för att spara den uppdaterade web.config filen.

Fortsätt med att aktivera diagnostikloggning:

1. I Azure-portalen väljer du bladet Diagnostikloggar .
2. Välj växeln På för Programloggning (Filsystem) och Detaljerade felmeddelanden. Välj knappen Spara överst på bladet.
3. Om du vill inkludera spårning av misslyckade begäranden, även kallat LOGGning av händelsebuffertning för misslyckade begäranden (FREB), väljer du växeln På för Spårning av misslyckade begäranden.
4. Välj bladet Loggström , som visas direkt under bladet Diagnostikloggar i portalen.
5. Skicka en begäran till appen.
6. I loggströmsdata anges orsaken till felet.

Se till att inaktivera stdout-loggning när felsökningen är klar.

Så här visar du spårningsloggarna för misslyckade förfrågningar (FREB-loggar):

1. Gå till bladet Diagnostisera och lösa problem i Azure-portalen.
2. Välj Spårningsloggar för misslyckade begäranden från området SUPPORTVERKTYG i sidofältet.

Se avsnittet Spårning av misslyckade begäranden i avsnittet Aktivera diagnostikloggning för webbappar i Azure App Service och vanliga frågor och svar om programprestanda för Web Apps i Azure: Hur aktiverar jag spårning av misslyckade förfrågningar? för mer information.

Mer information finns i Aktivera diagnostikloggning för webbappar i Azure App Service.

Felsöka på IIS

Programhändelselogg (IIS)

Öppna programhändelseloggen:

1. Öppna Start-menyn, sök efter Händelseloggoch välj appen Händelselogg.
2. I Loggbokenöppnar du noden Windows-loggar.
3. Välj program för att öppna programhändelseloggen.
4. Sök efter fel som är associerade med den misslyckade appen. Fel har värdet IIS AspNetCore-modul ellerIIS Express AspNetCore-modul i kolumnen Källa .

Kör appen i en kommandotolk

Många startfel genererar inte användbar information i programhändelseloggen. Du kan hitta orsaken till vissa fel genom att köra appen i en kommandotolk på värdsystemet.

Framework-dependent deployment

Om appen är en ramverksberoende distribution:

1. I en kommandotolk navigerar du till distributionsmappen och kör appen genom att köra appens sammansättning med dotnet.exe. I följande kommando ersätter du namnet på appens sammansättning med <assembly_name>: dotnet .\<assembly_name>.dll.
2. Konsolens utdata från appen, som visar eventuella fel, skrivs till konsolfönstret.
3. Om felen uppstår när du skickar en begäran till appen skickar du en begäran till värden och porten där Kestrel lyssnar. Använd standardvärden och skicka en begäran till http://localhost:5000/. Om appen svarar normalt på slutpunktsadressen Kestrel är problemet mer sannolikt relaterat till värdkonfigurationen och mindre troligt i appen.

Self-contained deployment

Om appen är en fristående distribution:

1. I en kommandotolk navigerar du till distributionsmappen och kör appens körbara fil. I följande kommando ersätter du namnet på appens sammansättning med <assembly_name>: <assembly_name>.exe.
2. Konsolens utdata från appen, som visar eventuella fel, skrivs till konsolfönstret.
3. Om felen uppstår när du skickar en begäran till appen skickar du en begäran till värden och porten där Kestrel lyssnar. Använd standardvärden och skicka en begäran till http://localhost:5000/. Om appen svarar normalt på slutpunktsadressen Kestrel är problemet mer sannolikt relaterat till värdkonfigurationen och mindre troligt i appen.

ASP.NET Core Module stdout log (IIS)

Så här aktiverar och visar du stdout-loggar:

1. Gå till platsens distributionsmapp i värdsystemet.
2. Om loggmappen inte finns skapar du mappen. Anvisningar om hur du aktiverar MSBuild för att skapa loggmappen i distributionen automatiskt finns i avsnittet Katalogstruktur .
3. Redigera filen web.config. Ange stdoutLogEnabled till true och ändra sökvägen stdoutLogFile så att den pekar på loggmappen (till exempel .\logs\stdout). stdout i sökvägen finns prefixet för loggfilens namn. En tidsstämpel, process-ID och filnamnstillägg läggs till automatiskt när loggen skapas. Med hjälp av stdout filnamnsprefixet heter en typisk loggfil stdout_20180205184032_5412.log.
4. Kontrollera att programpoolens identitet har skrivbehörighet till loggmappen.
5. Spara den uppdaterade filen web.config .
6. Skicka en begäran till appen.
7. Gå till loggmappen. Hitta och öppna den senaste stdout-loggen.
8. Studera loggen efter fel.

Inaktivera stdout-loggning när felsökningen är klar:

1. Redigera filen web.config.
2. Ange stdoutLogEnabled till false.
3. Spara filen.

Mer information finns i ASP.NET Core Module (ANCM) för IIS.

felsökningslogg för ASP.NET Core Module (IIS)

Lägg till följande hanteringsinställningar i appens web.config-fil för att aktivera felsökningsloggen för ASP.NET Core Module:

<aspNetCore ...>
  <handlerSettings>
    <handlerSetting name="debugLevel" value="file" />
    <handlerSetting name="debugFile" value="c:\temp\ancm.log" />
  </handlerSettings>
</aspNetCore>

Bekräfta att sökvägen som angetts för loggen finns och att apppoolens identitet har skrivbehörighet till platsen.

Mer information finns i Skapa och omdirigera loggar med ASP.NET Core-modulen.

Aktivera undantagssidan för utvecklare

Miljövariabeln ASPNETCORE_ENVIRONMENTkan läggas till i web.config för att köra appen i utvecklingsmiljön. Så länge miljön inte åsidosätts i appstarten av på värdverktyget, tillåter inställningen av UseEnvironment miljövariabeln att undantagssidan för utvecklare visas när appen körs.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout"
      hostingModel="InProcess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  </environmentVariables>
</aspNetCore>

Att ange miljövariabeln för ASPNETCORE_ENVIRONMENT rekommenderas endast för användning på mellanlagrings- och testservrar som inte exponeras för Internet. Ta bort miljövariabeln från filen web.config efter felsökning. Information om hur du anger miljövariabler i web.configfinns i environmentVariables underordnade element i aspNetCore.

Hämta data från en app

Om en app kan svara på begäranden hämtar du begäran, anslutning och ytterligare data från appen med hjälp av terminalens infogade mellanprogram. Mer information och exempelkod finns i Felsöka och felsöka ASP.NET Core-projekt.

Långsam eller icke-svarande app (IIS)

En kraschdump är en ögonblicksbild av systemets minne och kan hjälpa dig att fastställa orsaken till en appkrasch, ett startfel eller en långsam app.

Appen kraschar eller stöter på ett undantag

Hämta och analysera en dump från Windows Error Reporting (WER):

1. Skapa en mapp för att lagra kraschdumpfiler på c:\dumps. Apppoolen måste ha skrivbehörighet till mappen.

2. Kör PowerShell-skriptet EnableDumps:

   • Om appen använder den processbaserade värdmodellen kör du skriptet för w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • Om appen använder en out-of-process-värdmodell kör du skriptet för dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Kör appen under de förhållanden som orsakar kraschen.

4. När kraschen har inträffat kör du DisableDumps PowerShell-skriptet:

   • Om appen använder den processbaserade värdmodellen kör du skriptet för w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • Om appen använder en out-of-process-värdmodell kör du skriptet för dotnet.exe:

     .\DisableDumps dotnet.exe
     

När en app kraschar och dumpsamlingen har slutförts kan appen avslutas normalt. PowerShell-skriptet konfigurerar WER för att samla in upp till fem dumpar per app.

Appen svarar inte, misslyckas vid start eller körs normalt

När en app slutar svara men inte kraschar, misslyckas vid start eller körs normalt kan du läsa User-Mode Dump Files: Välja det bästa verktyget för att välja ett lämpligt verktyg för att skapa dumpen.

Analysera datadumpen

En dump kan analyseras med flera metoder. Mer information finns i Analysera en User-Mode dumpfil.

Rensa paketcache

En fungerande app kan misslyckas omedelbart efter att ha uppgraderat .NET SDK på utvecklingsdatorn eller ändrat paketversioner i appen. I vissa fall kan osammanhängande paket skada en app vid genomförande av större uppgraderingar. De flesta av dessa problem kan åtgärdas genom att följa dessa instruktioner:

1. Ta bort bin och obj mappar.

2. Rensa paketcacheminnena genom att köra dotnet nuget locals all --clear från ett kommandogränssnitt.

   Du kan också rensa paketcacheminnen med verktyget nuget.exe och köra kommandot nuget locals all -clear. nuget.exe är inte en paketerad installation med Windows-skrivbordsoperativsystemet och måste hämtas separat från NuGet-webbplatsen.

3. Återställa och återskapa projektet.

4. Ta bort alla filer i distributionsmappen på servern innan du distribuerar om appen.

Additional resources

• Felsöka .NET- och ASP.NET Core-källkod med Visual Studio
• Felsök och avbugga ASP.NET Core-projekt
• Vanliga fel vid felsökning för Azure App Service och IIS med ASP.NET Core
• Hantera fel i ASP.NET Core
• ASP.NET Core Module (ANCM) för IIS

Azure documentation

• Application Insights för ASP.NET Core
• Avsnittet Fjärrfelsökning av webbappar i Felsöka en webbapp i Azure App Service med hjälp av Visual Studio
• Översikt över Azure App Service-diagnostik
• Anvisningar: Övervaka appar i Azure App Service
• Felsöka en webbapp i Azure App Service med Visual Studio
• Felsöka HTTP-fel med "502 felaktig gateway" och "503-tjänsten är inte tillgänglig" i dina Azure-webbappar
• Felsöka problem med prestanda och långsamma webbappar i Azure App Service
• Vanliga frågor och svar om programprestanda för Web Apps i Azure
• Sandbox-miljö för Azure Web App (körningsbegränsningar för App Service)

Dokumentation om Visual Studio

• Fjärrfelsöka ASP.NET Core på IIS i Azure i Visual Studio 2017
• Fjärrfelsöka ASP.NET Core på en fjärr-IIS-dator i Visual Studio 2017
• Lär dig att felsöka med Visual Studio

Visual Studio Code-dokumentation

• Felsökning med Visual Studio Code