Problemen met ASP.NET Core in Azure App Service en IIS oplossen

Dit artikel bevat informatie over veelvoorkomende opstartfouten en instructies voor het diagnosticeren van fouten wanneer een app wordt geïmplementeerd in Azure App Service of IIS:

Opstartfouten bij app
Hierin worden veelvoorkomende scenario's met HTTP-statuscode voor opstarten uitgelegd.

Problemen oplossen in Azure App Service
Biedt advies voor probleemoplossing voor apps die zijn geïmplementeerd in Azure App Service.

Problemen met IIS oplossen
Biedt advies voor probleemoplossing voor apps die zijn geïmplementeerd in IIS of lokaal worden uitgevoerd op IIS Express. De richtlijnen zijn van toepassing op zowel Windows Server- als Windows-bureaubladimplementaties.

Pakketcaches wissen
Hierin wordt uitgelegd wat u moet doen wanneer incoherent pakketten een app breken bij het uitvoeren van belangrijke upgrades of het wijzigen van pakketversies.

Additional resources
Hier vindt u aanvullende onderwerpen over probleemoplossing.

Opstartfouten van apps

In Visual Studio is Kestrelde standaardserver van het ASP.NET Core-project. Visual Studio kan worden geconfigureerd voor het gebruik van IIS Express. Een 502.5 - Procesfout of een 500.30 - Fout starten die optreedt wanneer lokaal foutopsporing met IIS Express kan worden vastgesteld met behulp van het advies in dit onderwerp.

403.14 Forbidden

De app kan niet worden gestart. De volgende fout wordt geregistreerd:

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

De fout wordt meestal veroorzaakt door een verbroken implementatie op het hostingsysteem, waaronder een van de volgende scenario's:

• De app wordt geïmplementeerd in de verkeerde map op het hostingsysteem.
• Het implementatieproces kan niet alle bestanden en mappen van de app verplaatsen naar de implementatiemap op het hostingsysteem.
• Het web.config bestand ontbreekt in de implementatie of de inhoud van hetweb.config bestand is onjuist.

Voer de volgende stappen uit:

1. Verwijder alle bestanden en mappen uit de implementatiemap op het hostingsysteem.
2. Implementeer de inhoud van de publicatiemap van de app opnieuw naar het hostingsysteem met behulp van uw normale implementatiemethode, zoals Visual Studio, PowerShell of handmatige implementatie:
   • Controleer of het web.config-bestand aanwezig is in de implementatie en of de inhoud juist is.
   • Wanneer u host in Azure App Service, controleert u of de app is geïmplementeerd in de D:\home\site\wwwroot map.
   • Wanneer de app wordt gehost door IIS, controleert u of de app is geïmplementeerd op het fysieke IIS-pad dat wordt weergegeven in de basisinstellingen van IIS-beheer.
3. Controleer of alle bestanden en mappen van de app zijn geïmplementeerd door de implementatie op het hostingsysteem te vergelijken met de inhoud van de publicatiemap van het project.

Zie ASP.NET Core-mapstructuur voor meer informatie over de indeling van een gepubliceerde ASP.NET Core-app. Zie ASP.NET Core Module (ANCM) voor IIS voor meer informatie over het bestandweb.config.

500 Interne Serverfout

De app wordt gestart, maar een fout voorkomt dat de server aan de aanvraag voldoet.

Deze fout treedt op in de code van de app tijdens het opstarten of tijdens het maken van een antwoord. Het antwoord bevat mogelijk geen inhoud of het antwoord kan worden weergegeven als een interne serverfout van 500 in de browser. In het toepassingslogboek wordt meestal aangegeven dat de app normaal is gestart. Dat is juist vanuit het perspectief van de server. De app is gestart, maar er kan geen geldig antwoord worden gegenereerd. Voer de app uit bij een opdrachtprompt op de server of schakel het stdout-logboek van de ASP.NET Core Module in om het probleem op te lossen.

Deze fout kan ook optreden wanneer de .NET-hostingbundel niet is geïnstalleerd of beschadigd is. Het probleem kan worden opgelost door de installatie van de .NET Hosting Bundle (voor IIS) of Visual Studio (voor IIS Express) te installeren of te herstellen.

500.0 In-Process Load Failure

Het werkproces mislukt. De app wordt niet gestart.

Er is een onbekende fout opgetreden bij het laden van ASP.NET Core Module-onderdelen . Ga in dat geval op een van de volgende manieren te werk:

• Neem contact op met Microsoft Ondersteuning (selecteer Ontwikkelhulpprogramma'sen ASP.NET Core).
• Stel een vraag op Stack Overflow.
• Dien een probleem in in onze GitHub-opslagplaats.

500.30 In-Process opstartfout

Het werkproces mislukt. De app wordt niet gestart.

De ASP.NET Core-module probeert de .NET CLR in het proces te starten, maar kan niet worden gestart. De oorzaak van een opstartfout in een proces kan meestal worden bepaald op basis van vermeldingen in het gebeurtenislogboek van de toepassing en het stdout-logboek van de ASP.NET Core Module.

Algemene foutvoorwaarden:

• De app is onjuist geconfigureerd vanwege het doel van een versie van het gedeelde ASP.NET Core-framework dat niet aanwezig is. Controleer welke versies van het gedeelde framework ASP.NET Core op de doelcomputer zijn geïnstalleerd.
• Het gebruik van Azure Key Vault, gebrek aan machtigingen voor de Key Vault. Controleer het toegangsbeleid in de doelsleutelkluis om ervoor te zorgen dat de juiste machtigingen worden verleend.

500.31 ANCM kan geen systeemeigen afhankelijkheden vinden

Het werkproces mislukt. De app wordt niet gestart.

De ASP.NET Core Module probeert de .NET-runtime in het proces te starten, maar kan niet worden gestart. De meest voorkomende oorzaak van deze opstartfout is wanneer de Microsoft.NETCore.App of Microsoft.AspNetCore.App runtime niet is geïnstalleerd. Als de app is geïmplementeerd voor het doel ASP.NET Core 3.0 en die versie niet op de computer bestaat, treedt deze fout op. Een voorbeeld van een foutbericht volgt:

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]

Het foutbericht bevat alle geïnstalleerde .NET-versies en de versie die door de app is aangevraagd. U kunt deze fout als volgt oplossen:

• Installeer de juiste versie van .NET op de computer.
• Wijzig de app in het doel van een versie van .NET die aanwezig is op de computer.
• Publiceer de app als een zelfstandige implementatie.

Wanneer de omgevingsvariabele wordt uitgevoerd in ontwikkeling (de ASPNETCORE_ENVIRONMENT omgevingsvariabele is ingesteld op Development), wordt de specifieke fout naar het HTTP-antwoord geschreven. De oorzaak van een opstartfout bij het proces vindt u ook in het gebeurtenislogboek van de toepassing.

500.32 ANCM kan dll niet laden

Het werkproces mislukt. De app wordt niet gestart.

De meest voorkomende oorzaak voor deze fout is dat de app wordt gepubliceerd voor een incompatibele processorarchitectuur. Als het werkproces wordt uitgevoerd als een 32-bits app en de app is gepubliceerd naar doel 64-bits, treedt deze fout op.

U kunt deze fout als volgt oplossen:

• Publiceer de app opnieuw voor dezelfde processorarchitectuur als het werkproces.
• Publiceer de app als een frameworkafhankelijke implementatie.

500.33 ANCM Request Handler Load Failure

Het werkproces mislukt. De app wordt niet gestart.

De app heeft niet verwezen naar het Microsoft.AspNetCore.App framework. Alleen apps die zijn gericht op het Microsoft.AspNetCore.App framework, kunnen worden gehost door de ASP.NET Core-module.

Als u deze fout wilt oplossen, controleert u of de app gericht is op het Microsoft.AspNetCore.App framework. Controleer het .runtimeconfig.json framework waarop de app is gericht.

500.34 ANCM Gemengde hostingmodellen worden niet ondersteund

Het werkproces kan niet zowel een in-process-app als een out-of-process-app in hetzelfde proces uitvoeren.

U kunt deze fout oplossen door apps uit te voeren in afzonderlijke IIS-toepassingsgroepen.

500.35 ANCM Meerdere In-Process toepassingen in hetzelfde proces

Het werkproces kan niet meerdere in-process apps in hetzelfde proces uitvoeren.

U kunt deze fout oplossen door apps uit te voeren in afzonderlijke IIS-toepassingsgroepen.

500.36 ANCM Out-Of-Process Handler Load Failure

De out-of-process request handler, aspnetcorev2_outofprocess.dll, bevindt zich niet naast het aspnetcorev2.dll bestand. Dit geeft een beschadigde installatie van de ASP.NET Core-module aan.

U kunt deze fout oplossen door de installatie van de .NET Hosting Bundle (voor IIS) of Visual Studio (voor IIS Express) te herstellen.

500.37 ANCM kan niet worden gestart binnen de opstarttijdlimiet

ANCM kan niet worden gestart binnen de opgegeven opstarttijdlimiet. De time-out is standaard 120 seconden.

Deze fout kan optreden bij het starten van een groot aantal apps op dezelfde computer. Controleer tijdens het opstarten op pieken in het CPU-/geheugengebruik op de server. Mogelijk moet u het opstartproces van meerdere apps stagneren.

500.38 ANCM-toepassings-DLL niet gevonden

ANCM kan de DLL van de toepassing niet vinden, die naast het uitvoerbare bestand moet staan.

Deze fout treedt op bij het hosten van een app die is verpakt als uitvoerbaar bestand met één bestand met behulp van het in-process hostingmodel. Het in-process model vereist dat de ANCM de .NET-app in het bestaande IIS-proces laadt. Dit scenario wordt niet ondersteund door het implementatiemodel met één bestand. Gebruik een van de volgende benaderingen in het projectbestand van de app om deze fout op te lossen:

1. Schakel publicatie van één bestand uit door de PublishSingleFile eigenschap MSBuild in te stellen op false.
2. Schakel over naar het out-of-process hostingmodel door de AspNetCoreHostingModel eigenschap MSBuild in te stellen op OutOfProcess.

502.5 Procesfout

Het werkproces mislukt. De app wordt niet gestart.

De ASP.NET Core Module probeert het werkproces te starten, maar kan niet worden gestart. De oorzaak van een opstartfout in een proces kan meestal worden bepaald op basis van vermeldingen in het gebeurtenislogboek van de toepassing en het stdout-logboek van de ASP.NET Core Module.

Een veelvoorkomende foutvoorwaarde is dat de app onjuist is geconfigureerd vanwege een versie van het gedeelde ASP.NET Core-framework dat niet aanwezig is. Controleer welke versies van het gedeelde framework ASP.NET Core op de doelcomputer zijn geïnstalleerd. Het gedeelde framework is de set assembly's (.dll bestanden) die op de computer zijn geïnstalleerd en waarnaar wordt verwezen door een metapackage, zoals Microsoft.AspNetCore.App. De metapackage-verwijzing kan een minimaal vereiste versie opgeven. Zie Het gedeelde frameworkvoor meer informatie.

De foutpagina 502.5 Procesfout wordt geretourneerd wanneer een hosting- of app-onjuiste configuratie ervoor zorgt dat het werkproces mislukt:

Kan de toepassing niet starten (ErrorCode '0x800700c1')

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

De app kan niet worden gestart omdat de assembly van de app (.dll) niet kan worden geladen.

Deze fout treedt op wanneer er een beetje niet overeenkomt tussen de gepubliceerde app en het w3wp/iisexpress-proces.

Controleer of de 32-bits instelling van de app-pool juist is:

1. Selecteer de app-groep in de toepassingsgroepen van IIS-beheer.
2. Selecteer Geavanceerde instellingen onder Groep toepassingen bewerken in het deelvenster Acties .
3. 32-bits toepassingen instellen:
   • Als u een 32-bits app (x86) implementeert, stelt u de waarde in op True.
   • Als u een 64-bits (x64)-app implementeert, stelt u de waarde in op False.

Controleer of er geen conflict is tussen een <Platform> MSBuild-eigenschap in het projectbestand en de gepubliceerde bitness van de app.

Kan de toepassing niet starten (ErrorCode '0x800701b1')

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

De app kan niet worden gestart omdat een Windows-service niet kan worden geladen.

Een veelgebruikte service die moet worden ingeschakeld, is de 'null'-service. Met de volgende opdracht wordt de null Windows-service ingeschakeld:

sc.exe start null

Connection reset

Als er een fout optreedt nadat de headers zijn verzonden, is het te laat voor de server om een 500 interne serverfout te verzenden wanneer er een fout optreedt. Dit gebeurt vaak wanneer er een fout optreedt tijdens de serialisatie van complexe objecten voor een antwoord. Dit type fout wordt weergegeven als een verbindingsherstelfout op de client. Toepassingslogboekregistratie kan helpen bij het oplossen van deze typen fouten.

Standaard opstartlimieten

De ASP.NET Core-module is geconfigureerd met een standaard startupTimeLimit van 120 seconden. Wanneer u op de standaardwaarde blijft staan, kan het tot twee minuten duren voordat de module een procesfout registreert. Zie Kenmerken van het aspNetCore-element voor meer informatie over het configureren van de module.

Problemen oplossen in Azure App Service

Azure App Services-logboekstream

In het Logboek van Azure App Services worden logboekgegevens gestreamd terwijl deze zich voordoen. Streaminglogboeken weergeven:

1. Open de app in Azure Portal in App Services.
2. Navigeer in het linkerdeelvenster naarApp Service-logboekenbewaken>.
3. Selecteer Bestandssysteem voor webserverlogboekregistratie. Schakel eventueel toepassingslogboekregistratie in.
4. Navigeer in het linkerdeelvenster naar debewakingslogboekstream> en selecteer toepassingslogboeken of webserverlogboeken.

In de volgende afbeeldingen ziet u de uitvoer van de toepassingslogboeken:

Streaminglogboeken hebben enige latentie en worden mogelijk niet onmiddellijk weergegeven.

Gebeurtenislogboek van toepassing (Azure App Service)

Als u toegang wilt krijgen tot het gebeurtenislogboek van de toepassing, gebruikt u de blade Problemen vaststellen en oplossen in Azure Portal:

1. Open de app in Azure Portal in App Services.
2. Selecteer Problemen diagnosticeren en oplossen.
3. Selecteer de kop Diagnostische hulpprogramma's .
4. Selecteer onder Ondersteuningshulpprogramma's de knop Toepassingsevenementen .
5. Bekijk de meest recente fout die is opgegeven door de vermelding IIS AspNetCoreModule of IIS AspNetCoreModule V2 in de kolom Bron .

Een alternatief voor het gebruik van de blade Problemen vaststellen en oplossen is door het toepassingslogboekbestand rechtstreeks te onderzoeken met behulp van Kudu:

1. Open Geavanceerde hulpprogramma's in het gebied Ontwikkelhulpprogramma's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
2. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
3. Open de map LogFiles .
4. Selecteer het potloodpictogram naast het eventlog.xml bestand.
5. Bekijk het logboek. Schuif naar de onderkant van het logboek om de meest recente gebeurtenissen te bekijken.

De app uitvoeren in de Kudu-console

Veel opstartfouten produceren geen nuttige informatie in het toepassingslogboek. U kunt de app uitvoeren in de Kudu Remote Execution Console om de fout te detecteren:

1. Open Geavanceerde hulpprogramma's in het gebied Ontwikkelhulpprogramma's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
2. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.

Een 32-bits app (x86) testen

Current release

1. cd d:\home\site\wwwroot
2. Voer de app uit:

   • Als de app een frameworkafhankelijke implementatie is:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Als de app een zelfstandige implementatie is:

     {ASSEMBLY NAME}.exe
     

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

Frameworkafhankelijke implementatie die wordt uitgevoerd op een preview-versie

Hiervoor moet de site-extensie ASP.NET Core {VERSION} (x86) Runtime worden geïnstalleerd.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} is de runtimeversie)
2. Voer de app uit: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

Een 64-bits (x64)-app testen

Current release

• Als de app een 64-bits frameworkafhankelijke implementatie (x64) is:
  1. cd D:\Program Files\dotnet
  2. Voer de app uit: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Als de app een zelfstandige implementatie is:
  1. cd D:\home\site\wwwroot
  2. Voer de app uit: {ASSEMBLY NAME}.exe

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

Frameworkafhankelijke implementatie die wordt uitgevoerd op een preview-versie

Hiervoor moet de site-extensie ASP.NET Core {VERSION} (x64) Runtime worden geïnstalleerd.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} is de runtimeversie)
2. Voer de app uit: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

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

Het ASP.NET Core Module stdout-logboek registreert vaak nuttige foutberichten die niet in het gebeurtenislogboek van de toepassing worden gevonden. Stdout-logboeken inschakelen en weergeven:

1. Navigeer in Azure Portal naar de web-app.
2. Voer kudu in het zoekvak in op de blade App Service.
3. Selecteer Geavanceerde hulpprogramma's>Go.
4. Selecteer CMD voor foutopsporingsconsole>.
5. Navigeren naar site/wwwroot
6. Selecteer het potloodpictogram om het web.config bestand te bewerken.
7. <aspNetCore /> Stel het element in stdoutLogEnabled="true" en selecteer Opslaan.

Schakel stdout-logboekregistratie uit wanneer het oplossen van problemen is voltooid door de instelling in te stellen stdoutLogEnabled="false".

Zie ASP.NET Core Module (ANCM) voor IIS-voor meer informatie.

ASP.NET Core Module-foutopsporingslogboek (Azure App Service)

Het ASP.NET Core Module-foutopsporingslogboek biedt aanvullende, uitgebreidere logboekregistratie van de ASP.NET Core-module. Stdout-logboeken inschakelen en weergeven:

1. Voer een van de volgende handelingen uit om het uitgebreide diagnostische logboek in te schakelen:
   • Volg de instructies in uitgebreide diagnostische logboeken om de app te configureren voor een uitgebreide diagnostische logboekregistratie. Implementeer de app opnieuw.
   • Voeg de <handlerSettings> weergegeven diagnostische logboeken toe aan het web.config-bestand van de live-app met behulp van de Kudu-console:
     1. Open Geavanceerde hulpprogramma's in het gebied Ontwikkelhulpprogramma's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
     2. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
     3. Open de mappen naar de padsite>wwwroot. Bewerk het web.config bestand door de potloodknop te selecteren. Voeg de <handlerSettings> sectie toe zoals wordt weergegeven in uitgebreide diagnostische logboeken. Selecteer de knop Opslaan.
2. Open Geavanceerde hulpprogramma's in het gebied Ontwikkelhulpprogramma's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
3. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
4. Open de mappen naar de padsite>wwwroot. Als u geen pad hebt opgegeven voor het aspnetcore-debug.log bestand, wordt het bestand weergegeven in de lijst. Als u een pad hebt opgegeven, gaat u naar de locatie van het logboekbestand.
5. Open het logboekbestand met de potloodknop naast de bestandsnaam.

Schakel logboekregistratie voor foutopsporing uit wanneer het oplossen van problemen is voltooid:

Voer een van de volgende handelingen uit om het uitgebreide foutopsporingslogboek uit te schakelen:

• Verwijder het <handlerSettings> bestand uit het web.config lokaal en implementeer de app opnieuw.
• Gebruik de Kudu-console om het web.config bestand te bewerken en de <handlerSettings> sectie te verwijderen. Sla het bestand op.

Zie Logboek maken en omleiden met de ASP.NET Core-module voor meer informatie.

Trage of niet-reagerende app (Azure App Service)

Als een app langzaam reageert of niet reageert op een aanvraag, raadpleegt u Problemen met trage prestaties van web-apps in Azure App Service oplossen.

Monitoring blades

Bewakingsbladeën bieden een alternatieve probleemoplossingservaring voor de methoden die eerder in het onderwerp zijn beschreven. Deze blades kunnen worden gebruikt om fouten uit de 500-serie vast te stellen.

Controleer of de ASP.NET Core Extensions zijn geïnstalleerd. Als de extensies niet zijn geïnstalleerd, installeert u deze handmatig:

1. Selecteer in de blade ONTWIKKELHULPPROGRAMMA's de blade Extensies .
2. De ASP.NET Core Extensions moeten worden weergegeven in de lijst.
3. Als de extensies niet zijn geïnstalleerd, selecteert u de knop Toevoegen .
4. Kies de ASP.NET Core Extensions in de lijst.
5. Selecteer OK om de juridische voorwaarden te accepteren.
6. Selecteer OK op de blade Extensie toevoegen .
7. Een informatief pop-upbericht geeft aan wanneer de extensies zijn geïnstalleerd.

Als stdout-logboekregistratie niet is ingeschakeld, volgt u deze stappen:

1. Selecteer in Azure Portal de blade Geavanceerde hulpprogramma's in het gebied ONTWIKKELHULPPROGRAMMA's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
2. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
3. Open de mappen naar de padsite>wwwroot en schuif omlaag om het web.config bestand onder aan de lijst weer te geven.
4. Klik op het potloodpictogram naast het bestandweb.config .
5. Stel stdoutLogEnabled in en true wijzig het pad stdoutLogFile in: \\?\%home%\LogFiles\stdout.
6. Selecteer Opslaan om het bijgewerkte web.config-bestand op te slaan.

Ga verder met het activeren van diagnostische logboekregistratie:

1. Selecteer in Azure Portal de blade Diagnostische logboeken .
2. Selecteer de aan-schakelaar voor toepassingslogboekregistratie (bestandssysteem) en gedetailleerde foutberichten. Selecteer de knop Opslaan boven aan de blade.
3. Als u tracering van mislukte aanvragen wilt opnemen, ook wel freb-logboekregistratie (Failed Request Event Buffering) genoemd, selecteert u de aan-switch voor tracering van mislukte aanvragen.
4. Selecteer de blade Logboekstream , die direct wordt weergegeven onder de blade Diagnostische logboeken in de portal.
5. Een aanvraag indienen bij de app.
6. Binnen de logboekstreamgegevens wordt de oorzaak van de fout aangegeven.

Zorg ervoor dat u stdout-logboekregistratie uitschakelt wanneer het oplossen van problemen is voltooid.

De logboeken voor het traceren van mislukte aanvragen (FREB-logboeken) weergeven:

1. Navigeer naar de blade Problemen vaststellen en oplossen in Azure Portal.
2. Selecteer Logboeken voor tracering van mislukte aanvragen in het gebied ONDERSTEUNINGSHULPPROGRAMMA's van de zijbalk.

Zie de sectie Traceringen van mislukte aanvragen van het onderwerp Diagnostische logboekregistratie inschakelen voor web-apps in Azure App Service en de veelgestelde vragen over toepassingsprestaties voor Web Apps in Azure: Hoe schakel ik tracering van mislukte aanvragen in? voor meer informatie.

Zie Diagnostische logboekregistratie inschakelen voor web-apps in Azure App Service voor meer informatie.

Problemen met IIS oplossen

Toepassingslogboek (IIS)

Toegang tot het gebeurtenislogboek van de toepassing:

1. Open het menu Start, zoek Logboekvieweren selecteer de Logboekviewer app.
2. Open in Logboekenhet knooppunt Windows-logboeken.
3. Selecteer Toepassing om het gebeurtenislogboek van de toepassing te openen.
4. Zoek naar fouten die zijn gekoppeld aan de mislukte app. Fouten hebben een waarde van de IIS AspNetCore-module of IIS Express AspNetCore-module in de kolom Bron .

De app uitvoeren bij een opdrachtprompt

Veel opstartfouten produceren geen nuttige informatie in het toepassingslogboek. U kunt de oorzaak van sommige fouten vinden door de app uit te voeren via een opdrachtprompt op het hostingsysteem.

Framework-dependent deployment

Als de app een frameworkafhankelijke implementatie is:

1. Navigeer bij een opdrachtprompt naar de implementatiemap en voer de app uit door de assembly van de app uit te voeren met dotnet.exe. Vervang in de volgende opdracht de naam van de assembly van de app door <assembly_name>: dotnet .\<assembly_name>.dll.
2. De console-uitvoer van de app, met eventuele fouten, wordt naar het consolevenster geschreven.
3. Als de fouten optreden bij het indienen van een aanvraag naar de app, moet u een aanvraag indienen bij de host en poort waar Kestrel wordt geluisterd. Gebruik de standaardhost en post om een aanvraag in te http://localhost:5000/dienen. Als de app normaal op het Kestrel eindpuntadres reageert, is het probleem waarschijnlijker gerelateerd aan de hostingconfiguratie en minder waarschijnlijk binnen de app.

Self-contained deployment

Als de app een zelfstandige implementatie is:

1. Navigeer bij een opdrachtprompt naar de implementatiemap en voer het uitvoerbare bestand van de app uit. Vervang in de volgende opdracht de naam van de assembly van de app door <assembly_name>: <assembly_name>.exe.
2. De console-uitvoer van de app, met eventuele fouten, wordt naar het consolevenster geschreven.
3. Als de fouten optreden bij het indienen van een aanvraag naar de app, moet u een aanvraag indienen bij de host en poort waar Kestrel wordt geluisterd. Gebruik de standaardhost en post om een aanvraag in te http://localhost:5000/dienen. Als de app normaal op het Kestrel eindpuntadres reageert, is het probleem waarschijnlijker gerelateerd aan de hostingconfiguratie en minder waarschijnlijk binnen de app.

ASP.NET Core Module stdout-logboek (IIS)

Stdout-logboeken inschakelen en weergeven:

1. Navigeer naar de implementatiemap van de site op het hostingsysteem.
2. Als de map logboeken niet aanwezig is, maakt u de map. Zie het onderwerp Mapstructuur voor instructies over het automatisch maken van de map logboeken in de implementatie door MSBuild in te schakelen.
3. Bewerk het web.config-bestand . Stel stdoutLogEnabled in en true wijzig het pad stdoutLogFile zodat deze verwijst naar de map met logboeken (bijvoorbeeld .\logs\stdout). stdout in het pad staat het voorvoegsel voor de naam van het logboekbestand. Er wordt automatisch een tijdstempel, proces-id en bestandsextensie toegevoegd wanneer het logboek wordt gemaakt. Als stdout voorvoegsel voor de bestandsnaam wordt een typisch logboekbestand met de naam stdout_20180205184032_5412.log genoemd.
4. Zorg ervoor dat de identiteit van de groep van toepassingen schrijfmachtigingen heeft voor de map logboeken .
5. Sla het bijgewerkte web.config-bestand op.
6. Een aanvraag indienen bij de app.
7. Navigeer naar de map met logboeken . Zoek en open het meest recente stdout-logboek.
8. Onderzoek het logboek op fouten.

Schakel stdout-logboekregistratie uit wanneer het oplossen van problemen is voltooid:

1. Bewerk het web.config-bestand .
2. Stel stdoutLogEnabled in op false.
3. Sla het bestand op.

Zie ASP.NET Core Module (ANCM) voor IIS-voor meer informatie.

ASP.NET Core Module-foutopsporingslogboek (IIS)

Voeg de volgende handler-instellingen toe aan het web.config-bestand van de app om ASP.NET Core Module-foutopsporingslogboek in te schakelen:

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

Controleer of het opgegeven pad voor het logboek bestaat en of de identiteit van de app-pool schrijfmachtigingen heeft voor de locatie.

Zie Logboek maken en omleiden met de ASP.NET Core-module voor meer informatie.

De uitzonderingspagina voor ontwikkelaars inschakelen

De ASPNETCORE_ENVIRONMENTomgevingsvariabele kan worden toegevoegd aan web.config om de app uit te voeren in de ontwikkelomgeving. Zolang de omgeving niet wordt overschreven bij het opstarten van de app door UseEnvironment de hostbouwer, kan de omgevingsvariabele worden ingesteld zodat de uitzonderingspagina voor ontwikkelaars wordt weergegeven wanneer de app wordt uitgevoerd.

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

Het instellen van de omgevingsvariabele ASPNETCORE_ENVIRONMENT wordt alleen aanbevolen voor gebruik op faserings- en testservers die niet beschikbaar zijn voor internet. Verwijder de omgevingsvariabele uit het web.config-bestand na het oplossen van problemen. Zie het onderliggende element environmentVariables van aspNetCore voor informatie over het instellen van omgevingsvariabelen in web.config.

Gegevens ophalen uit een app

Als een app in staat is om te reageren op aanvragen, kunt u aanvragen, verbindingen en aanvullende gegevens van de app verkrijgen met behulp van terminal-inline-middleware. Zie Problemen oplossen en fouten opsporen ASP.NET Core-projecten voor meer informatie en voorbeeldcode.

Trage of niet-reagerende app (IIS)

Een crashdump is een momentopname van het geheugen van het systeem en kan helpen bij het bepalen van de oorzaak van een app-crash, opstartfout of trage app.

App loopt vast of ondervindt een uitzondering

Een dump verkrijgen en analyseren van Wer (Windows Error Reporting):

1. Maak een map voor het opslaan van crashdumpbestanden op c:\dumps. De app-pool moet schrijftoegang hebben tot de map.

2. Voer het PowerShell-script EnableDumps uit:

   • Als de app gebruikmaakt van het in-process hostingmodel, voert u het script uit voor w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • Als de app gebruikmaakt van het out-of-process hostingmodel, voert u het script uit voor dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Voer de app uit onder de omstandigheden die ervoor zorgen dat de crash optreedt.

4. Nadat de crash is opgetreden, voert u het DisableDumps PowerShell-script uit:

   • Als de app gebruikmaakt van het in-process hostingmodel, voert u het script uit voor w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • Als de app gebruikmaakt van het out-of-process hostingmodel, voert u het script uit voor dotnet.exe:

     .\DisableDumps dotnet.exe
     

Nadat een app vastloopt en het verzamelen van dumps is voltooid, mag de app normaal worden beëindigd. Met het PowerShell-script wordt WER geconfigureerd voor het verzamelen van maximaal vijf dumps per app.

De app reageert niet, mislukt tijdens het opstarten of wordt normaal uitgevoerd

Wanneer een app niet meer reageert, maar niet crasht, mislukt tijdens het opstarten of normaal wordt uitgevoerd, raadpleegt u User-Mode dumpbestanden: het kiezen van het beste hulpprogramma om een geschikt hulpprogramma te selecteren om de dump te produceren.

De dump analyseren

Een dump kan op verschillende manieren worden geanalyseerd. Zie Een User-Mode dumpbestand analyserenvoor meer informatie.

Caches van pakketten wissen

Een werkende app kan onmiddellijk mislukken na het upgraden van de .NET SDK op de ontwikkelcomputer of het wijzigen van pakketversies in de app. In sommige gevallen kunnen incoherent pakketten een app breken bij het uitvoeren van belangrijke upgrades. De meeste van deze problemen kunnen worden opgelost door de volgende instructies te volgen:

1. Verwijder de bin en obj-mappen.

2. Wis de pakketcaches door dotnet nuget locals all --clear vanuit een opdrachtprompt uit te voeren.

   Het wissen van pakketcaches kan ook worden uitgevoerd met het hulpprogramma nuget.exe en het uitvoeren van de opdracht nuget locals all -clear. nuget.exe is geen gebundelde installatie met het Windows-bureaubladbesturingssysteem en moet afzonderlijk worden verkregen van de NuGet-website.

3. Herstel het project en bouw het opnieuw.

4. Verwijder alle bestanden in de implementatiemap op de server voordat u de app opnieuw implementeert.

Additional resources

• Fouten opsporen in .NET en ASP.NET Core-broncode met Visual Studio
• Problemen met ASP.NET Core-projecten oplossen en fouten opsporen
• Veelvoorkomende fout oplossen voor Azure App Service en IIS met ASP.NET Core-
• fouten afhandelen in ASP.NET Core
• ASP.NET Core Module (ANCM) voor IIS-

Azure documentation

• Application Insights voor ASP.NET Core
• Sectie Web-apps voor externe foutopsporing van problemen met een web-app in Azure App Service oplossen met behulp van Visual Studio
• Overzicht van Azure App Service-diagnostiek
• Procedure: Apps bewaken in Azure App Service
• Problemen met een web-app in Azure App Service oplossen met Visual Studio
• HTTP-fouten van '502 ongeldige gateway' en '503-service niet beschikbaar' in uw Azure-web-apps oplossen
• Problemen met trage prestaties van web-apps in Azure App Service oplossen
• Veelgestelde vragen over toepassingsprestaties voor Web Apps in Azure
• Azure Web App-sandbox (uitvoeringsbeperkingen voor App Service-runtime)

Documentatie voor Visual Studio

• Externe foutopsporing ASP.NET Core in IIS in Azure in Visual Studio 2017
• Externe foutopsporing ASP.NET Core op een externe IIS-computer in Visual Studio 2017
• Meer informatie over foutopsporing met Visual Studio

Visual Studio Code-documentatie

• Foutopsporing met Visual Studio Code

Dit artikel bevat informatie over veelvoorkomende opstartfouten en instructies voor het diagnosticeren van fouten wanneer een app wordt geïmplementeerd in Azure App Service of IIS:

Opstartfouten bij app
Hierin worden veelvoorkomende scenario's met HTTP-statuscode voor opstarten uitgelegd.

Problemen oplossen in Azure App Service
Biedt advies voor probleemoplossing voor apps die zijn geïmplementeerd in Azure App Service.

Problemen met IIS oplossen
Biedt advies voor probleemoplossing voor apps die zijn geïmplementeerd in IIS of lokaal worden uitgevoerd op IIS Express. De richtlijnen zijn van toepassing op zowel Windows Server- als Windows-bureaubladimplementaties.

Pakketcaches wissen
Hierin wordt uitgelegd wat u moet doen wanneer incoherent pakketten een app breken bij het uitvoeren van belangrijke upgrades of het wijzigen van pakketversies.

Additional resources
Hier vindt u aanvullende onderwerpen over probleemoplossing.

Opstartfouten van apps

In Visual Studio wordt een ASP.NET Core-project standaard ingesteld op IIS Express-hosting tijdens foutopsporing. Een 502.5 - Procesfout of een 500.30 - Fout starten die optreedt wanneer lokaal foutopsporing kan worden vastgesteld met behulp van het advies in dit onderwerp.

403.14 Forbidden

De app kan niet worden gestart. De volgende fout wordt geregistreerd:

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

De fout wordt meestal veroorzaakt door een verbroken implementatie op het hostingsysteem, waaronder een van de volgende scenario's:

• De app wordt geïmplementeerd in de verkeerde map op het hostingsysteem.
• Het implementatieproces kan niet alle bestanden en mappen van de app verplaatsen naar de implementatiemap op het hostingsysteem.
• Het web.config bestand ontbreekt in de implementatie of de inhoud van hetweb.config bestand is onjuist.

Voer de volgende stappen uit:

1. Verwijder alle bestanden en mappen uit de implementatiemap op het hostingsysteem.
2. Implementeer de inhoud van de publicatiemap van de app opnieuw naar het hostingsysteem met behulp van uw normale implementatiemethode, zoals Visual Studio, PowerShell of handmatige implementatie:
   • Controleer of het web.config-bestand aanwezig is in de implementatie en of de inhoud juist is.
   • Wanneer u host in Azure App Service, controleert u of de app is geïmplementeerd in de D:\home\site\wwwroot map.
   • Wanneer de app wordt gehost door IIS, controleert u of de app is geïmplementeerd op het fysieke IIS-pad dat wordt weergegeven in de basisinstellingen van IIS-beheer.
3. Controleer of alle bestanden en mappen van de app zijn geïmplementeerd door de implementatie op het hostingsysteem te vergelijken met de inhoud van de publicatiemap van het project.

Zie ASP.NET Core-mapstructuur voor meer informatie over de indeling van een gepubliceerde ASP.NET Core-app. Zie ASP.NET Core Module (ANCM) voor IIS voor meer informatie over het bestandweb.config.

500 Interne Serverfout

De app wordt gestart, maar een fout voorkomt dat de server aan de aanvraag voldoet.

Deze fout treedt op in de code van de app tijdens het opstarten of tijdens het maken van een antwoord. Het antwoord bevat mogelijk geen inhoud of het antwoord kan worden weergegeven als een interne serverfout van 500 in de browser. In het toepassingslogboek wordt meestal aangegeven dat de app normaal is gestart. Dat is juist vanuit het perspectief van de server. De app is gestart, maar er kan geen geldig antwoord worden gegenereerd. Voer de app uit bij een opdrachtprompt op de server of schakel het stdout-logboek van de ASP.NET Core Module in om het probleem op te lossen.

Deze fout kan ook optreden wanneer de .NET Core Hosting Bundle niet is geïnstalleerd of beschadigd is. Het installeren of herstellen van de installatie van de .NET Core Hosting Bundle (voor IIS) of Visual Studio (voor IIS Express) kan het probleem oplossen.

500.0 In-Process Load Failure

Het werkproces mislukt. De app wordt niet gestart.

De ASP.NET Core-module kan de .NET Core CLR niet vinden en de handler voor in-procesaanvragen (aspnetcorev2_inprocess.dll) vinden. Check that:

• De app is gericht op het NuGet-pakket Microsoft.AspNetCore.Server.IIS of het Microsoft.AspNetCore.App metapackage.
• De versie van het gedeelde ASP.NET Core-framework waarop de app-doelen zijn geïnstalleerd op de doelcomputer.

500.0 Out-Of-Process Handler Load Failure

Het werkproces mislukt. De app wordt niet gestart.

De ASP.NET Core-module kan de out-of-process hosting-aanvraaghandler niet vinden. Zorg ervoor dat de aspnetcorev2_outofprocess.dll aanwezig is in een submap naast aspnetcorev2.dll.

502.5 Procesfout

Het werkproces mislukt. De app wordt niet gestart.

De ASP.NET Core Module probeert het werkproces te starten, maar kan niet worden gestart. De oorzaak van een opstartfout in een proces kan meestal worden bepaald op basis van vermeldingen in het gebeurtenislogboek van de toepassing en het stdout-logboek van de ASP.NET Core Module.

Een veelvoorkomende foutvoorwaarde is dat de app onjuist is geconfigureerd vanwege een versie van het gedeelde ASP.NET Core-framework dat niet aanwezig is. Controleer welke versies van het gedeelde framework ASP.NET Core op de doelcomputer zijn geïnstalleerd. Het gedeelde framework is de set assembly's (.dll bestanden) die op de computer zijn geïnstalleerd en waarnaar wordt verwezen door een metapackage, zoals Microsoft.AspNetCore.App. De metapackage-verwijzing kan een minimaal vereiste versie opgeven. Zie Het gedeelde frameworkvoor meer informatie.

De foutpagina 502.5 Procesfout wordt geretourneerd wanneer een hosting- of app-onjuiste configuratie ervoor zorgt dat het werkproces mislukt:

Kan de toepassing niet starten (ErrorCode '0x800700c1')

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

De app kan niet worden gestart omdat de assembly van de app (.dll) niet kan worden geladen.

Deze fout treedt op wanneer er een beetje niet overeenkomt tussen de gepubliceerde app en het w3wp/iisexpress-proces.

Controleer of de 32-bits instelling van de app-pool juist is:

1. Selecteer de app-groep in de toepassingsgroepen van IIS-beheer.
2. Selecteer Geavanceerde instellingen onder Groep toepassingen bewerken in het deelvenster Acties .
3. 32-bits toepassingen instellen:
   • Als u een 32-bits app (x86) implementeert, stelt u de waarde in op True.
   • Als u een 64-bits (x64)-app implementeert, stelt u de waarde in op False.

Controleer of er geen conflict is tussen een <Platform> MSBuild-eigenschap in het projectbestand en de gepubliceerde bitness van de app.

Connection reset

Als er een fout optreedt nadat de headers zijn verzonden, is het te laat voor de server om een 500 interne serverfout te verzenden wanneer er een fout optreedt. Dit gebeurt vaak wanneer er een fout optreedt tijdens de serialisatie van complexe objecten voor een antwoord. Dit type fout wordt weergegeven als een verbindingsherstelfout op de client. Toepassingslogboekregistratie kan helpen bij het oplossen van deze typen fouten.

Standaard opstartlimieten

De ASP.NET Core-module is geconfigureerd met een standaard startupTimeLimit van 120 seconden. Wanneer u op de standaardwaarde blijft staan, kan het tot twee minuten duren voordat de module een procesfout registreert. Zie Kenmerken van het aspNetCore-element voor meer informatie over het configureren van de module.

Problemen oplossen in Azure App Service

Gebeurtenislogboek van toepassing (Azure App Service)

Als u toegang wilt krijgen tot het gebeurtenislogboek van de toepassing, gebruikt u de blade Problemen vaststellen en oplossen in Azure Portal:

1. Open de app in Azure Portal in App Services.
2. Selecteer Problemen diagnosticeren en oplossen.
3. Selecteer de kop Diagnostische hulpprogramma's .
4. Selecteer onder Ondersteuningshulpprogramma's de knop Toepassingsevenementen .
5. Bekijk de meest recente fout die is opgegeven door de vermelding IIS AspNetCoreModule of IIS AspNetCoreModule V2 in de kolom Bron .

Een alternatief voor het gebruik van de blade Problemen vaststellen en oplossen is door het toepassingslogboekbestand rechtstreeks te onderzoeken met behulp van Kudu:

1. Open Geavanceerde hulpprogramma's in het gebied Ontwikkelhulpprogramma's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
2. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
3. Open de map LogFiles .
4. Selecteer het potloodpictogram naast het eventlog.xml bestand.
5. Bekijk het logboek. Schuif naar de onderkant van het logboek om de meest recente gebeurtenissen te bekijken.

De app uitvoeren in de Kudu-console

Veel opstartfouten produceren geen nuttige informatie in het toepassingslogboek. U kunt de app uitvoeren in de Kudu Remote Execution Console om de fout te detecteren:

1. Open Geavanceerde hulpprogramma's in het gebied Ontwikkelhulpprogramma's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
2. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.

Een 32-bits app (x86) testen

Current release

1. cd d:\home\site\wwwroot
2. Voer de app uit:

   • Als de app een frameworkafhankelijke implementatie is:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Als de app een zelfstandige implementatie is:

     {ASSEMBLY NAME}.exe
     

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

Frameworkafhankelijke implementatie die wordt uitgevoerd op een preview-versie

Hiervoor moet de site-extensie ASP.NET Core {VERSION} (x86) Runtime worden geïnstalleerd.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} is de runtimeversie)
2. Voer de app uit: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

Een 64-bits (x64)-app testen

Current release

• Als de app een 64-bits frameworkafhankelijke implementatie (x64) is:
  1. cd D:\Program Files\dotnet
  2. Voer de app uit: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Als de app een zelfstandige implementatie is:
  1. cd D:\home\site\wwwroot
  2. Voer de app uit: {ASSEMBLY NAME}.exe

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

Frameworkafhankelijke implementatie die wordt uitgevoerd op een preview-versie

Hiervoor moet de site-extensie ASP.NET Core {VERSION} (x64) Runtime worden geïnstalleerd.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} is de runtimeversie)
2. Voer de app uit: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

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

Het ASP.NET Core Module stdout-logboek registreert vaak nuttige foutberichten die niet in het gebeurtenislogboek van de toepassing worden gevonden. Stdout-logboeken inschakelen en weergeven:

1. Navigeer naar de blade Problemen vaststellen en oplossen in Azure Portal.
2. Selecteer onder SELECT PROBLEM CATEGORY de knop Web App Down .
3. Selecteer onder Voorgestelde oplossingen>Stdout-logboekomleiding de knop om Kudu-console te openen om Web.Config te bewerken.
4. Open in de Diagnostische Kudu-console de mappen naar de padsite>wwwroot. Schuif omlaag om het web.config bestand onder aan de lijst weer te geven.
5. Klik op het potloodpictogram naast het bestandweb.config .
6. Stel stdoutLogEnabled in en true wijzig het pad stdoutLogFile in: \\?\%home%\LogFiles\stdout.
7. Selecteer Opslaan om het bijgewerkte web.config-bestand op te slaan.
8. Een aanvraag indienen bij de app.
9. Ga terug naar Azure Portal. Selecteer de blade Geavanceerde hulpprogramma's in het gebied ONTWIKKELHULPPROGRAMMA's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
10. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
11. Selecteer de map LogFiles .
12. Inspecteer de kolom Gewijzigd en selecteer het potloodpictogram om het stdout-logboek te bewerken met de laatste wijzigingsdatum.
13. Wanneer het logboekbestand wordt geopend, wordt de fout weergegeven.

Schakel stdout-logboekregistratie uit wanneer het oplossen van problemen is voltooid:

1. Ga in de Diagnostische Kudu-console terug naar de padsite>wwwroot om het web.config bestand weer te geven. Open het web.config bestand opnieuw door het potloodpictogram te selecteren.
2. Stel stdoutLogEnabled in op false.
3. Selecteer Opslaan om het bestand op te slaan.

Zie ASP.NET Core Module (ANCM) voor IIS-voor meer informatie.

ASP.NET Core Module-foutopsporingslogboek (Azure App Service)

Het ASP.NET Core Module-foutopsporingslogboek biedt aanvullende, uitgebreidere logboekregistratie van de ASP.NET Core-module. Stdout-logboeken inschakelen en weergeven:

1. Voer een van de volgende handelingen uit om het uitgebreide diagnostische logboek in te schakelen:
   • Volg de instructies in uitgebreide diagnostische logboeken om de app te configureren voor een uitgebreide diagnostische logboekregistratie. Implementeer de app opnieuw.
   • Voeg de <handlerSettings> weergegeven diagnostische logboeken toe aan het web.config-bestand van de live-app met behulp van de Kudu-console:
     1. Open Geavanceerde hulpprogramma's in het gebied Ontwikkelhulpprogramma's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
     2. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
     3. Open de mappen naar de padsite>wwwroot. Bewerk het web.config bestand door de potloodknop te selecteren. Voeg de <handlerSettings> sectie toe zoals wordt weergegeven in uitgebreide diagnostische logboeken. Selecteer de knop Opslaan.
2. Open Geavanceerde hulpprogramma's in het gebied Ontwikkelhulpprogramma's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
3. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
4. Open de mappen naar de padsite>wwwroot. Als u geen pad hebt opgegeven voor het aspnetcore-debug.log bestand, wordt het bestand weergegeven in de lijst. Als u een pad hebt opgegeven, gaat u naar de locatie van het logboekbestand.
5. Open het logboekbestand met de potloodknop naast de bestandsnaam.

Schakel logboekregistratie voor foutopsporing uit wanneer het oplossen van problemen is voltooid:

Voer een van de volgende handelingen uit om het uitgebreide foutopsporingslogboek uit te schakelen:

• Verwijder het <handlerSettings> bestand uit het web.config lokaal en implementeer de app opnieuw.
• Gebruik de Kudu-console om het web.config bestand te bewerken en de <handlerSettings> sectie te verwijderen. Sla het bestand op.

Zie Logboek maken en omleiden met de ASP.NET Core-module voor meer informatie.

Trage of niet-reagerende app (Azure App Service)

Als een app langzaam reageert of niet reageert op een aanvraag, raadpleegt u de volgende artikelen:

• Problemen met trage prestaties van web-apps in Azure App Service oplossen
• Crash Diagnoser-site-extensie gebruiken om dump vast te leggen voor onregelmatige uitzonderingsproblemen of prestatieproblemen in Azure Web App

Monitoring blades

Bewakingsbladeën bieden een alternatieve probleemoplossingservaring voor de methoden die eerder in het onderwerp zijn beschreven. Deze blades kunnen worden gebruikt om fouten uit de 500-serie vast te stellen.

Controleer of de ASP.NET Core Extensions zijn geïnstalleerd. Als de extensies niet zijn geïnstalleerd, installeert u deze handmatig:

1. Selecteer in de blade ONTWIKKELHULPPROGRAMMA's de blade Extensies .
2. De ASP.NET Core Extensions moeten worden weergegeven in de lijst.
3. Als de extensies niet zijn geïnstalleerd, selecteert u de knop Toevoegen .
4. Kies de ASP.NET Core Extensions in de lijst.
5. Selecteer OK om de juridische voorwaarden te accepteren.
6. Selecteer OK op de blade Extensie toevoegen .
7. Een informatief pop-upbericht geeft aan wanneer de extensies zijn geïnstalleerd.

Als stdout-logboekregistratie niet is ingeschakeld, volgt u deze stappen:

1. Selecteer in Azure Portal de blade Geavanceerde hulpprogramma's in het gebied ONTWIKKELHULPPROGRAMMA's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
2. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
3. Open de mappen naar de padsite>wwwroot en schuif omlaag om het web.config bestand onder aan de lijst weer te geven.
4. Klik op het potloodpictogram naast het bestandweb.config .
5. Stel stdoutLogEnabled in en true wijzig het pad stdoutLogFile in: \\?\%home%\LogFiles\stdout.
6. Selecteer Opslaan om het bijgewerkte web.config-bestand op te slaan.

Ga verder met het activeren van diagnostische logboekregistratie:

1. Selecteer in Azure Portal de blade Diagnostische logboeken .
2. Selecteer de aan-schakelaar voor toepassingslogboekregistratie (bestandssysteem) en gedetailleerde foutberichten. Selecteer de knop Opslaan boven aan de blade.
3. Als u tracering van mislukte aanvragen wilt opnemen, ook wel freb-logboekregistratie (Failed Request Event Buffering) genoemd, selecteert u de aan-switch voor tracering van mislukte aanvragen.
4. Selecteer de blade Logboekstream , die direct wordt weergegeven onder de blade Diagnostische logboeken in de portal.
5. Een aanvraag indienen bij de app.
6. Binnen de logboekstreamgegevens wordt de oorzaak van de fout aangegeven.

Zorg ervoor dat u stdout-logboekregistratie uitschakelt wanneer het oplossen van problemen is voltooid.

De logboeken voor het traceren van mislukte aanvragen (FREB-logboeken) weergeven:

1. Navigeer naar de blade Problemen vaststellen en oplossen in Azure Portal.
2. Selecteer Logboeken voor tracering van mislukte aanvragen in het gebied ONDERSTEUNINGSHULPPROGRAMMA's van de zijbalk.

Zie de sectie Traceringen van mislukte aanvragen van het onderwerp Diagnostische logboekregistratie inschakelen voor web-apps in Azure App Service en de veelgestelde vragen over toepassingsprestaties voor Web Apps in Azure: Hoe schakel ik tracering van mislukte aanvragen in? voor meer informatie.

Zie Diagnostische logboekregistratie inschakelen voor web-apps in Azure App Service voor meer informatie.

Problemen met IIS oplossen

Toepassingslogboek (IIS)

Toegang tot het gebeurtenislogboek van de toepassing:

1. Open het menu Start, zoek Logboekvieweren selecteer de Logboekviewer app.
2. Open in Logboekenhet knooppunt Windows-logboeken.
3. Selecteer Toepassing om het gebeurtenislogboek van de toepassing te openen.
4. Zoek naar fouten die zijn gekoppeld aan de mislukte app. Fouten hebben een waarde van de IIS AspNetCore-module of IIS Express AspNetCore-module in de kolom Bron .

De app uitvoeren bij een opdrachtprompt

Veel opstartfouten produceren geen nuttige informatie in het toepassingslogboek. U kunt de oorzaak van sommige fouten vinden door de app uit te voeren via een opdrachtprompt op het hostingsysteem.

Framework-dependent deployment

Als de app een frameworkafhankelijke implementatie is:

1. Navigeer bij een opdrachtprompt naar de implementatiemap en voer de app uit door de assembly van de app uit te voeren met dotnet.exe. Vervang in de volgende opdracht de naam van de assembly van de app door <assembly_name>: dotnet .\<assembly_name>.dll.
2. De console-uitvoer van de app, met eventuele fouten, wordt naar het consolevenster geschreven.
3. Als de fouten optreden bij het indienen van een aanvraag naar de app, moet u een aanvraag indienen bij de host en poort waar Kestrel wordt geluisterd. Gebruik de standaardhost en post om een aanvraag in te http://localhost:5000/dienen. Als de app normaal op het Kestrel eindpuntadres reageert, is het probleem waarschijnlijker gerelateerd aan de hostingconfiguratie en minder waarschijnlijk binnen de app.

Self-contained deployment

Als de app een zelfstandige implementatie is:

1. Navigeer bij een opdrachtprompt naar de implementatiemap en voer het uitvoerbare bestand van de app uit. Vervang in de volgende opdracht de naam van de assembly van de app door <assembly_name>: <assembly_name>.exe.
2. De console-uitvoer van de app, met eventuele fouten, wordt naar het consolevenster geschreven.
3. Als de fouten optreden bij het indienen van een aanvraag naar de app, moet u een aanvraag indienen bij de host en poort waar Kestrel wordt geluisterd. Gebruik de standaardhost en post om een aanvraag in te http://localhost:5000/dienen. Als de app normaal op het Kestrel eindpuntadres reageert, is het probleem waarschijnlijker gerelateerd aan de hostingconfiguratie en minder waarschijnlijk binnen de app.

ASP.NET Core Module stdout-logboek (IIS)

Stdout-logboeken inschakelen en weergeven:

1. Navigeer naar de implementatiemap van de site op het hostingsysteem.
2. Als de map logboeken niet aanwezig is, maakt u de map. Zie het onderwerp Mapstructuur voor instructies over het automatisch maken van de map logboeken in de implementatie door MSBuild in te schakelen.
3. Bewerk het web.config-bestand . Stel stdoutLogEnabled in en true wijzig het pad stdoutLogFile zodat deze verwijst naar de map met logboeken (bijvoorbeeld .\logs\stdout). stdout in het pad staat het voorvoegsel voor de naam van het logboekbestand. Er wordt automatisch een tijdstempel, proces-id en bestandsextensie toegevoegd wanneer het logboek wordt gemaakt. Als stdout voorvoegsel voor de bestandsnaam wordt een typisch logboekbestand met de naam stdout_20180205184032_5412.log genoemd.
4. Zorg ervoor dat de identiteit van de groep van toepassingen schrijfmachtigingen heeft voor de map logboeken .
5. Sla het bijgewerkte web.config-bestand op.
6. Een aanvraag indienen bij de app.
7. Navigeer naar de map met logboeken . Zoek en open het meest recente stdout-logboek.
8. Onderzoek het logboek op fouten.

Schakel stdout-logboekregistratie uit wanneer het oplossen van problemen is voltooid:

1. Bewerk het web.config-bestand .
2. Stel stdoutLogEnabled in op false.
3. Sla het bestand op.

Zie ASP.NET Core Module (ANCM) voor IIS-voor meer informatie.

ASP.NET Core Module-foutopsporingslogboek (IIS)

Voeg de volgende handler-instellingen toe aan het web.config-bestand van de app om ASP.NET Core Module-foutopsporingslogboek in te schakelen:

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

Controleer of het opgegeven pad voor het logboek bestaat en of de identiteit van de app-pool schrijfmachtigingen heeft voor de locatie.

Zie Logboek maken en omleiden met de ASP.NET Core-module voor meer informatie.

De uitzonderingspagina voor ontwikkelaars inschakelen

De ASPNETCORE_ENVIRONMENTomgevingsvariabele kan worden toegevoegd aan web.config om de app uit te voeren in de ontwikkelomgeving. Zolang de omgeving niet wordt overschreven bij het opstarten van de app door UseEnvironment de hostbouwer, kan de omgevingsvariabele worden ingesteld zodat de uitzonderingspagina voor ontwikkelaars wordt weergegeven wanneer de app wordt uitgevoerd.

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

Het instellen van de omgevingsvariabele ASPNETCORE_ENVIRONMENT wordt alleen aanbevolen voor gebruik op faserings- en testservers die niet beschikbaar zijn voor internet. Verwijder de omgevingsvariabele uit het web.config-bestand na het oplossen van problemen. Zie het onderliggende element environmentVariables van aspNetCore voor informatie over het instellen van omgevingsvariabelen in web.config.

Gegevens ophalen uit een app

Als een app in staat is om te reageren op aanvragen, kunt u aanvragen, verbindingen en aanvullende gegevens van de app verkrijgen met behulp van terminal-inline-middleware. Zie Problemen oplossen en fouten opsporen ASP.NET Core-projecten voor meer informatie en voorbeeldcode.

Trage of niet-reagerende app (IIS)

Een crashdump is een momentopname van het geheugen van het systeem en kan helpen bij het bepalen van de oorzaak van een app-crash, opstartfout of trage app.

App loopt vast of ondervindt een uitzondering

Een dump verkrijgen en analyseren van Wer (Windows Error Reporting):

1. Maak een map voor het opslaan van crashdumpbestanden op c:\dumps. De app-pool moet schrijftoegang hebben tot de map.

2. Voer het PowerShell-script EnableDumps uit:

   • Als de app gebruikmaakt van het in-process hostingmodel, voert u het script uit voor w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • Als de app gebruikmaakt van het out-of-process hostingmodel, voert u het script uit voor dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Voer de app uit onder de omstandigheden die ervoor zorgen dat de crash optreedt.

4. Nadat de crash is opgetreden, voert u het DisableDumps PowerShell-script uit:

   • Als de app gebruikmaakt van het in-process hostingmodel, voert u het script uit voor w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • Als de app gebruikmaakt van het out-of-process hostingmodel, voert u het script uit voor dotnet.exe:

     .\DisableDumps dotnet.exe
     

Nadat een app vastloopt en het verzamelen van dumps is voltooid, mag de app normaal worden beëindigd. Met het PowerShell-script wordt WER geconfigureerd voor het verzamelen van maximaal vijf dumps per app.

De app reageert niet, mislukt tijdens het opstarten of wordt normaal uitgevoerd

Wanneer een app niet meer reageert, maar niet crasht, mislukt tijdens het opstarten of normaal wordt uitgevoerd, raadpleegt u User-Mode dumpbestanden: het kiezen van het beste hulpprogramma om een geschikt hulpprogramma te selecteren om de dump te produceren.

De dump analyseren

Een dump kan op verschillende manieren worden geanalyseerd. Zie Een User-Mode dumpbestand analyserenvoor meer informatie.

Caches van pakketten wissen

Een werkende app kan onmiddellijk mislukken na het upgraden van de .NET Core SDK op de ontwikkelcomputer of het wijzigen van pakketversies in de app. In sommige gevallen kunnen incoherent pakketten een app breken bij het uitvoeren van belangrijke upgrades. De meeste van deze problemen kunnen worden opgelost door de volgende instructies te volgen:

1. Verwijder de bin en obj-mappen.

2. Wis de pakketcaches door dotnet nuget locals all --clear vanuit een opdrachtprompt uit te voeren.

   Het wissen van pakketcaches kan ook worden uitgevoerd met het hulpprogramma nuget.exe en het uitvoeren van de opdracht nuget locals all -clear. nuget.exe is geen gebundelde installatie met het Windows-bureaubladbesturingssysteem en moet afzonderlijk worden verkregen van de NuGet-website.

3. Herstel het project en bouw het opnieuw.

4. Verwijder alle bestanden in de implementatiemap op de server voordat u de app opnieuw implementeert.

Additional resources

• Problemen met ASP.NET Core-projecten oplossen en fouten opsporen
• Veelvoorkomende fout oplossen voor Azure App Service en IIS met ASP.NET Core-
• fouten afhandelen in ASP.NET Core
• ASP.NET Core Module (ANCM) voor IIS-

Azure documentation

• Application Insights voor ASP.NET Core
• Sectie Web-apps voor externe foutopsporing van problemen met een web-app in Azure App Service oplossen met behulp van Visual Studio
• Overzicht van Azure App Service-diagnostiek
• Procedure: Apps bewaken in Azure App Service
• Problemen met een web-app in Azure App Service oplossen met Visual Studio
• HTTP-fouten van '502 ongeldige gateway' en '503-service niet beschikbaar' in uw Azure-web-apps oplossen
• Problemen met trage prestaties van web-apps in Azure App Service oplossen
• Veelgestelde vragen over toepassingsprestaties voor Web Apps in Azure
• Azure Web App-sandbox (uitvoeringsbeperkingen voor App Service-runtime)

Documentatie voor Visual Studio

• Externe foutopsporing ASP.NET Core in IIS in Azure in Visual Studio 2017
• Externe foutopsporing ASP.NET Core op een externe IIS-computer in Visual Studio 2017
• Meer informatie over foutopsporing met Visual Studio

Visual Studio Code-documentatie

• Foutopsporing met Visual Studio Code

Dit artikel bevat informatie over veelvoorkomende opstartfouten en instructies voor het diagnosticeren van fouten wanneer een app wordt geïmplementeerd in Azure App Service of IIS:

Opstartfouten bij app
Hierin worden veelvoorkomende scenario's met HTTP-statuscode voor opstarten uitgelegd.

Problemen oplossen in Azure App Service
Biedt advies voor probleemoplossing voor apps die zijn geïmplementeerd in Azure App Service.

Problemen met IIS oplossen
Biedt advies voor probleemoplossing voor apps die zijn geïmplementeerd in IIS of lokaal worden uitgevoerd op IIS Express. De richtlijnen zijn van toepassing op zowel Windows Server- als Windows-bureaubladimplementaties.

Pakketcaches wissen
Hierin wordt uitgelegd wat u moet doen wanneer incoherent pakketten een app breken bij het uitvoeren van belangrijke upgrades of het wijzigen van pakketversies.

Additional resources
Hier vindt u aanvullende onderwerpen over probleemoplossing.

Opstartfouten van apps

In Visual Studio wordt een ASP.NET Core-project standaard ingesteld op IIS Express-hosting tijdens foutopsporing. Een 502.5-procesfout die optreedt wanneer lokaal foutopsporing kan worden vastgesteld met behulp van het advies in dit onderwerp.

403.14 Forbidden

De app kan niet worden gestart. De volgende fout wordt geregistreerd:

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

De fout wordt meestal veroorzaakt door een verbroken implementatie op het hostingsysteem, waaronder een van de volgende scenario's:

• De app wordt geïmplementeerd in de verkeerde map op het hostingsysteem.
• Het implementatieproces kan niet alle bestanden en mappen van de app verplaatsen naar de implementatiemap op het hostingsysteem.
• Het web.config bestand ontbreekt in de implementatie of de inhoud van hetweb.config bestand is onjuist.

Voer de volgende stappen uit:

1. Verwijder alle bestanden en mappen uit de implementatiemap op het hostingsysteem.
2. Implementeer de inhoud van de publicatiemap van de app opnieuw naar het hostingsysteem met behulp van uw normale implementatiemethode, zoals Visual Studio, PowerShell of handmatige implementatie:
   • Controleer of het web.config-bestand aanwezig is in de implementatie en of de inhoud juist is.
   • Wanneer u host in Azure App Service, controleert u of de app is geïmplementeerd in de D:\home\site\wwwroot map.
   • Wanneer de app wordt gehost door IIS, controleert u of de app is geïmplementeerd op het fysieke IIS-pad dat wordt weergegeven in de basisinstellingen van IIS-beheer.
3. Controleer of alle bestanden en mappen van de app zijn geïmplementeerd door de implementatie op het hostingsysteem te vergelijken met de inhoud van de publicatiemap van het project.

Zie ASP.NET Core-mapstructuur voor meer informatie over de indeling van een gepubliceerde ASP.NET Core-app. Zie ASP.NET Core Module (ANCM) voor IIS voor meer informatie over het bestandweb.config.

500 Interne Serverfout

De app wordt gestart, maar een fout voorkomt dat de server aan de aanvraag voldoet.

Deze fout treedt op in de code van de app tijdens het opstarten of tijdens het maken van een antwoord. Het antwoord bevat mogelijk geen inhoud of het antwoord kan worden weergegeven als een interne serverfout van 500 in de browser. In het toepassingslogboek wordt meestal aangegeven dat de app normaal is gestart. Dat is juist vanuit het perspectief van de server. De app is gestart, maar er kan geen geldig antwoord worden gegenereerd. Voer de app uit bij een opdrachtprompt op de server of schakel het stdout-logboek van de ASP.NET Core Module in om het probleem op te lossen.

Deze fout kan ook optreden wanneer de .NET Core Hosting Bundle niet is geïnstalleerd of beschadigd is. Het installeren of herstellen van de installatie van de .NET Core Hosting Bundle (voor IIS) of Visual Studio (voor IIS Express) kan het probleem oplossen.

502.5 Procesfout

Het werkproces mislukt. De app wordt niet gestart.

De ASP.NET Core Module probeert het werkproces te starten, maar kan niet worden gestart. De oorzaak van een opstartfout in een proces kan meestal worden bepaald op basis van vermeldingen in het gebeurtenislogboek van de toepassing en het stdout-logboek van de ASP.NET Core Module.

Een veelvoorkomende foutvoorwaarde is dat de app onjuist is geconfigureerd vanwege een versie van het gedeelde ASP.NET Core-framework dat niet aanwezig is. Controleer welke versies van het gedeelde framework ASP.NET Core op de doelcomputer zijn geïnstalleerd. Het gedeelde framework is de set assembly's (.dll bestanden) die op de computer zijn geïnstalleerd en waarnaar wordt verwezen door een metapackage, zoals Microsoft.AspNetCore.App. De metapackage-verwijzing kan een minimaal vereiste versie opgeven. Zie Het gedeelde frameworkvoor meer informatie.

De foutpagina 502.5 Procesfout wordt geretourneerd wanneer een hosting- of app-onjuiste configuratie ervoor zorgt dat het werkproces mislukt:

Kan de toepassing niet starten (ErrorCode '0x800700c1')

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

De app kan niet worden gestart omdat de assembly van de app (.dll) niet kan worden geladen.

Deze fout treedt op wanneer er een beetje niet overeenkomt tussen de gepubliceerde app en het w3wp/iisexpress-proces.

Controleer of de 32-bits instelling van de app-pool juist is:

1. Selecteer de app-groep in de toepassingsgroepen van IIS-beheer.
2. Selecteer Geavanceerde instellingen onder Groep toepassingen bewerken in het deelvenster Acties .
3. 32-bits toepassingen instellen:
   • Als u een 32-bits app (x86) implementeert, stelt u de waarde in op True.
   • Als u een 64-bits (x64)-app implementeert, stelt u de waarde in op False.

Controleer of er geen conflict is tussen een <Platform> MSBuild-eigenschap in het projectbestand en de gepubliceerde bitness van de app.

Connection reset

Als er een fout optreedt nadat de headers zijn verzonden, is het te laat voor de server om een 500 interne serverfout te verzenden wanneer er een fout optreedt. Dit gebeurt vaak wanneer er een fout optreedt tijdens de serialisatie van complexe objecten voor een antwoord. Dit type fout wordt weergegeven als een verbindingsherstelfout op de client. Toepassingslogboekregistratie kan helpen bij het oplossen van deze typen fouten.

Standaard opstartlimieten

De ASP.NET Core-module is geconfigureerd met een standaard startupTimeLimit van 120 seconden. Wanneer u op de standaardwaarde blijft staan, kan het tot twee minuten duren voordat de module een procesfout registreert. Zie Kenmerken van het aspNetCore-element voor meer informatie over het configureren van de module.

Problemen oplossen in Azure App Service

Gebeurtenislogboek van toepassing (Azure App Service)

Als u toegang wilt krijgen tot het gebeurtenislogboek van de toepassing, gebruikt u de blade Problemen vaststellen en oplossen in Azure Portal:

1. Open de app in Azure Portal in App Services.
2. Selecteer Problemen diagnosticeren en oplossen.
3. Selecteer de kop Diagnostische hulpprogramma's .
4. Selecteer onder Ondersteuningshulpprogramma's de knop Toepassingsevenementen .
5. Bekijk de meest recente fout die is opgegeven door de vermelding IIS AspNetCoreModule of IIS AspNetCoreModule V2 in de kolom Bron .

Een alternatief voor het gebruik van de blade Problemen vaststellen en oplossen is door het toepassingslogboekbestand rechtstreeks te onderzoeken met behulp van Kudu:

1. Open Geavanceerde hulpprogramma's in het gebied Ontwikkelhulpprogramma's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
2. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
3. Open de map LogFiles .
4. Selecteer het potloodpictogram naast het eventlog.xml bestand.
5. Bekijk het logboek. Schuif naar de onderkant van het logboek om de meest recente gebeurtenissen te bekijken.

De app uitvoeren in de Kudu-console

Veel opstartfouten produceren geen nuttige informatie in het toepassingslogboek. U kunt de app uitvoeren in de Kudu Remote Execution Console om de fout te detecteren:

1. Open Geavanceerde hulpprogramma's in het gebied Ontwikkelhulpprogramma's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
2. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.

Een 32-bits app (x86) testen

Current release

1. cd d:\home\site\wwwroot
2. Voer de app uit:

   • Als de app een frameworkafhankelijke implementatie is:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Als de app een zelfstandige implementatie is:

     {ASSEMBLY NAME}.exe
     

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

Frameworkafhankelijke implementatie die wordt uitgevoerd op een preview-versie

Hiervoor moet de site-extensie ASP.NET Core {VERSION} (x86) Runtime worden geïnstalleerd.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} is de runtimeversie)
2. Voer de app uit: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

Een 64-bits (x64)-app testen

Current release

• Als de app een 64-bits frameworkafhankelijke implementatie (x64) is:
  1. cd D:\Program Files\dotnet
  2. Voer de app uit: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Als de app een zelfstandige implementatie is:
  1. cd D:\home\site\wwwroot
  2. Voer de app uit: {ASSEMBLY NAME}.exe

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

Frameworkafhankelijke implementatie die wordt uitgevoerd op een preview-versie

Hiervoor moet de site-extensie ASP.NET Core {VERSION} (x64) Runtime worden geïnstalleerd.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} is de runtimeversie)
2. Voer de app uit: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

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

Het ASP.NET Core Module stdout-logboek registreert vaak nuttige foutberichten die niet in het gebeurtenislogboek van de toepassing worden gevonden. Stdout-logboeken inschakelen en weergeven:

1. Navigeer naar de blade Problemen vaststellen en oplossen in Azure Portal.
2. Selecteer onder SELECT PROBLEM CATEGORY de knop Web App Down .
3. Selecteer onder Voorgestelde oplossingen>Stdout-logboekomleiding de knop om Kudu-console te openen om Web.Config te bewerken.
4. Open in de Diagnostische Kudu-console de mappen naar de padsite>wwwroot. Schuif omlaag om het web.config bestand onder aan de lijst weer te geven.
5. Klik op het potloodpictogram naast het bestandweb.config .
6. Stel stdoutLogEnabled in en true wijzig het pad stdoutLogFile in: \\?\%home%\LogFiles\stdout.
7. Selecteer Opslaan om het bijgewerkte web.config-bestand op te slaan.
8. Een aanvraag indienen bij de app.
9. Ga terug naar Azure Portal. Selecteer de blade Geavanceerde hulpprogramma's in het gebied ONTWIKKELHULPPROGRAMMA's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
10. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
11. Selecteer de map LogFiles .
12. Inspecteer de kolom Gewijzigd en selecteer het potloodpictogram om het stdout-logboek te bewerken met de laatste wijzigingsdatum.
13. Wanneer het logboekbestand wordt geopend, wordt de fout weergegeven.

Schakel stdout-logboekregistratie uit wanneer het oplossen van problemen is voltooid:

1. Ga in de Diagnostische Kudu-console terug naar de padsite>wwwroot om het web.config bestand weer te geven. Open het web.config bestand opnieuw door het potloodpictogram te selecteren.
2. Stel stdoutLogEnabled in op false.
3. Selecteer Opslaan om het bestand op te slaan.

Zie ASP.NET Core Module (ANCM) voor IIS-voor meer informatie.

Trage of niet-reagerende app (Azure App Service)

Als een app langzaam reageert of niet reageert op een aanvraag, raadpleegt u de volgende artikelen:

• Problemen met trage prestaties van web-apps in Azure App Service oplossen
• Crash Diagnoser-site-extensie gebruiken om dump vast te leggen voor onregelmatige uitzonderingsproblemen of prestatieproblemen in Azure Web App

Monitoring blades

Bewakingsbladeën bieden een alternatieve probleemoplossingservaring voor de methoden die eerder in het onderwerp zijn beschreven. Deze blades kunnen worden gebruikt om fouten uit de 500-serie vast te stellen.

Controleer of de ASP.NET Core Extensions zijn geïnstalleerd. Als de extensies niet zijn geïnstalleerd, installeert u deze handmatig:

1. Selecteer in de blade ONTWIKKELHULPPROGRAMMA's de blade Extensies .
2. De ASP.NET Core Extensions moeten worden weergegeven in de lijst.
3. Als de extensies niet zijn geïnstalleerd, selecteert u de knop Toevoegen .
4. Kies de ASP.NET Core Extensions in de lijst.
5. Selecteer OK om de juridische voorwaarden te accepteren.
6. Selecteer OK op de blade Extensie toevoegen .
7. Een informatief pop-upbericht geeft aan wanneer de extensies zijn geïnstalleerd.

Als stdout-logboekregistratie niet is ingeschakeld, volgt u deze stappen:

1. Selecteer in Azure Portal de blade Geavanceerde hulpprogramma's in het gebied ONTWIKKELHULPPROGRAMMA's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
2. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
3. Open de mappen naar de padsite>wwwroot en schuif omlaag om het web.config bestand onder aan de lijst weer te geven.
4. Klik op het potloodpictogram naast het bestandweb.config .
5. Stel stdoutLogEnabled in en true wijzig het pad stdoutLogFile in: \\?\%home%\LogFiles\stdout.
6. Selecteer Opslaan om het bijgewerkte web.config-bestand op te slaan.

Ga verder met het activeren van diagnostische logboekregistratie:

1. Selecteer in Azure Portal de blade Diagnostische logboeken .
2. Selecteer de aan-schakelaar voor toepassingslogboekregistratie (bestandssysteem) en gedetailleerde foutberichten. Selecteer de knop Opslaan boven aan de blade.
3. Als u tracering van mislukte aanvragen wilt opnemen, ook wel freb-logboekregistratie (Failed Request Event Buffering) genoemd, selecteert u de aan-switch voor tracering van mislukte aanvragen.
4. Selecteer de blade Logboekstream , die direct wordt weergegeven onder de blade Diagnostische logboeken in de portal.
5. Een aanvraag indienen bij de app.
6. Binnen de logboekstreamgegevens wordt de oorzaak van de fout aangegeven.

Zorg ervoor dat u stdout-logboekregistratie uitschakelt wanneer het oplossen van problemen is voltooid.

De logboeken voor het traceren van mislukte aanvragen (FREB-logboeken) weergeven:

1. Navigeer naar de blade Problemen vaststellen en oplossen in Azure Portal.
2. Selecteer Logboeken voor tracering van mislukte aanvragen in het gebied ONDERSTEUNINGSHULPPROGRAMMA's van de zijbalk.

Zie de sectie Traceringen van mislukte aanvragen van het onderwerp Diagnostische logboekregistratie inschakelen voor web-apps in Azure App Service en de veelgestelde vragen over toepassingsprestaties voor Web Apps in Azure: Hoe schakel ik tracering van mislukte aanvragen in? voor meer informatie.

Zie Diagnostische logboekregistratie inschakelen voor web-apps in Azure App Service voor meer informatie.

Problemen met IIS oplossen

Toepassingslogboek (IIS)

Toegang tot het gebeurtenislogboek van de toepassing:

1. Open het menu Start, zoek Logboekvieweren selecteer de Logboekviewer app.
2. Open in Logboekenhet knooppunt Windows-logboeken.
3. Selecteer Toepassing om het gebeurtenislogboek van de toepassing te openen.
4. Zoek naar fouten die zijn gekoppeld aan de mislukte app. Fouten hebben een waarde van de IIS AspNetCore-module of IIS Express AspNetCore-module in de kolom Bron .

De app uitvoeren bij een opdrachtprompt

Veel opstartfouten produceren geen nuttige informatie in het toepassingslogboek. U kunt de oorzaak van sommige fouten vinden door de app uit te voeren via een opdrachtprompt op het hostingsysteem.

Framework-dependent deployment

Als de app een frameworkafhankelijke implementatie is:

1. Navigeer bij een opdrachtprompt naar de implementatiemap en voer de app uit door de assembly van de app uit te voeren met dotnet.exe. Vervang in de volgende opdracht de naam van de assembly van de app door <assembly_name>: dotnet .\<assembly_name>.dll.
2. De console-uitvoer van de app, met eventuele fouten, wordt naar het consolevenster geschreven.
3. Als de fouten optreden bij het indienen van een aanvraag naar de app, moet u een aanvraag indienen bij de host en poort waar Kestrel wordt geluisterd. Gebruik de standaardhost en post om een aanvraag in te http://localhost:5000/dienen. Als de app normaal op het Kestrel eindpuntadres reageert, is het probleem waarschijnlijker gerelateerd aan de hostingconfiguratie en minder waarschijnlijk binnen de app.

Self-contained deployment

Als de app een zelfstandige implementatie is:

1. Navigeer bij een opdrachtprompt naar de implementatiemap en voer het uitvoerbare bestand van de app uit. Vervang in de volgende opdracht de naam van de assembly van de app door <assembly_name>: <assembly_name>.exe.
2. De console-uitvoer van de app, met eventuele fouten, wordt naar het consolevenster geschreven.
3. Als de fouten optreden bij het indienen van een aanvraag naar de app, moet u een aanvraag indienen bij de host en poort waar Kestrel wordt geluisterd. Gebruik de standaardhost en post om een aanvraag in te http://localhost:5000/dienen. Als de app normaal op het Kestrel eindpuntadres reageert, is het probleem waarschijnlijker gerelateerd aan de hostingconfiguratie en minder waarschijnlijk binnen de app.

ASP.NET Core Module stdout-logboek (IIS)

Stdout-logboeken inschakelen en weergeven:

1. Navigeer naar de implementatiemap van de site op het hostingsysteem.
2. Als de map logboeken niet aanwezig is, maakt u de map. Zie het onderwerp Mapstructuur voor instructies over het automatisch maken van de map logboeken in de implementatie door MSBuild in te schakelen.
3. Bewerk het web.config-bestand . Stel stdoutLogEnabled in en true wijzig het pad stdoutLogFile zodat deze verwijst naar de map met logboeken (bijvoorbeeld .\logs\stdout). stdout in het pad staat het voorvoegsel voor de naam van het logboekbestand. Er wordt automatisch een tijdstempel, proces-id en bestandsextensie toegevoegd wanneer het logboek wordt gemaakt. Als stdout voorvoegsel voor de bestandsnaam wordt een typisch logboekbestand met de naam stdout_20180205184032_5412.log genoemd.
4. Zorg ervoor dat de identiteit van de groep van toepassingen schrijfmachtigingen heeft voor de map logboeken .
5. Sla het bijgewerkte web.config-bestand op.
6. Een aanvraag indienen bij de app.
7. Navigeer naar de map met logboeken . Zoek en open het meest recente stdout-logboek.
8. Onderzoek het logboek op fouten.

Schakel stdout-logboekregistratie uit wanneer het oplossen van problemen is voltooid:

1. Bewerk het web.config-bestand .
2. Stel stdoutLogEnabled in op false.
3. Sla het bestand op.

Zie ASP.NET Core Module (ANCM) voor IIS-voor meer informatie.

De uitzonderingspagina voor ontwikkelaars inschakelen

De ASPNETCORE_ENVIRONMENTomgevingsvariabele kan worden toegevoegd aan web.config om de app uit te voeren in de ontwikkelomgeving. Zolang de omgeving niet wordt overschreven bij het opstarten van de app door UseEnvironment de hostbouwer, kan de omgevingsvariabele worden ingesteld zodat de uitzonderingspagina voor ontwikkelaars wordt weergegeven wanneer de app wordt uitgevoerd.

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

Het instellen van de omgevingsvariabele ASPNETCORE_ENVIRONMENT wordt alleen aanbevolen voor gebruik op faserings- en testservers die niet beschikbaar zijn voor internet. Verwijder de omgevingsvariabele uit het web.config-bestand na het oplossen van problemen. Zie het onderliggende element environmentVariables van aspNetCore voor informatie over het instellen van omgevingsvariabelen in web.config.

Gegevens ophalen uit een app

Als een app in staat is om te reageren op aanvragen, kunt u aanvragen, verbindingen en aanvullende gegevens van de app verkrijgen met behulp van terminal-inline-middleware. Zie Problemen oplossen en fouten opsporen ASP.NET Core-projecten voor meer informatie en voorbeeldcode.

Trage of niet-reagerende app (IIS)

Een crashdump is een momentopname van het geheugen van het systeem en kan helpen bij het bepalen van de oorzaak van een app-crash, opstartfout of trage app.

App loopt vast of ondervindt een uitzondering

Een dump verkrijgen en analyseren van Wer (Windows Error Reporting):

1. Maak een map voor het opslaan van crashdumpbestanden op c:\dumps. De app-pool moet schrijftoegang hebben tot de map.

2. Voer het PowerShell-script EnableDumps uit:

   • Als de app gebruikmaakt van het in-process hostingmodel, voert u het script uit voor w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • Als de app gebruikmaakt van het out-of-process hostingmodel, voert u het script uit voor dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Voer de app uit onder de omstandigheden die ervoor zorgen dat de crash optreedt.

4. Nadat de crash is opgetreden, voert u het DisableDumps PowerShell-script uit:

   • Als de app gebruikmaakt van het in-process hostingmodel, voert u het script uit voor w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • Als de app gebruikmaakt van het out-of-process hostingmodel, voert u het script uit voor dotnet.exe:

     .\DisableDumps dotnet.exe
     

Nadat een app vastloopt en het verzamelen van dumps is voltooid, mag de app normaal worden beëindigd. Met het PowerShell-script wordt WER geconfigureerd voor het verzamelen van maximaal vijf dumps per app.

De app reageert niet, mislukt tijdens het opstarten of wordt normaal uitgevoerd

Wanneer een app niet meer reageert, maar niet crasht, mislukt tijdens het opstarten of normaal wordt uitgevoerd, raadpleegt u User-Mode dumpbestanden: het kiezen van het beste hulpprogramma om een geschikt hulpprogramma te selecteren om de dump te produceren.

De dump analyseren

Een dump kan op verschillende manieren worden geanalyseerd. Zie Een User-Mode dumpbestand analyserenvoor meer informatie.

Caches van pakketten wissen

Een werkende app kan onmiddellijk mislukken na het upgraden van de .NET Core SDK op de ontwikkelcomputer of het wijzigen van pakketversies in de app. In sommige gevallen kunnen incoherent pakketten een app breken bij het uitvoeren van belangrijke upgrades. De meeste van deze problemen kunnen worden opgelost door de volgende instructies te volgen:

1. Verwijder de bin en obj-mappen.

2. Wis de pakketcaches door dotnet nuget locals all --clear vanuit een opdrachtprompt uit te voeren.

   Het wissen van pakketcaches kan ook worden uitgevoerd met het hulpprogramma nuget.exe en het uitvoeren van de opdracht nuget locals all -clear. nuget.exe is geen gebundelde installatie met het Windows-bureaubladbesturingssysteem en moet afzonderlijk worden verkregen van de NuGet-website.

3. Herstel het project en bouw het opnieuw.

4. Verwijder alle bestanden in de implementatiemap op de server voordat u de app opnieuw implementeert.

Additional resources

• Problemen met ASP.NET Core-projecten oplossen en fouten opsporen
• Veelvoorkomende fout oplossen voor Azure App Service en IIS met ASP.NET Core-
• fouten afhandelen in ASP.NET Core
• ASP.NET Core Module (ANCM) voor IIS-

Azure documentation

• Application Insights voor ASP.NET Core
• Sectie Web-apps voor externe foutopsporing van problemen met een web-app in Azure App Service oplossen met behulp van Visual Studio
• Overzicht van Azure App Service-diagnostiek
• Procedure: Apps bewaken in Azure App Service
• Problemen met een web-app in Azure App Service oplossen met Visual Studio
• HTTP-fouten van '502 ongeldige gateway' en '503-service niet beschikbaar' in uw Azure-web-apps oplossen
• Problemen met trage prestaties van web-apps in Azure App Service oplossen
• Veelgestelde vragen over toepassingsprestaties voor Web Apps in Azure
• Azure Web App-sandbox (uitvoeringsbeperkingen voor App Service-runtime)

Documentatie voor Visual Studio

• Externe foutopsporing ASP.NET Core in IIS in Azure in Visual Studio 2017
• Externe foutopsporing ASP.NET Core op een externe IIS-computer in Visual Studio 2017
• Meer informatie over foutopsporing met Visual Studio

Visual Studio Code-documentatie

• Foutopsporing met Visual Studio Code

Dit artikel bevat informatie over veelvoorkomende opstartfouten en instructies voor het diagnosticeren van fouten wanneer een app wordt geïmplementeerd in Azure App Service of IIS:

Opstartfouten bij app
Hierin worden veelvoorkomende scenario's met HTTP-statuscode voor opstarten uitgelegd.

Problemen oplossen in Azure App Service
Biedt advies voor probleemoplossing voor apps die zijn geïmplementeerd in Azure App Service.

Problemen met IIS oplossen
Biedt advies voor probleemoplossing voor apps die zijn geïmplementeerd in IIS of lokaal worden uitgevoerd op IIS Express. De richtlijnen zijn van toepassing op zowel Windows Server- als Windows-bureaubladimplementaties.

Pakketcaches wissen
Hierin wordt uitgelegd wat u moet doen wanneer incoherent pakketten een app breken bij het uitvoeren van belangrijke upgrades of het wijzigen van pakketversies.

Additional resources
Hier vindt u aanvullende onderwerpen over probleemoplossing.

Opstartfouten van apps

In Visual Studio is Kestrelde standaardserver van het ASP.NET Core-project. Visual Studio kan worden geconfigureerd voor het gebruik van IIS Express. Een 502.5 - Procesfout of een 500.30 - Fout starten die optreedt wanneer lokaal foutopsporing met IIS Express kan worden vastgesteld met behulp van het advies in dit onderwerp.

403.14 Forbidden

De app kan niet worden gestart. De volgende fout wordt geregistreerd:

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

De fout wordt meestal veroorzaakt door een verbroken implementatie op het hostingsysteem, waaronder een van de volgende scenario's:

• De app wordt geïmplementeerd in de verkeerde map op het hostingsysteem.
• Het implementatieproces kan niet alle bestanden en mappen van de app verplaatsen naar de implementatiemap op het hostingsysteem.
• Het web.config bestand ontbreekt in de implementatie of de inhoud van hetweb.config bestand is onjuist.

Voer de volgende stappen uit:

1. Verwijder alle bestanden en mappen uit de implementatiemap op het hostingsysteem.
2. Implementeer de inhoud van de publicatiemap van de app opnieuw naar het hostingsysteem met behulp van uw normale implementatiemethode, zoals Visual Studio, PowerShell of handmatige implementatie:
   • Controleer of het web.config-bestand aanwezig is in de implementatie en of de inhoud juist is.
   • Wanneer u host in Azure App Service, controleert u of de app is geïmplementeerd in de D:\home\site\wwwroot map.
   • Wanneer de app wordt gehost door IIS, controleert u of de app is geïmplementeerd op het fysieke IIS-pad dat wordt weergegeven in de basisinstellingen van IIS-beheer.
3. Controleer of alle bestanden en mappen van de app zijn geïmplementeerd door de implementatie op het hostingsysteem te vergelijken met de inhoud van de publicatiemap van het project.

Zie ASP.NET Core-mapstructuur voor meer informatie over de indeling van een gepubliceerde ASP.NET Core-app. Zie ASP.NET Core Module (ANCM) voor IIS voor meer informatie over het bestandweb.config.

500 Interne Serverfout

De app wordt gestart, maar een fout voorkomt dat de server aan de aanvraag voldoet.

Deze fout treedt op in de code van de app tijdens het opstarten of tijdens het maken van een antwoord. Het antwoord bevat mogelijk geen inhoud of het antwoord kan worden weergegeven als een interne serverfout van 500 in de browser. In het toepassingslogboek wordt meestal aangegeven dat de app normaal is gestart. Dat is juist vanuit het perspectief van de server. De app is gestart, maar er kan geen geldig antwoord worden gegenereerd. Voer de app uit bij een opdrachtprompt op de server of schakel het stdout-logboek van de ASP.NET Core Module in om het probleem op te lossen.

Deze fout kan ook optreden wanneer de .NET-hostingbundel niet is geïnstalleerd of beschadigd is. Het probleem kan worden opgelost door de installatie van de .NET Hosting Bundle (voor IIS) of Visual Studio (voor IIS Express) te installeren of te herstellen.

500.0 In-Process Load Failure

Het werkproces mislukt. De app wordt niet gestart.

Er is een onbekende fout opgetreden bij het laden van ASP.NET Core Module-onderdelen . Ga in dat geval op een van de volgende manieren te werk:

• Neem contact op met Microsoft Ondersteuning (selecteer Ontwikkelhulpprogramma'sen ASP.NET Core).
• Stel een vraag op Stack Overflow.
• Dien een probleem in in onze GitHub-opslagplaats.

500.30 In-Process opstartfout

Het werkproces mislukt. De app wordt niet gestart.

De ASP.NET Core-module probeert de .NET CLR in het proces te starten, maar kan niet worden gestart. De oorzaak van een opstartfout in een proces kan meestal worden bepaald op basis van vermeldingen in het gebeurtenislogboek van de toepassing en het stdout-logboek van de ASP.NET Core Module.

Algemene foutvoorwaarden:

• De app is onjuist geconfigureerd vanwege het doel van een versie van het gedeelde ASP.NET Core-framework dat niet aanwezig is. Controleer welke versies van het gedeelde framework ASP.NET Core op de doelcomputer zijn geïnstalleerd.
• Het gebruik van Azure Key Vault, gebrek aan machtigingen voor de Key Vault. Controleer het toegangsbeleid in de doelsleutelkluis om ervoor te zorgen dat de juiste machtigingen worden verleend.

500.31 ANCM kan geen systeemeigen afhankelijkheden vinden

Het werkproces mislukt. De app wordt niet gestart.

De ASP.NET Core Module probeert de .NET-runtime in het proces te starten, maar kan niet worden gestart. De meest voorkomende oorzaak van deze opstartfout is wanneer de Microsoft.NETCore.App of Microsoft.AspNetCore.App runtime niet is geïnstalleerd. Als de app is geïmplementeerd voor het doel ASP.NET Core 3.0 en die versie niet op de computer bestaat, treedt deze fout op. Een voorbeeld van een foutbericht volgt:

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]

Het foutbericht bevat alle geïnstalleerde .NET-versies en de versie die door de app is aangevraagd. U kunt deze fout als volgt oplossen:

• Installeer de juiste versie van .NET op de computer.
• Wijzig de app in het doel van een versie van .NET die aanwezig is op de computer.
• Publiceer de app als een zelfstandige implementatie.

Wanneer de omgevingsvariabele wordt uitgevoerd in ontwikkeling (de ASPNETCORE_ENVIRONMENT omgevingsvariabele is ingesteld op Development), wordt de specifieke fout naar het HTTP-antwoord geschreven. De oorzaak van een opstartfout bij het proces vindt u ook in het gebeurtenislogboek van de toepassing.

500.32 ANCM kan dll niet laden

Het werkproces mislukt. De app wordt niet gestart.

De meest voorkomende oorzaak voor deze fout is dat de app wordt gepubliceerd voor een incompatibele processorarchitectuur. Als het werkproces wordt uitgevoerd als een 32-bits app en de app is gepubliceerd naar doel 64-bits, treedt deze fout op.

U kunt deze fout als volgt oplossen:

• Publiceer de app opnieuw voor dezelfde processorarchitectuur als het werkproces.
• Publiceer de app als een frameworkafhankelijke implementatie.

500.33 ANCM Request Handler Load Failure

Het werkproces mislukt. De app wordt niet gestart.

De app heeft niet verwezen naar het Microsoft.AspNetCore.App framework. Alleen apps die zijn gericht op het Microsoft.AspNetCore.App framework, kunnen worden gehost door de ASP.NET Core-module.

Als u deze fout wilt oplossen, controleert u of de app gericht is op het Microsoft.AspNetCore.App framework. Controleer het .runtimeconfig.json framework waarop de app is gericht.

500.34 ANCM Gemengde hostingmodellen worden niet ondersteund

Het werkproces kan niet zowel een in-process-app als een out-of-process-app in hetzelfde proces uitvoeren.

U kunt deze fout oplossen door apps uit te voeren in afzonderlijke IIS-toepassingsgroepen.

500.35 ANCM Meerdere In-Process toepassingen in hetzelfde proces

Het werkproces kan niet meerdere in-process apps in hetzelfde proces uitvoeren.

U kunt deze fout oplossen door apps uit te voeren in afzonderlijke IIS-toepassingsgroepen.

500.36 ANCM Out-Of-Process Handler Load Failure

De out-of-process request handler, aspnetcorev2_outofprocess.dll, bevindt zich niet naast het aspnetcorev2.dll bestand. Dit geeft een beschadigde installatie van de ASP.NET Core-module aan.

U kunt deze fout oplossen door de installatie van de .NET Hosting Bundle (voor IIS) of Visual Studio (voor IIS Express) te herstellen.

500.37 ANCM kan niet worden gestart binnen de opstarttijdlimiet

ANCM kan niet worden gestart binnen de opgegeven opstarttijdlimiet. De time-out is standaard 120 seconden.

Deze fout kan optreden bij het starten van een groot aantal apps op dezelfde computer. Controleer tijdens het opstarten op pieken in het CPU-/geheugengebruik op de server. Mogelijk moet u het opstartproces van meerdere apps stagneren.

500.38 ANCM-toepassings-DLL niet gevonden

ANCM kan de DLL van de toepassing niet vinden, die naast het uitvoerbare bestand moet staan.

Deze fout treedt op bij het hosten van een app die is verpakt als uitvoerbaar bestand met één bestand met behulp van het in-process hostingmodel. Het in-process model vereist dat de ANCM de .NET-app in het bestaande IIS-proces laadt. Dit scenario wordt niet ondersteund door het implementatiemodel met één bestand. Gebruik een van de volgende benaderingen in het projectbestand van de app om deze fout op te lossen:

1. Schakel publicatie van één bestand uit door de PublishSingleFile eigenschap MSBuild in te stellen op false.
2. Schakel over naar het out-of-process hostingmodel door de AspNetCoreHostingModel eigenschap MSBuild in te stellen op OutOfProcess.

502.5 Procesfout

Het werkproces mislukt. De app wordt niet gestart.

De ASP.NET Core Module probeert het werkproces te starten, maar kan niet worden gestart. De oorzaak van een opstartfout in een proces kan meestal worden bepaald op basis van vermeldingen in het gebeurtenislogboek van de toepassing en het stdout-logboek van de ASP.NET Core Module.

Een veelvoorkomende foutvoorwaarde is dat de app onjuist is geconfigureerd vanwege een versie van het gedeelde ASP.NET Core-framework dat niet aanwezig is. Controleer welke versies van het gedeelde framework ASP.NET Core op de doelcomputer zijn geïnstalleerd. Het gedeelde framework is de set assembly's (.dll bestanden) die op de computer zijn geïnstalleerd en waarnaar wordt verwezen door een metapackage, zoals Microsoft.AspNetCore.App. De metapackage-verwijzing kan een minimaal vereiste versie opgeven. Zie Het gedeelde frameworkvoor meer informatie.

De foutpagina 502.5 Procesfout wordt geretourneerd wanneer een hosting- of app-onjuiste configuratie ervoor zorgt dat het werkproces mislukt:

Kan de toepassing niet starten (ErrorCode '0x800700c1')

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

De app kan niet worden gestart omdat de assembly van de app (.dll) niet kan worden geladen.

Deze fout treedt op wanneer er een beetje niet overeenkomt tussen de gepubliceerde app en het w3wp/iisexpress-proces.

Controleer of de 32-bits instelling van de app-pool juist is:

1. Selecteer de app-groep in de toepassingsgroepen van IIS-beheer.
2. Selecteer Geavanceerde instellingen onder Groep toepassingen bewerken in het deelvenster Acties .
3. 32-bits toepassingen instellen:
   • Als u een 32-bits app (x86) implementeert, stelt u de waarde in op True.
   • Als u een 64-bits (x64)-app implementeert, stelt u de waarde in op False.

Controleer of er geen conflict is tussen een <Platform> MSBuild-eigenschap in het projectbestand en de gepubliceerde bitness van de app.

Kan de toepassing niet starten (ErrorCode '0x800701b1')

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

De app kan niet worden gestart omdat een Windows-service niet kan worden geladen.

Een veelgebruikte service die moet worden ingeschakeld, is de 'null'-service. Met de volgende opdracht wordt de null Windows-service ingeschakeld:

sc.exe start null

Connection reset

Als er een fout optreedt nadat de headers zijn verzonden, is het te laat voor de server om een 500 interne serverfout te verzenden wanneer er een fout optreedt. Dit gebeurt vaak wanneer er een fout optreedt tijdens de serialisatie van complexe objecten voor een antwoord. Dit type fout wordt weergegeven als een verbindingsherstelfout op de client. Toepassingslogboekregistratie kan helpen bij het oplossen van deze typen fouten.

Standaard opstartlimieten

De ASP.NET Core-module is geconfigureerd met een standaard startupTimeLimit van 120 seconden. Wanneer u op de standaardwaarde blijft staan, kan het tot twee minuten duren voordat de module een procesfout registreert. Zie Kenmerken van het aspNetCore-element voor meer informatie over het configureren van de module.

Problemen oplossen in Azure App Service

Azure App Services-logboekstream

In het Logboek van Azure App Services worden logboekgegevens gestreamd terwijl deze zich voordoen. Streaminglogboeken weergeven:

1. Open de app in Azure Portal in App Services.
2. Navigeer in het linkerdeelvenster naarApp Service-logboekenbewaken>.
3. Selecteer Bestandssysteem voor webserverlogboekregistratie. Schakel eventueel toepassingslogboekregistratie in.
4. Navigeer in het linkerdeelvenster naar debewakingslogboekstream> en selecteer toepassingslogboeken of webserverlogboeken.

In de volgende afbeeldingen ziet u de uitvoer van de toepassingslogboeken:

Streaminglogboeken hebben enige latentie en worden mogelijk niet onmiddellijk weergegeven.

Gebeurtenislogboek van toepassing (Azure App Service)

Als u toegang wilt krijgen tot het gebeurtenislogboek van de toepassing, gebruikt u de blade Problemen vaststellen en oplossen in Azure Portal:

1. Open de app in Azure Portal in App Services.
2. Selecteer Problemen diagnosticeren en oplossen.
3. Selecteer de kop Diagnostische hulpprogramma's .
4. Selecteer onder Ondersteuningshulpprogramma's de knop Toepassingsevenementen .
5. Bekijk de meest recente fout die is opgegeven door de vermelding IIS AspNetCoreModule of IIS AspNetCoreModule V2 in de kolom Bron .

Een alternatief voor het gebruik van de blade Problemen vaststellen en oplossen is door het toepassingslogboekbestand rechtstreeks te onderzoeken met behulp van Kudu:

1. Open Geavanceerde hulpprogramma's in het gebied Ontwikkelhulpprogramma's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
2. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
3. Open de map LogFiles .
4. Selecteer het potloodpictogram naast het eventlog.xml bestand.
5. Bekijk het logboek. Schuif naar de onderkant van het logboek om de meest recente gebeurtenissen te bekijken.

De app uitvoeren in de Kudu-console

Veel opstartfouten produceren geen nuttige informatie in het toepassingslogboek. U kunt de app uitvoeren in de Kudu Remote Execution Console om de fout te detecteren:

1. Open Geavanceerde hulpprogramma's in het gebied Ontwikkelhulpprogramma's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
2. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.

Een 32-bits app (x86) testen

Current release

1. cd d:\home\site\wwwroot
2. Voer de app uit:

   • Als de app een frameworkafhankelijke implementatie is:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Als de app een zelfstandige implementatie is:

     {ASSEMBLY NAME}.exe
     

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

Frameworkafhankelijke implementatie die wordt uitgevoerd op een preview-versie

Hiervoor moet de site-extensie ASP.NET Core {VERSION} (x86) Runtime worden geïnstalleerd.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} is de runtimeversie)
2. Voer de app uit: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

Een 64-bits (x64)-app testen

Current release

• Als de app een 64-bits frameworkafhankelijke implementatie (x64) is:
  1. cd D:\Program Files\dotnet
  2. Voer de app uit: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Als de app een zelfstandige implementatie is:
  1. cd D:\home\site\wwwroot
  2. Voer de app uit: {ASSEMBLY NAME}.exe

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

Frameworkafhankelijke implementatie die wordt uitgevoerd op een preview-versie

Hiervoor moet de site-extensie ASP.NET Core {VERSION} (x64) Runtime worden geïnstalleerd.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} is de runtimeversie)
2. Voer de app uit: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

De console-uitvoer van de app, met eventuele fouten, wordt doorgegeven aan de Kudu-console.

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

Het ASP.NET Core Module stdout-logboek registreert vaak nuttige foutberichten die niet in het gebeurtenislogboek van de toepassing worden gevonden. Stdout-logboeken inschakelen en weergeven:

1. Navigeer in Azure Portal naar de web-app.
2. Voer kudu in het zoekvak in op de blade App Service.
3. Selecteer Geavanceerde hulpprogramma's>Go.
4. Selecteer CMD voor foutopsporingsconsole>.
5. Navigeren naar site/wwwroot
6. Selecteer het potloodpictogram om het web.config bestand te bewerken.
7. <aspNetCore /> Stel het element in stdoutLogEnabled="true" en selecteer Opslaan.

Schakel stdout-logboekregistratie uit wanneer het oplossen van problemen is voltooid door de instelling in te stellen stdoutLogEnabled="false".

Zie ASP.NET Core Module (ANCM) voor IIS-voor meer informatie.

ASP.NET Core Module-foutopsporingslogboek (Azure App Service)

Het ASP.NET Core Module-foutopsporingslogboek biedt aanvullende, uitgebreidere logboekregistratie van de ASP.NET Core-module. Stdout-logboeken inschakelen en weergeven:

1. Voer een van de volgende handelingen uit om het uitgebreide diagnostische logboek in te schakelen:
   • Volg de instructies in uitgebreide diagnostische logboeken om de app te configureren voor een uitgebreide diagnostische logboekregistratie. Implementeer de app opnieuw.
   • Voeg de <handlerSettings> weergegeven diagnostische logboeken toe aan het web.config-bestand van de live-app met behulp van de Kudu-console:
     1. Open Geavanceerde hulpprogramma's in het gebied Ontwikkelhulpprogramma's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
     2. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
     3. Open de mappen naar de padsite>wwwroot. Bewerk het web.config bestand door de potloodknop te selecteren. Voeg de <handlerSettings> sectie toe zoals wordt weergegeven in uitgebreide diagnostische logboeken. Selecteer de knop Opslaan.
2. Open Geavanceerde hulpprogramma's in het gebied Ontwikkelhulpprogramma's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
3. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
4. Open de mappen naar de padsite>wwwroot. Als u geen pad hebt opgegeven voor het aspnetcore-debug.log bestand, wordt het bestand weergegeven in de lijst. Als u een pad hebt opgegeven, gaat u naar de locatie van het logboekbestand.
5. Open het logboekbestand met de potloodknop naast de bestandsnaam.

Schakel logboekregistratie voor foutopsporing uit wanneer het oplossen van problemen is voltooid:

Voer een van de volgende handelingen uit om het uitgebreide foutopsporingslogboek uit te schakelen:

• Verwijder het <handlerSettings> bestand uit het web.config lokaal en implementeer de app opnieuw.
• Gebruik de Kudu-console om het web.config bestand te bewerken en de <handlerSettings> sectie te verwijderen. Sla het bestand op.

Zie Logboek maken en omleiden met de ASP.NET Core-module voor meer informatie.

Trage of niet-reagerende app (Azure App Service)

Als een app langzaam reageert of niet reageert op een aanvraag, raadpleegt u Problemen met trage prestaties van web-apps in Azure App Service oplossen.

Monitoring blades

Bewakingsbladeën bieden een alternatieve probleemoplossingservaring voor de methoden die eerder in het onderwerp zijn beschreven. Deze blades kunnen worden gebruikt om fouten uit de 500-serie vast te stellen.

Controleer of de ASP.NET Core Extensions zijn geïnstalleerd. Als de extensies niet zijn geïnstalleerd, installeert u deze handmatig:

1. Selecteer in de blade ONTWIKKELHULPPROGRAMMA's de blade Extensies .
2. De ASP.NET Core Extensions moeten worden weergegeven in de lijst.
3. Als de extensies niet zijn geïnstalleerd, selecteert u de knop Toevoegen .
4. Kies de ASP.NET Core Extensions in de lijst.
5. Selecteer OK om de juridische voorwaarden te accepteren.
6. Selecteer OK op de blade Extensie toevoegen .
7. Een informatief pop-upbericht geeft aan wanneer de extensies zijn geïnstalleerd.

Als stdout-logboekregistratie niet is ingeschakeld, volgt u deze stappen:

1. Selecteer in Azure Portal de blade Geavanceerde hulpprogramma's in het gebied ONTWIKKELHULPPROGRAMMA's . Selecteer de knop Go→ . De Kudu-console wordt geopend in een nieuw browsertabblad of -venster.
2. Open de console voor foutopsporing met behulp van de navigatiebalk boven aan de pagina en selecteer CMD.
3. Open de mappen naar de padsite>wwwroot en schuif omlaag om het web.config bestand onder aan de lijst weer te geven.
4. Klik op het potloodpictogram naast het bestandweb.config .
5. Stel stdoutLogEnabled in en true wijzig het pad stdoutLogFile in: \\?\%home%\LogFiles\stdout.
6. Selecteer Opslaan om het bijgewerkte web.config-bestand op te slaan.

Ga verder met het activeren van diagnostische logboekregistratie:

1. Selecteer in Azure Portal de blade Diagnostische logboeken .
2. Selecteer de aan-schakelaar voor toepassingslogboekregistratie (bestandssysteem) en gedetailleerde foutberichten. Selecteer de knop Opslaan boven aan de blade.
3. Als u tracering van mislukte aanvragen wilt opnemen, ook wel freb-logboekregistratie (Failed Request Event Buffering) genoemd, selecteert u de aan-switch voor tracering van mislukte aanvragen.
4. Selecteer de blade Logboekstream , die direct wordt weergegeven onder de blade Diagnostische logboeken in de portal.
5. Een aanvraag indienen bij de app.
6. Binnen de logboekstreamgegevens wordt de oorzaak van de fout aangegeven.

Zorg ervoor dat u stdout-logboekregistratie uitschakelt wanneer het oplossen van problemen is voltooid.

De logboeken voor het traceren van mislukte aanvragen (FREB-logboeken) weergeven:

1. Navigeer naar de blade Problemen vaststellen en oplossen in Azure Portal.
2. Selecteer Logboeken voor tracering van mislukte aanvragen in het gebied ONDERSTEUNINGSHULPPROGRAMMA's van de zijbalk.

Zie de sectie Traceringen van mislukte aanvragen van het onderwerp Diagnostische logboekregistratie inschakelen voor web-apps in Azure App Service en de veelgestelde vragen over toepassingsprestaties voor Web Apps in Azure: Hoe schakel ik tracering van mislukte aanvragen in? voor meer informatie.

Zie Diagnostische logboekregistratie inschakelen voor web-apps in Azure App Service voor meer informatie.

Problemen met IIS oplossen

Toepassingslogboek (IIS)

Toegang tot het gebeurtenislogboek van de toepassing:

1. Open het menu Start, zoek Logboekvieweren selecteer de Logboekviewer app.
2. Open in Logboekenhet knooppunt Windows-logboeken.
3. Selecteer Toepassing om het gebeurtenislogboek van de toepassing te openen.
4. Zoek naar fouten die zijn gekoppeld aan de mislukte app. Fouten hebben een waarde van de IIS AspNetCore-module of IIS Express AspNetCore-module in de kolom Bron .

De app uitvoeren bij een opdrachtprompt

Veel opstartfouten produceren geen nuttige informatie in het toepassingslogboek. U kunt de oorzaak van sommige fouten vinden door de app uit te voeren via een opdrachtprompt op het hostingsysteem.

Framework-dependent deployment

Als de app een frameworkafhankelijke implementatie is:

1. Navigeer bij een opdrachtprompt naar de implementatiemap en voer de app uit door de assembly van de app uit te voeren met dotnet.exe. Vervang in de volgende opdracht de naam van de assembly van de app door <assembly_name>: dotnet .\<assembly_name>.dll.
2. De console-uitvoer van de app, met eventuele fouten, wordt naar het consolevenster geschreven.
3. Als de fouten optreden bij het indienen van een aanvraag naar de app, moet u een aanvraag indienen bij de host en poort waar Kestrel wordt geluisterd. Gebruik de standaardhost en post om een aanvraag in te http://localhost:5000/dienen. Als de app normaal op het Kestrel eindpuntadres reageert, is het probleem waarschijnlijker gerelateerd aan de hostingconfiguratie en minder waarschijnlijk binnen de app.

Self-contained deployment

Als de app een zelfstandige implementatie is:

1. Navigeer bij een opdrachtprompt naar de implementatiemap en voer het uitvoerbare bestand van de app uit. Vervang in de volgende opdracht de naam van de assembly van de app door <assembly_name>: <assembly_name>.exe.
2. De console-uitvoer van de app, met eventuele fouten, wordt naar het consolevenster geschreven.
3. Als de fouten optreden bij het indienen van een aanvraag naar de app, moet u een aanvraag indienen bij de host en poort waar Kestrel wordt geluisterd. Gebruik de standaardhost en post om een aanvraag in te http://localhost:5000/dienen. Als de app normaal op het Kestrel eindpuntadres reageert, is het probleem waarschijnlijker gerelateerd aan de hostingconfiguratie en minder waarschijnlijk binnen de app.

ASP.NET Core Module stdout-logboek (IIS)

Stdout-logboeken inschakelen en weergeven:

1. Navigeer naar de implementatiemap van de site op het hostingsysteem.
2. Als de map logboeken niet aanwezig is, maakt u de map. Zie het onderwerp Mapstructuur voor instructies over het automatisch maken van de map logboeken in de implementatie door MSBuild in te schakelen.
3. Bewerk het web.config-bestand . Stel stdoutLogEnabled in en true wijzig het pad stdoutLogFile zodat deze verwijst naar de map met logboeken (bijvoorbeeld .\logs\stdout). stdout in het pad staat het voorvoegsel voor de naam van het logboekbestand. Er wordt automatisch een tijdstempel, proces-id en bestandsextensie toegevoegd wanneer het logboek wordt gemaakt. Als stdout voorvoegsel voor de bestandsnaam wordt een typisch logboekbestand met de naam stdout_20180205184032_5412.log genoemd.
4. Zorg ervoor dat de identiteit van de groep van toepassingen schrijfmachtigingen heeft voor de map logboeken .
5. Sla het bijgewerkte web.config-bestand op.
6. Een aanvraag indienen bij de app.
7. Navigeer naar de map met logboeken . Zoek en open het meest recente stdout-logboek.
8. Onderzoek het logboek op fouten.

Schakel stdout-logboekregistratie uit wanneer het oplossen van problemen is voltooid:

1. Bewerk het web.config-bestand .
2. Stel stdoutLogEnabled in op false.
3. Sla het bestand op.

Zie ASP.NET Core Module (ANCM) voor IIS-voor meer informatie.

ASP.NET Core Module-foutopsporingslogboek (IIS)

Voeg de volgende handler-instellingen toe aan het web.config-bestand van de app om ASP.NET Core Module-foutopsporingslogboek in te schakelen:

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

Controleer of het opgegeven pad voor het logboek bestaat en of de identiteit van de app-pool schrijfmachtigingen heeft voor de locatie.

Zie Logboek maken en omleiden met de ASP.NET Core-module voor meer informatie.

De uitzonderingspagina voor ontwikkelaars inschakelen

De ASPNETCORE_ENVIRONMENTomgevingsvariabele kan worden toegevoegd aan web.config om de app uit te voeren in de ontwikkelomgeving. Zolang de omgeving niet wordt overschreven bij het opstarten van de app door UseEnvironment de hostbouwer, kan de omgevingsvariabele worden ingesteld zodat de uitzonderingspagina voor ontwikkelaars wordt weergegeven wanneer de app wordt uitgevoerd.

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

Het instellen van de omgevingsvariabele ASPNETCORE_ENVIRONMENT wordt alleen aanbevolen voor gebruik op faserings- en testservers die niet beschikbaar zijn voor internet. Verwijder de omgevingsvariabele uit het web.config-bestand na het oplossen van problemen. Zie het onderliggende element environmentVariables van aspNetCore voor informatie over het instellen van omgevingsvariabelen in web.config.

Gegevens ophalen uit een app

Als een app in staat is om te reageren op aanvragen, kunt u aanvragen, verbindingen en aanvullende gegevens van de app verkrijgen met behulp van terminal-inline-middleware. Zie Problemen oplossen en fouten opsporen ASP.NET Core-projecten voor meer informatie en voorbeeldcode.

Trage of niet-reagerende app (IIS)

Een crashdump is een momentopname van het geheugen van het systeem en kan helpen bij het bepalen van de oorzaak van een app-crash, opstartfout of trage app.

App loopt vast of ondervindt een uitzondering

Een dump verkrijgen en analyseren van Wer (Windows Error Reporting):

1. Maak een map voor het opslaan van crashdumpbestanden op c:\dumps. De app-pool moet schrijftoegang hebben tot de map.

2. Voer het PowerShell-script EnableDumps uit:

   • Als de app gebruikmaakt van het in-process hostingmodel, voert u het script uit voor w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • Als de app gebruikmaakt van het out-of-process hostingmodel, voert u het script uit voor dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Voer de app uit onder de omstandigheden die ervoor zorgen dat de crash optreedt.

4. Nadat de crash is opgetreden, voert u het DisableDumps PowerShell-script uit:

   • Als de app gebruikmaakt van het in-process hostingmodel, voert u het script uit voor w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • Als de app gebruikmaakt van het out-of-process hostingmodel, voert u het script uit voor dotnet.exe:

     .\DisableDumps dotnet.exe
     

Nadat een app vastloopt en het verzamelen van dumps is voltooid, mag de app normaal worden beëindigd. Met het PowerShell-script wordt WER geconfigureerd voor het verzamelen van maximaal vijf dumps per app.

De app reageert niet, mislukt tijdens het opstarten of wordt normaal uitgevoerd

Wanneer een app niet meer reageert, maar niet crasht, mislukt tijdens het opstarten of normaal wordt uitgevoerd, raadpleegt u User-Mode dumpbestanden: het kiezen van het beste hulpprogramma om een geschikt hulpprogramma te selecteren om de dump te produceren.

De dump analyseren

Een dump kan op verschillende manieren worden geanalyseerd. Zie Een User-Mode dumpbestand analyserenvoor meer informatie.

Caches van pakketten wissen

Een werkende app kan onmiddellijk mislukken na het upgraden van de .NET SDK op de ontwikkelcomputer of het wijzigen van pakketversies in de app. In sommige gevallen kunnen incoherent pakketten een app breken bij het uitvoeren van belangrijke upgrades. De meeste van deze problemen kunnen worden opgelost door de volgende instructies te volgen:

1. Verwijder de bin en obj-mappen.

2. Wis de pakketcaches door dotnet nuget locals all --clear vanuit een opdrachtprompt uit te voeren.

   Het wissen van pakketcaches kan ook worden uitgevoerd met het hulpprogramma nuget.exe en het uitvoeren van de opdracht nuget locals all -clear. nuget.exe is geen gebundelde installatie met het Windows-bureaubladbesturingssysteem en moet afzonderlijk worden verkregen van de NuGet-website.

3. Herstel het project en bouw het opnieuw.

4. Verwijder alle bestanden in de implementatiemap op de server voordat u de app opnieuw implementeert.

Additional resources

• Fouten opsporen in .NET en ASP.NET Core-broncode met Visual Studio
• Problemen met ASP.NET Core-projecten oplossen en fouten opsporen
• Veelvoorkomende fout oplossen voor Azure App Service en IIS met ASP.NET Core-
• fouten afhandelen in ASP.NET Core
• ASP.NET Core Module (ANCM) voor IIS-

Azure documentation

• Application Insights voor ASP.NET Core
• Sectie Web-apps voor externe foutopsporing van problemen met een web-app in Azure App Service oplossen met behulp van Visual Studio
• Overzicht van Azure App Service-diagnostiek
• Procedure: Apps bewaken in Azure App Service
• Problemen met een web-app in Azure App Service oplossen met Visual Studio
• HTTP-fouten van '502 ongeldige gateway' en '503-service niet beschikbaar' in uw Azure-web-apps oplossen
• Problemen met trage prestaties van web-apps in Azure App Service oplossen
• Veelgestelde vragen over toepassingsprestaties voor Web Apps in Azure
• Azure Web App-sandbox (uitvoeringsbeperkingen voor App Service-runtime)

Documentatie voor Visual Studio

• Externe foutopsporing ASP.NET Core in IIS in Azure in Visual Studio 2017
• Externe foutopsporing ASP.NET Core op een externe IIS-computer in Visual Studio 2017
• Meer informatie over foutopsporing met Visual Studio

Visual Studio Code-documentatie

• Foutopsporing met Visual Studio Code