Problembehandlung bei ASP.NET Core in Azure App Service und IIS

  • Artikel

Dieser Artikel enthält Informationen über häufige Fehler beim Starten von Apps und Anweisungen zur Fehlerdiagnose bei der Bereitstellung einer App für den Azure App Service oder für IIS:

App-Startfehler
Erläutert allgemeine HTTP-Statuscodeszenarien.

Problembehandlung in Azure App Service
Bietet Ratschläge zur Problembehandlung für Apps, die in Azure App Service bereitgestellt werden.

Problembehandlung bei den Internetinformationsdiensten (IIS)
Bietet Ratschläge zur Problembehandlung für Apps, die in IIS bereitgestellt oder lokal unter IIS Express ausgeführt werden. Die Anleitung gilt sowohl für Windows Server- als auch für Windows-Desktopbereitstellungen.

Bereinigen der Paketcaches
Erläutert die zu erledigenden Aktionen, wenn inkohärente Pakete eine App beim Durchführen größerer Upgrades oder beim Ändern von Paketversionen beschädigen.

Zusätzliche Ressourcen
Listet weitere Themen zur Problembehandlung auf.

App-Startfehler

In Visual Studio ist Kestrel der ASP.NET Core-Projektstandardserver. Visual Studio kann für die Verwendung von IIS Express konfiguriert werden. Ein 502.5: Prozessfehler oder 500.30: Startfehler, der beim lokalen Debuggen mit IIS Express auftritt, kann mithilfe der Hinweise in diesem Thema diagnostiziert werden.

403.14 Unzulässig

Die App startet nicht. Der folgende Fehler wird protokolliert:

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

Der Fehler wird in der Regel durch eine fehlerhafte Bereitstellung auf dem Hostsystem verursacht, wozu eines der folgenden Szenarien gehört:

  • Die App wird im falschen Ordner auf dem Hostsystem bereitgestellt.
  • Der Bereitstellungsprozess konnte nicht alle Dateien und Ordner der App in den Bereitstellungsordner auf dem Hostsystem verschieben.
  • Die Datei web.config fehlt bei der Bereitstellung, oder der Inhalt der Datei web.config ist falsch formatiert.

Führen Sie die folgenden Schritte aus:

  1. Löschen Sie alle Dateien und Ordner aus dem Bereitstellungsordner auf dem Hostsystem.
  2. Stellen Sie den Inhalt des Ordners publish der App mit Ihrer normalen Bereitstellungsmethode wie Visual Studio, PowerShell oder über die manuelle Bereitstellung erneut auf dem Hostsystem bereit:
    • Bestätigen Sie, dass die Datei web.config in der Bereitstellung vorhanden und ihr Inhalt korrekt ist.
    • Wenn Sie in Azure App Service hosten, bestätigen Sie, dass die App im Ordner D:\home\site\wwwroot bereitgestellt wird.
    • Wenn die App von IIS gehostet wird, bestätigen Sie, dass die App im physischen Pfad von IIS bereitgestellt wird, der in den grundlegenden Einstellungen des IIS-Managers angezeigt wird.
  3. Bestätigen Sie, dass alle Dateien und Ordner der App bereitgestellt werden, indem Sie die Bereitstellung auf dem Hostsystem mit dem Inhalt des Ordners publish des Projekts vergleichen.

Weitere Informationen zum Layout einer veröffentlichten ASP.NET Core-App finden Sie unter ASP.NET Core-Verzeichnisstruktur. Weitere Informationen zur Datei web.config finden Sie unter ASP.NET Core-Modul (ANCM) für IIS.

500: Interner Serverfehler

Die App wird gestartet, aber ein Fehler verhindert, dass der Server auf die Anforderung eingeht.

Dieser Fehler tritt im Code der App während des Starts oder bei der Erstellung einer Antwort auf. Die Antwort enthält möglicherweise keinen Inhalt oder die Antwort wird als 500: Interner Serverfehler im Browser angezeigt. Das Anwendungsereignisprotokoll gibt normalerweise an, dass die Anwendung normal gestartet wurde. Aus Sicht des Servers ist dies richtig. Die App wurde gestartet, aber sie kann keine gültige Antwort generieren. Führen Sie die App in einer Eingabeaufforderung auf dem Server aus oder aktivieren Sie das stdout-Protokoll des ASP.NET Core-Moduls, um das Problem zu beheben.

Dieser Fehler kann auch auftreten, wenn das .NET Core-Hostingpaket nicht installiert oder beschädigt ist. Durch die Installation oder Reparatur der Installation des .NET Core-Hostingpakets (für IIS) oder Visual Studio (für IIS Express) kann das Problem behoben werden.

500.0: Fehler beim Laden des prozessinternen Handlers

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Beim Laden von Komponenten des ASP.NET Core-Moduls ist ein unbekannter Fehler aufgetreten. Führen Sie eine der folgenden Aktionen aus:

  • Wenden Sie sich an den Microsoft-Support (über Entwicklertools > ASP.NET Core).
  • Stellen Sie Ihre Frage auf Stack Overflow.
  • Melden Sie das Problem im GitHub-Repository.

500.30: Prozessinterner Startupfehler

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Das ASP.NET Core-Modul kann den .NET Core-CLR-In-Process nicht starten. Die Ursache für einen Fehler beim Starten eines Prozesses kann in der Regel über Einträge im Anwendungsereignisprotokoll und im stdout-Protokoll des ASP.NET Core-Moduls ermittelt werden.

Häufige Fehlerbedingungen:

  • Die App ist aufgrund einer Version des freigegebenen ASP.NET Core-Frameworks falsch konfiguriert ist, die nicht vorhanden ist. Überprüfen Sie, welche Versionen des freigegebenen ASP.NET Core-Frameworks auf dem Zielcomputer installiert sind.
  • Bei Verwendung von Azure Key Vault fehlen die Berechtigungen für den Schlüsseltresor. Überprüfen Sie die Zugriffsrichtlinien im angestrebten Schlüsseltresor, um sicherzustellen, dass die richtigen Berechtigungen gewährt werden.

500.31: Fehler bei der Suche nach nativen Abhängigkeiten in ANCM

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Das ASP.NET Core-Modul kann die prozessinterne .NET Core-Runtime nicht starten. Die häufigste Ursache dieses Startfehlers ist die fehlende Installation der Laufzeiten Microsoft.NETCore.App oder Microsoft.AspNetCore.App. Dieser Fehler tritt auf, wenn die App für die Zielversion 3.0 von ASP.NET Core bereitgestellt wurde, die aber auf dem Computer nicht vorhanden ist. Es wird beispielsweise folgende Fehlermeldung angezeigt:

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]

In der Fehlermeldung werden alle installierten .NET Core-Versionen aufgelistet sowie die für die App erforderliche Version. Sie haben folgende Möglichkeiten, um diesen Fehler zu beheben:

  • Installieren Sie die entsprechende .NET Core-Version auf Ihrem Computer.
  • Ändern Sie die Zielversion der App in eine .NET Core-Version, die auf Ihrem Computer vorhanden ist.
  • Veröffentlichen Sie die App als eine eigenständige Bereitstellung.

Beim Ausführen im Entwicklungsmodus (wenn die Umgebungsvariable ASPNETCORE_ENVIRONMENT auf Development festgelegt ist) wird der jeweilige Fehler in die HTTP-Antwort geschrieben. Die Ursache für einen Fehler beim Starten eines Prozesses kann auch über das Anwendungsereignisprotokoll ermittelt werden.

500.32: Fehler beim Laden der DLL in ANCM

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Die häufigste Ursache für diesen Fehler ist die Veröffentlichung der App für eine nicht kompatible Prozessorarchitektur. Der Fehler tritt auf, wenn der Arbeitsprozess als 32-Bit-App ausgeführt wird, die App aber für eine 64-Bit-Ausführung veröffentlicht wurde.

Sie haben folgende Möglichkeiten, um diesen Fehler zu beheben:

  • Veröffentlichen Sie die App erneut, sodass Prozessorarchitektur und Arbeitsprozess übereinstimmen.
  • Veröffentlichen Sie die App als eine Framework-abhängige Bereitstellung.

500.33: Fehler beim Laden des Anforderungshandlers in ANCM

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Die App verweist nicht auf das Framework Microsoft.AspNetCore.App. Das ASP.NET Core-Modul hostet nur Apps mit Microsoft.AspNetCore.App als Zielframework.

Vergewissern Sie sich, dass das Zielframework der App Microsoft.AspNetCore.App ist, um den Fehler zu beheben. Überprüfen Sie .runtimeconfig.json, um das Zielframework der App anzuzeigen.

500.34: Gemischte Hostingmodelle in ANCM nicht unterstützt

Im selben Arbeitsprozess können nicht gleichzeitig eine In-Process- und eine Out-of-Process-App ausgeführt werden.

Führen Sie die Apps in separaten IIS-Anwendungspools aus, um diesen Fehler zu beheben.

500.35: Mehrere In-Process-Anwendungen im selben Prozess in ANCM

Der Workerprozess kann nicht mehrere prozessinterne Apps im selben Prozess ausführen.

Führen Sie die Apps in separaten IIS-Anwendungspools aus, um diesen Fehler zu beheben.

500.36: Fehler beim Laden des Out-of-Process-Handlers in ANCM

Der Out-of-Process-Anforderungshandler aspnetcorev2_outofprocess.dll befindet sich nicht neben der Datei aspnetcorev2.dll. Dies deutet auf eine fehlerhafte Installation des ASP.NET Core-Moduls hin.

Reparieren Sie die Installation des .NET Core-Hostingpakets (für IIS) oder von Visual Studio (für IIS Express), um diesen Fehler zu beheben.

500.37: Fehler beim Starten von ANCM innerhalb des Zeitlimits für den Start

ANCM konnte nicht innerhalb des angegebenen Zeitlimits für den Start gestartet werden. Das Standardzeitlimit beträgt 120 Sekunden.

Dieser Fehler kann beim Starten einer großen Anzahl von Apps auf dem gleichen Computer auftreten. Überprüfen Sie, ob beim Starten CPU-/Speicherauslastungsspitzen auf dem Server vorhanden sind. In diesem Fall sollten Sie möglicherweise den Startvorgang einiger Apps staffeln.

500.38 ANCM-Anwendungs-DLL nicht gefunden.

Das ANCM konnte die Anwendungs-DLL nicht finden, die sich neben der ausführbaren Datei befinden sollte.

Dieser Fehler tritt auf, wenn eine als einzelne ausführbare Datei gepackte App mithilfe des In-Process-Hostingmodells gehostet wird. Das In-Process-Modell erfordert, dass das ANCM die .NET Core-App in den vorhandenen IIS-Prozess lädt. Dieses Szenario wird vom Einzeldatei-Bereitstellungsmodell nicht unterstützt. Verwenden Sie einen der folgenden Ansätze in der Projektdatei der App, um diesen Fehler zu korrigieren:

  1. Deaktivieren Sie die Einzeldateiveröffentlichung, indem Sie die MSBuild-Eigenschaft PublishSingleFile auf false festlegen.
  2. Wechseln Sie zum Out-of-Process-Hostingmodell, indem Sie die MSBuild-Eigenschaft AspNetCoreHostingModel auf OutOfProcess festlegen.

502.5: Prozessfehler

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Das ASP.NET Core-Modul kann den Workerprozess nicht starten. Die Ursache für einen Fehler beim Starten eines Prozesses kann in der Regel über Einträge im Anwendungsereignisprotokoll und im stdout-Protokoll des ASP.NET Core-Moduls ermittelt werden.

Eine allgemeine Fehlerbedingung ist, dass die App aufgrund einer Version des freigegebenen ASP.NET Core-Frameworks falsch konfiguriert ist, die nicht vorhanden ist. Überprüfen Sie, welche Versionen des freigegebenen ASP.NET Core-Frameworks auf dem Zielcomputer installiert sind. Das freigegebene Framework ist der Satz der Assemblys (DLL-Dateien), die auf dem Computer installiert werden und auf die ein Metapaket wie Microsoft.AspNetCore.App verweist. Der Metapaketverweis kann eine mindestens erforderliche Version angeben. Weitere Informationen finden Sie unter The shared framework (Das freigegebene Framework).

Die Fehlerseite 502.5: Prozessfehler wird zurückgegeben, wenn ein falsch konfiguriertes Hosting oder eine falsch konfigurierte App bewirkt, dass der Workerprozess fehlschlägt:

Fehler beim Starten der Anwendung (ErrorCode 0x800700c1)

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

Die App konnte nicht gestartet werden, weil die Assembly der App ( .dll) nicht geladen werden konnte.

Dieser Fehler tritt bei einem Bitanzahlkonflikt zwischen der veröffentlichten App und dem w3wp/iisexpress-Prozess auf.

Überprüfen Sie, ob die 32-Bit-Einstellung des Anwendungspools korrekt ist:

  1. Wählen Sie im IIS-Manager unter Anwendungspools den Anwendungspool aus.
  2. Wählen Sie im Bereich Aktionen unter Anwendungspool bearbeitenErweiterte Einstellungen aus.
  3. Wählen Sie 32-Bit-Anwendungen aktivieren aus:
    • Wenn Sie eine 32-Bit-(x86)-App bereitstellen, legen Sie den Wert auf True fest.
    • Wenn Sie eine 64-Bit-(x64)-App bereitstellen, legen Sie den Wert auf False fest.

Bestätigen Sie, dass es keinen Konflikt zwischen einer <Platform> MSBuild-Eigenschaft in der Projektdatei und der veröffentlichten Bitanzahl der App gibt.

Fehler beim Starten der Anwendung (Fehlercode „0x800701b1“)

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

Die App konnte nicht gestartet werden, da ein Windows-Dienst nicht geladen werden konnte.

Ein allgemeiner Dienst, der aktiviert werden muss, ist der „NULL“-Dienst. Mit dem folgenden Befehl wird der Windows-Dienst „null“ aktiviert:

sc.exe start null

Verbindungszurücksetzung

Falls ein Fehler auftritt, nachdem die Header gesendet wurden, ist es zu spät für den Server, einen 500: Interner Serverfehler zu senden, wenn ein Fehler auftritt. Dies ist häufig der Fall, wenn während der Serialisierung komplexer Objekte für eine Antwort ein Fehler auftritt. Diese Art von Fehler wird angezeigt, wenn ein Verbindungszurücksetzungsfehler auf dem Client auftritt. Mithilfe der Anwendungsprotokollierung können diese Fehlertypen behoben werden.

Standardstarteinschränkungen

Das ASP.NET Core-Modul wurde mit dem Standardwert 120 Sekunden für das startupTimeLimit konfiguriert. Wenn der Standardwert beibehalten wird, dauert der Start einer App möglicherweise bis zu zwei Minuten. Erst danach kann das Modul einen Prozessfehler protokollieren. Weitere Informationen zum Konfigurieren des Moduls finden Sie unter Attribute des aspNetCore-Elements.

Problembehandlung in Azure App Service

Wichtig

ASP.NET Core-Vorschauversion mit Azure App Service

ASP.NET Core-Vorschauversionen werden nicht standardmäßig in Azure App Service bereitgestellt. Weitere Informationen zum Hosten einer App, die eine ASP.NET Core-Vorschauversion verwendet, finden Sie unter Deploy ASP.NET Core preview release to Azure App Service (Bereitstellen der ASP.NET Core-Vorschauversion in Azure App Service).

Azure App Service-Protokollstream

Die Azure App Service-Protokollstreams protokollieren Informationen, sobald sie aufkommen. So zeigen Sie Streamingprotokolle an:

  1. Öffnen Sie die App im Azure-Portal unter App Services.
  2. Navigieren Sie im linken Bereich zu Überwachung>App Service-Protokolle. App Service-Protokolle
  3. Wählen Sie Dateisystem für Webserverprotokollierung aus. Aktivieren Sie optional die Anwendungsprotokollierung. Protokollierung aktivieren
  4. Navigieren Sie im linken Bereich zu Überwachung>Protokollstream, und wählen Sie dann Anwendungsprotokolle oder Webserverprotokolle aus.

Überwachung > Protokollstream

Die folgenden Abbildungen zeigen die Ausgabe der Anwendungsprotokolle:

App-Protokolle

Streamingprotokolle haben eine etwas höhere Latenz und werden möglicherweise nicht sofort angezeigt.

Anwendungsereignisprotokoll (Azure App Service)

Verwenden Sie das Blatt Diagnose und Problembehandlung im Azure-Portal, um auf das Anwendungsereignisprotokoll zuzugreifen:

  1. Öffnen Sie die App im Azure-Portal unter App Services.
  2. Klicken Sie auf Diagnose und Problembehandlung.
  3. Wählen Sie die Überschrift Diagnosetools aus.
  4. Klicken Sie unter Supporttools auf die Schaltfläche Anwendungsereignisse.
  5. Überprüfen Sie den letzten vom Eintrag IIS AspNetCoreModule oder IIS AspNetCoreModule V2 in der Spalte Quelle angegebenen Fehler.

Anstatt das Blatt Diagnose und Problembehandlung zu verwenden, können Sie die Anwendungsereignisprotokoll-Datei auch direkt mit Kudu untersuchen:

  1. Öffnen Sie Erweiterte Tools im Bereich Entwicklungstools. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  2. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
  3. Öffnen Sie den Ordner LogFiles.
  4. Wählen Sie den Bleistift neben der Datei eventlog.xml aus.
  5. Untersuchen Sie das Protokoll. Scrollen Sie zum Ende des Protokolls, um die aktuellsten Ereignisse anzuzeigen.

Führen Sie die App in der Kudu-Konsole aus

Viele Startfehler erzeugen keine nützlichen Informationen im Anwendungsereignisprotokoll. Sie können die App in der Kudu-Remote-Ausführungskonsole ausführen, um den Fehler zu ermitteln:

  1. Öffnen Sie Erweiterte Tools im Bereich Entwicklungstools. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  2. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.

Testen einer 32-Bit-App (x86)

Aktuelles Release

  1. cd d:\home\site\wwwroot
  2. Führen Sie die App aus:

Die Konsolenausgabe der App, die Fehler anzeigt, wird an die Kudu-Konsole weitergeleitet.

Frameworkabhängige Bereitstellung, die in einem Vorschaurelease ausgeführt wird

Erfordert die Installation der Runtimeerweiterung für ASP.NET Core {VERSION} (x86).

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} ist die Runtimeversion.)
  2. Führen Sie die App aus: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Die Konsolenausgabe der App, in der alle Fehler angezeigt werden, wird per Pipe an die Kudu-Konsole weitergeleitet.

Testen einer 64-Bit-App (x64)

Aktuelles Release

  • Wenn es sich bei der App um eine frameworkabhängige Bereitstellung (64-Bit, x64) handelt:
    1. cd D:\Program Files\dotnet
    2. Führen Sie die App aus: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
  • Wenn es sich bei der App um eine eigenständige Bereitstellung handelt:
    1. cd D:\home\site\wwwroot
    2. Führen Sie die App aus: {ASSEMBLY NAME}.exe

Die Konsolenausgabe der App, in der alle Fehler angezeigt werden, wird per Pipe an die Kudu-Konsole weitergeleitet.

Frameworkabhängige Bereitstellung, die in einem Vorschaurelease ausgeführt wird

Erfordert die Installation der Runtimeerweiterung für ASP.NET Core {VERSION} (x64).

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} ist die Runtimeversion.)
  2. Führen Sie die App aus: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Die Konsolenausgabe der App, die Fehler anzeigt, wird an die Kudu-Konsole weitergeleitet.

stdout-Protokoll im ASP.NET Core-Modul (Azure App Service)

Warnung

Wenn das stdout-Protokoll nicht deaktiviert wird, können App- oder Serverfehler auftreten. Für die Protokollgröße oder die Anzahl von erstellten Protokolldateien ist kein Grenzwert festgelegt. Verwenden Sie die stdout-Protokollierung nur für die Behandlung von App-Startproblemen.

Verwenden Sie für die allgemeine Protokollierung in einer ASP.NET Core-App nach dem Start eine Protokollierungsbibliothek, die die Protokolldateigröße beschränkt und Protokolle rotiert. Weitere Informationen finden Sie im Artikel zur Protokollierung von Drittanbietern.

Das stdout-Protokoll des ASP.NET Core-Moduls zeichnet häufig nützliche Fehlermeldungen auf, die nicht im Anwendungsereignisprotokoll enthalten sind. So aktivieren Sie stdout-Protokolle und zeigen diese an:

  1. Navigieren Sie im Azure-Portal zur Web-App.
  2. Geben Sie auf dem Blatt App Service in das Suchfeld kudu ein.
  3. Wählen Sie Erweiterte Tools>Los aus.
  4. Wählen Sie Debugkonsole > CMD aus.
  5. Navigieren Sie zu site/wwwroot.
  6. Klicken Sie auf das Bleistiftsymbol, um die Datei web.config zu bearbeiten.
  7. Legen Sie im <aspNetCore />-Element stdoutLogEnabled="true" fest, und klicken Sie dann auf Speichern.

Deaktivieren Sie die stdout-Protokollierung, wenn die Problembehandlung abgeschlossen ist, indem Sie stdoutLogEnabled="false" festlegen.

Weitere Informationen finden Sie im Artikel ASP.NET Core-Modul (ANCM) für IIS:

Debugprotokoll im ASP.NET Core-Modul (Azure App Service)

Das Debugprotokoll des ASP.NET Core-Moduls ermöglicht die zusätzliche und ausführlichere Protokollierung über das ASP.NET Core-Modul. So aktivieren Sie stdout-Protokolle und zeigen diese an:

  1. Führen Sie einen der folgenden Schritte aus, um das erweiterte Diagnoseprotokoll zu aktivieren:
    • Befolgen Sie den Anweisungen in den erweiterten Diagnoseprotokollen, um die App für die erweiterte Diagnoseprotokollierung zu konfigurieren. Stellen Sie die App erneut bereit.
    • Fügen Sie die in unter Erweiterte Diagnoseprotokollen enthaltene <handlerSettings>-Klasse für die web.config-Datei der Live-App über die Kudu-Konsole hinzu:
      1. Öffnen Sie Erweiterte Tools im Bereich Entwicklungstools. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
      2. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
      3. Öffnen Sie die Ordner unter dem Pfad site>wwwroot. Bearbeiten Sie die Datei web.config, indem Sie auf die Bleistiftschaltfläche klicken. Fügen Sie den Abschnitt <handlerSettings> wie in den erweiterten Diagnoseprotokollen dargestellt hinzu. Klicken Sie auf die Schaltfläche Speichern.
  2. Öffnen Sie Erweiterte Tools im Bereich Entwicklungstools. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  3. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
  4. Öffnen Sie die Ordner unter dem Pfad site>wwwroot. Wenn Sie keinen Pfad für die aspnetcore-debug.log-Datei angegeben haben, wird die Datei in der Liste aufgeführt. Wenn Sie jedoch einen Pfad angegeben haben, navigieren Sie zum Speicherort der Protokolldatei.
  5. Öffnen Sie die Protokolldatei über die Bleistiftschaltfläche neben dem Dateinamen.

Deaktivieren Sie die Debugprotokollierung, wenn die Problembehandlung abgeschlossen ist.

Führen Sie einen der folgenden Schritte aus, um das erweiterte Debugprotokoll zu deaktivieren:

  • Entfernen Sie <handlerSettings> aus der lokalen web.config-Datei, und stellen Sie die App erneut bereit.
  • Verwenden Sie die Kudu-Konsole, um die web.config-Datei zu bearbeiten und den Abschnitt <handlerSettings> zu entfernen. Speichern Sie die Datei.

Weitere Informationen finden Sie unter Protokollerstellung und -umleitung mit dem ASP.NET Core-Modul.

Warnung

Wenn das Debugprotokoll nicht deaktiviert werden kann, können App- oder Serverfehler auftreten. Es gibt keine Begrenzung für die Größe der Protokolldatei. Nutzen Sie die Debugprotokollierung nur für die Behandlung von App-Startproblemen.

Verwenden Sie für die allgemeine Protokollierung in einer ASP.NET Core-App nach dem Start eine Protokollierungsbibliothek, die die Protokolldateigröße beschränkt und Protokolle rotiert. Weitere Informationen finden Sie im Artikel zur Protokollierung von Drittanbietern.

Langsame oder nicht reagierende App (Azure App Service)

Wenn eine App langsam reagiert oder auf eine Anfrage nicht reagiert, lesen Sie den Artikel Fehlerbehebung bei Problemen mit der Leistung langsamer Web-Apps in Azure App Service.

Überwachungsblätter

Überwachungsblätter bieten eine Alternative zur Problembehandlung mit den weiter oben in diesem Thema beschriebenen Methoden. Die Blätter können zur Diagnose von Serie 500-Fehlern verwendet werden.

Vergewissern Sie sich, dass ASP.NET Core-Erweiterungen installiert sind. Wenn die Erweiterungen nicht installiert sind, installieren Sie diese manuell:

  1. Wählen Sie im Blattabschnitt ENTWICKLUNGSTOOLS das Blatt Erweiterungen aus.
  2. Die ASP.NET Core-Erweiterungen werden in der Liste angezeigt.
  3. Wenn die Erweiterungen nicht installiert sind, klicken Sie auf Hinzufügen.
  4. Wählen Sie die ASP.NET Core-Erweiterungen aus der Liste.
  5. Klicken Sie auf OK, um die rechtlichen Bedingungen zu akzeptieren.
  6. Klicken Sie auf OK auf dem Blatt Erweiterung hinzufügen.
  7. Mit einer Popup-Informationsmeldung wird die erfolgreiche Installation der Erweiterungen angezeigt.

Wenn die stdout-Protokollierung nicht aktiviert ist, gehen Sie folgendermaßen vor:

  1. Wählen Sie im Azure-Portal das Blatt Erweiterte Tools im Bereich ENTWICKLUNGSTOOLS aus. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  2. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
  3. Öffnen Sie die Ordner unter dem Pfad site>wwwroot, und scrollen Sie nach unten, um die Datei web.config am Ende der Liste einzublenden.
  4. Klicken Sie auf den Bleistift neben der Datei web.config.
  5. Setzen Sie stdoutLogEnabled auf true, und ändern Sie den Pfad stdoutLogFile in: \\?\%home%\LogFiles\stdout.
  6. Wählen Sie Speichern aus, um die aktualisierte Datei web.config zu speichern.

Fahren Sie mit der Aktivierung der Diagnoseprotokollierung fort:

  1. Wählen Sie im Azure-Portal das Blatt Diagnoseprotokolle aus.
  2. Wählen Sie den Parameter On für Anwendungsprotokollierung (Dateisystem) und Detaillierte Fehlermeldungen aus. Klicken Sie auf Speichern am oberen Rand des Blatts.
  3. Um die Ablaufverfolgung für Anforderungsfehler, auch bekannt als Protokollierung der Anforderungsfehler-Ereignispufferung (FREB), einzuschließen, wählen Sie den Parameter On für Ablaufverfolgung für Anforderungsfehler aus.
  4. Wählen Sie das Blatt Protokollstream aus, das direkt unter dem Blatt Diagnoseprotokolle im Portal angezeigt wird.
  5. Führen Sie eine Anforderung an die App aus.
  6. In den Protokollstreamdaten wird die Ursache des Fehlers angegeben.

Achten Sie darauf, die stdout-Protokollierung zu deaktivieren, wenn die Problembehandlung abgeschlossen ist.

So zeigen Sie die Ablaufverfolgungsprotokolle für Anforderungsfehler (FREB-Protokolle) an:

  1. Navigieren Sie zum Blatt Diagnose und Problembehandlung im Azure-Portal.
  2. Wählen Sie Failed Request Tracing Logs (Ablaufverfolgungsprotokolle für Anforderungsfehler) im Bereich SUPPORTTOOLS der Seitenleiste aus.

Weitere Informationen finden Sie im Abschnitt „Failed request traces“ im Thema „Enable diagnostics logging for apps in Azure App Service“ und unter Häufig gestellte Fragen zur Anwendungsleistung von Web-Apps in Azure: Wie schalte ich die Ablaufverfolgung für Anforderungsfehler ein?

Aktivieren der Diagnoseprotokollierung für Apps in Azure App Service.

Warnung

Wenn das stdout-Protokoll nicht deaktiviert wird, können App- oder Serverfehler auftreten. Für die Protokollgröße oder die Anzahl von erstellten Protokolldateien ist kein Grenzwert festgelegt.

Verwenden Sie für die routinemäßige Protokollierung in einer ASP.NET Core-App eine Protokollierungsbibliothek, die die Protokolldateigröße beschränkt und die Protokolle rotiert. Weitere Informationen finden Sie im Artikel zur Protokollierung von Drittanbietern.

Problembehandlung bei den Internetinformationsdiensten (IIS)

Anwendungsereignisprotokoll (IIS)

Greifen Sie auf das Anwendungsereignisprotokoll zu:

  1. Öffnen Sie das Startmenü, suchen Sie nach der Ereignisanzeige, und wählen Sie dann die App Ereignisanzeige aus.
  2. Öffnen Sie unter Ereignisanzeige den Knoten Windows-Protokolle.
  3. Wählen Sie Anwendung aus, um das Anwendungsereignisprotokoll zu öffnen.
  4. Suchen Sie nach Fehlern, die mit der fehlerhaften App im Zusammenhang stehen. Fehler weisen in der Spalte Quelle den Wert IIS AspNetCore-Modul oder IIS Express AspNetCore-Modul auf.

Ausführen der App in einer Eingabeaufforderung

Viele Startfehler erzeugen keine nützlichen Informationen im Anwendungsereignisprotokoll. Sie können die Ursache für einige Fehler ermitteln, indem Sie die App in einer Eingabeaufforderung auf dem Hostsystem ausführen.

Framework-abhängige Bereitstellung

Wenn es sich bei der App um eine Framework-abhängige Bereitstellung handelt:

  1. Navigieren Sie in einer Eingabeaufforderung zum Bereitstellungsordner und führen Sie die App aus, indem Sie die Assembly der App mit dotnet.exe ausführen. Ersetzen Sie in folgendem Befehl den Namen der Assembly der App durch<assembly_name>: dotnet .\<assembly_name>.dll.
  2. Die Konsolenausgabe der App, die Fehler anzeigt, wird in das Konsolenfenster geschrieben.
  3. Wenn der Fehler während einer Anforderung an die App auftritt, führen Sie eine Anforderung an den Host und Port aus, auf dem Kestrel empfangsbereit ist. Führen Sie unter Verwendung der Standardhosts und -ports eine Anforderung für http://localhost:5000/ aus. Wenn die App normalerweise auf die Kestrel-Endpunktadresse reagiert, ist die Problemursache wahrscheinlich die Hostingkonfiguration (anstelle der App).

Eigenständige Bereitstellung

Wenn es sich bei der App um eine eigenständige Bereitstellung handelt:

  1. Navigieren Sie in einer Eingabeaufforderung zum Bereitstellungsordner und führen Sie die ausführbaren Dateien der App aus. Ersetzen Sie in folgendem Befehl den Namen der Assembly der App durch <assembly_name>: <assembly_name>.exe.
  2. Die Konsolenausgabe der App, die Fehler anzeigt, wird in das Konsolenfenster geschrieben.
  3. Wenn der Fehler während einer Anforderung an die App auftritt, führen Sie eine Anforderung an den Host und Port aus, auf dem Kestrel empfangsbereit ist. Führen Sie unter Verwendung der Standardhosts und -ports eine Anforderung für http://localhost:5000/ aus. Wenn die App normalerweise auf die Kestrel-Endpunktadresse reagiert, ist die Problemursache wahrscheinlich die Hostingkonfiguration (anstelle der App).

stdout-Protokoll des ASP.NET Core-Moduls (IIS)

So aktivieren Sie stdout-Protokolle und zeigen diese an:

  1. Navigieren Sie zum Bereitstellungsordner der Website auf dem Hostsystem.
  2. Erstellen Sie den Ordner logs, wenn dieser nicht vorhanden ist. Anweisungen zum Aktivieren von MSBuild für die automatische Erstellung des Ordners logs in der Bereitstellung finden Sie im Thema Verzeichnisstruktur.
  3. Bearbeiten Sie die Datei web.config. Legen Sie stdoutLogEnabled auf true fest, und ändern Sie den Pfad von stdoutLogFile so, dass auf den Ordner logs verwiesen wird (Beispiel: .\logs\stdout). stdout im Pfad ist das Präfix des Protokolldateinamens. Ein Zeitstempel, eine Prozess-ID und eine Dateierweiterung werden bei der Protokollerstellung automatisch hinzugefügt. Mit stdout als Präfix des Dateinamens wird eine typische Protokolldatei als stdout_20180205184032_5412.log benannt.
  4. Stellen Sie sicher, dass die Identität des Anwendungspools über Schreibberechtigungen für den Ordner Protokolle verfügt.
  5. Speichern Sie die aktualisierte Datei web.config.
  6. Führen Sie eine Anforderung an die App aus.
  7. Navigieren Sie zu dem Ordner logs. Suchen und öffnen Sie das aktuelle stdout-Protokoll.
  8. Untersuchen Sie das Protokoll auf Fehler.

Deaktivieren Sie die stdout-Protokollierung, wenn die Problembehandlung abgeschlossen ist:

  1. Bearbeiten Sie die Datei web.config.
  2. Legen Sie stdoutLogEnabled auf false fest.
  3. Speichern Sie die Datei.

Weitere Informationen finden Sie im Artikel ASP.NET Core-Modul (ANCM) für IIS:

Warnung

Wenn das stdout-Protokoll nicht deaktiviert wird, können App- oder Serverfehler auftreten. Für die Protokollgröße oder die Anzahl von erstellten Protokolldateien ist kein Grenzwert festgelegt.

Verwenden Sie für die routinemäßige Protokollierung in einer ASP.NET Core-App eine Protokollierungsbibliothek, die die Protokolldateigröße beschränkt und die Protokolle rotiert. Weitere Informationen finden Sie im Artikel zur Protokollierung von Drittanbietern.

Debugprotokoll des ASP.NET Core-Moduls (IIS)

Fügen Sie der web.config-Datei der App die folgenden Handlereinstellungen hinzu, um das Debugprotokoll des ASP.NET Core-Moduls zu aktivieren:

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

Überprüfen Sie, ob der für das Protokoll angegebene Pfad vorhanden ist und ob die Identität des Anwendungspools Schreibberechtigungen für den Speicherort hat.

Weitere Informationen finden Sie unter Protokollerstellung und -umleitung mit dem ASP.NET Core-Modul.

Aktivieren der Seite mit Ausnahmen für Entwickler

Die ASPNETCORE_ENVIRONMENT Umgebungsvariable kann zur Datei web.config hinzugefügt werden, um die App in der Entwicklungsumgebung auszuführen. Solange die Umgebung nicht beim Starten der App von UseEnvironment im Host-Builder außer Kraft gesetzt wird, kann die Seite mit Ausnahmen für Entwickler durch Festlegen der Umgebungsvariable angezeigt werden, wenn die App ausgeführt wird.

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

Das Festlegen der Umgebungsvariablen für ASPNETCORE_ENVIRONMENT wird nur bei der Verwendung von Staging- und Testservern empfohlen, die nicht für das Internet verfügbar gemacht werden. Entfernen Sie nach der Fehlerbehebung die Umgebungsvariable aus der Datei web.config. Informationen zum Festlegen von Umgebungsvariablen in der Datei web.config finden Sie unter Untergeordnetes environmentVariables-Element von aspNetCore.

Abrufen von Daten aus einer App

Wenn eine App in der Lage sind, auf Anforderungen zu reagieren, erhalten Sie Anforderungen, Verbindungen und zusätzliche Daten von den Apps über die Inlinemiddleware des Terminals. Weitere Informationen und Beispielcode finden Sie unter Problembehandlung und Debuggen von ASP.NET Core-Projekten.

Langsame oder nicht reagierende App (IIS)

Ein Absturzabbild ist eine Momentaufnahme des Systemarbeitsspeichers, die Ihnen dabei behilflich sein kann, die Ursache eines App-Absturzes, eines Startfehlers oder einer langsamen App zu ermitteln.

App stürzt ab, oder es tritt eine Ausnahme auf

Abrufen und Analysieren eines Speicherabbilds aus der Windows-Fehlerberichterstattung (WER):

  1. Erstellen Sie einen Ordner zum Speichern von Absturzabbilddateien unter c:\dumps. Der App-Pool muss über Schreibzugriff auf den Ordner verfügen.

  2. Führen Sie das PowerShell-Skript „EnableDumps“ aus:

    • Wenn die App das In-Process-Hostingmodell verwendet, führen Sie das Skript für w3wp.exe aus:

      .\EnableDumps w3wp.exe c:\dumps

    • Wenn die App das Out-of-Process-Hostingmodell verwendet, führen Sie das Skript für dotnet.exe aus:

      .\EnableDumps dotnet.exe c:\dumps

  3. Führen Sie die App unter den Bedingungen aus, die dazu führen, dass der Absturz auftritt.

  4. Nachdem der Absturz stattgefunden hat, führen Sie das PowerShell-Skript „DisableDumps“ aus:

Nachdem eine Anwendung abgestürzt ist und die Absturzabbildsammlung abgeschlossen ist, kann die App ordnungsgemäß beendet werden. Das PowerShell-Skript konfiguriert WER für die Erfassung von bis zu fünf Absturzabbildern pro App.

Warnung

Absturzabbilder können eine große Menge Speicherplatz in Anspruch nehmen (jeweils bis zu mehreren GB).

Die App reagiert nicht, schlägt während des Starts fehl oder wird normal ausgeführt.

Wenn eine App nicht mehr reagiert, aber nicht abstürzt, beim Start fehlschlägt oder normal läuft, finden Sie unter Benutzermodus-Dumpdateien: Auswählen des besten Tools ein geeignetes Tool zur Erstellung des Speicherabbilds.

Analysieren des Speicherabbilds

Ein Speicherabbild kann mithilfe mehrerer Ansätze analysiert werden. Weitere Informationen finden Sie unter Analysieren einer Benutzermodus-Speicherabbilddatei.

Bereinigen der Paketcaches

Eine funktionsfähige App kann direkt nach der Durchführung eines Upgrades für das .NET Core SDK auf dem Entwicklungscomputer oder einer Änderung der Paketversionen in der App fehlschlagen. In einigen Fällen können inkohärente Pakete eine App beschädigen, wenn größere Upgrades durchgeführt werden. Die meisten dieser Probleme können durch Befolgung der folgenden Anweisungen behoben werden:

  1. Löschen Sie die Ordner bin und obj.

  2. Bereinigen Sie die Paketcaches, indem Sie dotnet nuget locals all --clear über eine Befehlsshell ausführen.

    Sie können die Paketcaches auch mit dem Tool nuget.exe und dem Befehl nuget locals all -clear bereinigen. nuget.exe ist wird unter dem Windows Desktop-Betriebssystem nicht gebündelt installiert und muss separat von der NuGet-Website abgerufen werden.

  3. Stellen Sie das Projekt wieder her und erstellen Sie es neu.

  4. Löschen Sie alle Dateien im Bereitstellungsordner auf dem Server, bevor Sie die App noch mal bereitstellen.

Zusätzliche Ressourcen

Azure-Dokumentation

Visual Studio-Dokumentation

Dokumentation zu Visual Studio Code

Dieser Artikel enthält Informationen über häufige Fehler beim Starten von Apps und Anweisungen zur Fehlerdiagnose bei der Bereitstellung einer App für den Azure App Service oder für IIS:

App-Startfehler
Erläutert allgemeine HTTP-Statuscodeszenarien.

Problembehandlung in Azure App Service
Bietet Ratschläge zur Problembehandlung für Apps, die in Azure App Service bereitgestellt werden.

Problembehandlung bei den Internetinformationsdiensten (IIS)
Bietet Ratschläge zur Problembehandlung für Apps, die in IIS bereitgestellt oder lokal unter IIS Express ausgeführt werden. Die Anleitung gilt sowohl für Windows Server- als auch für Windows-Desktopbereitstellungen.

Bereinigen der Paketcaches
Erläutert die zu erledigenden Aktionen, wenn inkohärente Pakete eine App beim Durchführen größerer Upgrades oder beim Ändern von Paketversionen beschädigen.

Zusätzliche Ressourcen
Listet weitere Themen zur Problembehandlung auf.

App-Startfehler

In Visual Studio entspricht ein ASP.NET Core-Projekt standardmäßig dem IIS Express-Hosting während des Debuggens. Ein 502.5: Prozessfehler oder ein 500.30: Startfehler, der beim lokalen Debuggen auftritt, kann mithilfe der Hinweise in diesem Thema diagnostiziert werden.

403.14 Unzulässig

Die App startet nicht. Der folgende Fehler wird protokolliert:

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

Der Fehler wird in der Regel durch eine fehlerhafte Bereitstellung auf dem Hostsystem verursacht, wozu eines der folgenden Szenarien gehört:

  • Die App wird im falschen Ordner auf dem Hostsystem bereitgestellt.
  • Der Bereitstellungsprozess konnte nicht alle Dateien und Ordner der App in den Bereitstellungsordner auf dem Hostsystem verschieben.
  • Die Datei web.config fehlt bei der Bereitstellung, oder der Inhalt der Datei web.config ist falsch formatiert.

Führen Sie die folgenden Schritte aus:

  1. Löschen Sie alle Dateien und Ordner aus dem Bereitstellungsordner auf dem Hostsystem.
  2. Stellen Sie den Inhalt des Ordners publish der App mit Ihrer normalen Bereitstellungsmethode wie Visual Studio, PowerShell oder über die manuelle Bereitstellung erneut auf dem Hostsystem bereit:
    • Bestätigen Sie, dass die Datei web.config in der Bereitstellung vorhanden und ihr Inhalt korrekt ist.
    • Wenn Sie in Azure App Service hosten, bestätigen Sie, dass die App im Ordner D:\home\site\wwwroot bereitgestellt wird.
    • Wenn die App von IIS gehostet wird, bestätigen Sie, dass die App im physischen Pfad von IIS bereitgestellt wird, der in den grundlegenden Einstellungen des IIS-Managers angezeigt wird.
  3. Bestätigen Sie, dass alle Dateien und Ordner der App bereitgestellt werden, indem Sie die Bereitstellung auf dem Hostsystem mit dem Inhalt des Ordners publish des Projekts vergleichen.

Weitere Informationen zum Layout einer veröffentlichten ASP.NET Core-App finden Sie unter ASP.NET Core-Verzeichnisstruktur. Weitere Informationen zur Datei web.config finden Sie unter ASP.NET Core-Modul (ANCM) für IIS.

500: Interner Serverfehler

Die App wird gestartet, aber ein Fehler verhindert, dass der Server auf die Anforderung eingeht.

Dieser Fehler tritt im Code der App während des Starts oder bei der Erstellung einer Antwort auf. Die Antwort enthält möglicherweise keinen Inhalt oder die Antwort wird als 500: Interner Serverfehler im Browser angezeigt. Das Anwendungsereignisprotokoll gibt normalerweise an, dass die Anwendung normal gestartet wurde. Aus Sicht des Servers ist dies richtig. Die App wurde gestartet, aber sie kann keine gültige Antwort generieren. Führen Sie die App in einer Eingabeaufforderung auf dem Server aus oder aktivieren Sie das stdout-Protokoll des ASP.NET Core-Moduls, um das Problem zu beheben.

Dieser Fehler kann auch auftreten, wenn das .NET Core-Hostingpaket nicht installiert oder beschädigt ist. Durch die Installation oder Reparatur der Installation des .NET Core-Hostingpakets (für IIS) oder Visual Studio (für IIS Express) kann das Problem behoben werden.

500.0: Fehler beim Laden des prozessinternen Handlers

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Das ASP.NET Core-Modul kann die .NET Core-CLR und den In-Process-Anforderungshandler (aspnetcorev2_inprocess.dll) nicht finden. Überprüfen Sie Folgendes:

500.0: Fehler beim Laden des prozessexternen Handlers

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Das ASP.NET Core-Modul kann den Out-of-Process-Hostinganforderungshandler nicht finden. Stellen Sie sicher, dass sich aspnetcorev2_outofprocess.dll in einem Unterordner mit aspnetcorev2.dll befindet.

502.5: Prozessfehler

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Das ASP.NET Core-Modul kann den Workerprozess nicht starten. Die Ursache für einen Fehler beim Starten eines Prozesses kann in der Regel über Einträge im Anwendungsereignisprotokoll und im stdout-Protokoll des ASP.NET Core-Moduls ermittelt werden.

Eine allgemeine Fehlerbedingung ist, dass die App aufgrund einer Version des freigegebenen ASP.NET Core-Frameworks falsch konfiguriert ist, die nicht vorhanden ist. Überprüfen Sie, welche Versionen des freigegebenen ASP.NET Core-Frameworks auf dem Zielcomputer installiert sind. Das freigegebene Framework ist der Satz der Assemblys (DLL-Dateien), die auf dem Computer installiert werden und auf die ein Metapaket wie Microsoft.AspNetCore.App verweist. Der Metapaketverweis kann eine mindestens erforderliche Version angeben. Weitere Informationen finden Sie unter The shared framework (Das freigegebene Framework).

Die Fehlerseite 502.5: Prozessfehler wird zurückgegeben, wenn ein falsch konfiguriertes Hosting oder eine falsch konfigurierte App bewirkt, dass der Workerprozess fehlschlägt:

Fehler beim Starten der Anwendung (ErrorCode 0x800700c1)

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

Die App konnte nicht gestartet werden, weil die Assembly der App ( .dll) nicht geladen werden konnte.

Dieser Fehler tritt bei einem Bitanzahlkonflikt zwischen der veröffentlichten App und dem w3wp/iisexpress-Prozess auf.

Überprüfen Sie, ob die 32-Bit-Einstellung des Anwendungspools korrekt ist:

  1. Wählen Sie im IIS-Manager unter Anwendungspools den Anwendungspool aus.
  2. Wählen Sie im Bereich Aktionen unter Anwendungspool bearbeitenErweiterte Einstellungen aus.
  3. Wählen Sie 32-Bit-Anwendungen aktivieren aus:
    • Wenn Sie eine 32-Bit-(x86)-App bereitstellen, legen Sie den Wert auf True fest.
    • Wenn Sie eine 64-Bit-(x64)-App bereitstellen, legen Sie den Wert auf False fest.

Bestätigen Sie, dass es keinen Konflikt zwischen einer <Platform> MSBuild-Eigenschaft in der Projektdatei und der veröffentlichten Bitanzahl der App gibt.

Verbindungszurücksetzung

Falls ein Fehler auftritt, nachdem die Header gesendet wurden, ist es zu spät für den Server, einen 500: Interner Serverfehler zu senden, wenn ein Fehler auftritt. Dies ist häufig der Fall, wenn während der Serialisierung komplexer Objekte für eine Antwort ein Fehler auftritt. Diese Art von Fehler wird angezeigt, wenn ein Verbindungszurücksetzungsfehler auf dem Client auftritt. Mithilfe der Anwendungsprotokollierung können diese Fehlertypen behoben werden.

Standardstarteinschränkungen

Das ASP.NET Core-Modul wurde mit dem Standardwert 120 Sekunden für das startupTimeLimit konfiguriert. Wenn der Standardwert beibehalten wird, dauert der Start einer App möglicherweise bis zu zwei Minuten. Erst danach kann das Modul einen Prozessfehler protokollieren. Weitere Informationen zum Konfigurieren des Moduls finden Sie unter Attribute des aspNetCore-Elements.

Problembehandlung in Azure App Service

Wichtig

ASP.NET Core-Vorschauversion mit Azure App Service

ASP.NET Core-Vorschauversionen werden nicht standardmäßig in Azure App Service bereitgestellt. Weitere Informationen zum Hosten einer App, die eine ASP.NET Core-Vorschauversion verwendet, finden Sie unter Deploy ASP.NET Core preview release to Azure App Service (Bereitstellen der ASP.NET Core-Vorschauversion in Azure App Service).

Anwendungsereignisprotokoll (Azure App Service)

Verwenden Sie das Blatt Diagnose und Problembehandlung im Azure-Portal, um auf das Anwendungsereignisprotokoll zuzugreifen:

  1. Öffnen Sie die App im Azure-Portal unter App Services.
  2. Klicken Sie auf Diagnose und Problembehandlung.
  3. Wählen Sie die Überschrift Diagnosetools aus.
  4. Klicken Sie unter Supporttools auf die Schaltfläche Anwendungsereignisse.
  5. Überprüfen Sie den letzten vom Eintrag IIS AspNetCoreModule oder IIS AspNetCoreModule V2 in der Spalte Quelle angegebenen Fehler.

Anstatt das Blatt Diagnose und Problembehandlung zu verwenden, können Sie die Anwendungsereignisprotokoll-Datei auch direkt mit Kudu untersuchen:

  1. Öffnen Sie Erweiterte Tools im Bereich Entwicklungstools. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  2. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
  3. Öffnen Sie den Ordner LogFiles.
  4. Wählen Sie den Bleistift neben der Datei eventlog.xml aus.
  5. Untersuchen Sie das Protokoll. Scrollen Sie zum Ende des Protokolls, um die aktuellsten Ereignisse anzuzeigen.

Führen Sie die App in der Kudu-Konsole aus

Viele Startfehler erzeugen keine nützlichen Informationen im Anwendungsereignisprotokoll. Sie können die App in der Kudu-Remote-Ausführungskonsole ausführen, um den Fehler zu ermitteln:

  1. Öffnen Sie Erweiterte Tools im Bereich Entwicklungstools. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  2. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.

Testen einer 32-Bit-App (x86)

Aktuelles Release

  1. cd d:\home\site\wwwroot
  2. Führen Sie die App aus:

Die Konsolenausgabe der App, die Fehler anzeigt, wird an die Kudu-Konsole weitergeleitet.

Frameworkabhängige Bereitstellung, die in einem Vorschaurelease ausgeführt wird

Erfordert die Installation der Runtimeerweiterung für ASP.NET Core {VERSION} (x86).

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} ist die Runtimeversion.)
  2. Führen Sie die App aus: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Die Konsolenausgabe der App, in der alle Fehler angezeigt werden, wird per Pipe an die Kudu-Konsole weitergeleitet.

Testen einer 64-Bit-App (x64)

Aktuelles Release

  • Wenn es sich bei der App um eine frameworkabhängige Bereitstellung (64-Bit, x64) handelt:
    1. cd D:\Program Files\dotnet
    2. Führen Sie die App aus: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
  • Wenn es sich bei der App um eine eigenständige Bereitstellung handelt:
    1. cd D:\home\site\wwwroot
    2. Führen Sie die App aus: {ASSEMBLY NAME}.exe

Die Konsolenausgabe der App, in der alle Fehler angezeigt werden, wird per Pipe an die Kudu-Konsole weitergeleitet.

Frameworkabhängige Bereitstellung, die in einem Vorschaurelease ausgeführt wird

Erfordert die Installation der Runtimeerweiterung für ASP.NET Core {VERSION} (x64).

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} ist die Runtimeversion.)
  2. Führen Sie die App aus: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Die Konsolenausgabe der App, die Fehler anzeigt, wird an die Kudu-Konsole weitergeleitet.

stdout-Protokoll im ASP.NET Core-Modul (Azure App Service)

Das stdout-Protokoll des ASP.NET Core-Moduls zeichnet häufig nützliche Fehlermeldungen auf, die nicht im Anwendungsereignisprotokoll enthalten sind. So aktivieren Sie stdout-Protokolle und zeigen diese an:

  1. Navigieren Sie zum Blatt Diagnose und Problembehandlung im Azure-Portal.
  2. Wählen Sie unter SELECT PROBLEM CATEGORY (PROBLEMKATEGORIE WÄHLEN) die Schaltfläche Web App Down (Web-App ausgefallen) aus.
  3. Klicken Sie unter Suggested Solutions (Vorgeschlagene Lösungen) >Enable Stdout Log Redirection (stdout-Protokollumleitung aktivieren) auf Open Kudu Console to edit Web.Config (Kudu-Konsole öffnen, um web.config zu bearbeiten).
  4. Öffnen Sie in der Diagnosekonsole die Ordner unter dem Pfad site>wwwroot. Scrollen Sie nach unten, um die Datei web.config am Ende der Liste einzublenden.
  5. Klicken Sie auf den Bleistift neben der Datei web.config.
  6. Setzen Sie stdoutLogEnabled auf true, und ändern Sie den Pfad stdoutLogFile in: \\?\%home%\LogFiles\stdout.
  7. Wählen Sie Speichern aus, um die aktualisierte Datei web.config zu speichern.
  8. Führen Sie eine Anforderung an die App aus.
  9. Kehren Sie zum Azure-Portal zurück. Wählen Sie das Blatt Erweiterte Tools im Bereich ENTWICKLUNGSTOOLS aus. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  10. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
  11. Wählen Sie den Ordner LogFiles aus.
  12. Überprüfen Sie die Spalte Geändert, und wählen Sie den Bleistift aus, um das stdout-Protokoll mit dem letzten Änderungsdatum zu bearbeiten.
  13. Wenn die Protokolldatei geöffnet wird, wird der Fehler angezeigt.

Deaktivieren Sie die stdout-Protokollierung, wenn die Problembehandlung abgeschlossen ist:

  1. Kehren Sie in der Kudu-Diagnosekonsole zum Pfad site>wwwroot zurück, um die Datei web.config einzublenden. Öffnen Sie die Datei web.config erneut, indem Sie den Bleistift auswählen.
  2. Legen Sie stdoutLogEnabled auf false fest.
  3. Wählen Sie Speichern aus, um die Datei zu speichern.

Weitere Informationen finden Sie im Artikel ASP.NET Core-Modul (ANCM) für IIS:

Warnung

Wenn das stdout-Protokoll nicht deaktiviert wird, können App- oder Serverfehler auftreten. Für die Protokollgröße oder die Anzahl von erstellten Protokolldateien ist kein Grenzwert festgelegt. Verwenden Sie die stdout-Protokollierung nur für die Behandlung von App-Startproblemen.

Verwenden Sie für die allgemeine Protokollierung in einer ASP.NET Core-App nach dem Start eine Protokollierungsbibliothek, die die Protokolldateigröße beschränkt und Protokolle rotiert. Weitere Informationen finden Sie im Artikel zur Protokollierung von Drittanbietern.

Debugprotokoll im ASP.NET Core-Modul (Azure App Service)

Das Debugprotokoll des ASP.NET Core-Moduls ermöglicht die zusätzliche und ausführlichere Protokollierung über das ASP.NET Core-Modul. So aktivieren Sie stdout-Protokolle und zeigen diese an:

  1. Führen Sie einen der folgenden Schritte aus, um das erweiterte Diagnoseprotokoll zu aktivieren:
    • Befolgen Sie den Anweisungen in den erweiterten Diagnoseprotokollen, um die App für die erweiterte Diagnoseprotokollierung zu konfigurieren. Stellen Sie die App erneut bereit.
    • Fügen Sie die in unter Erweiterte Diagnoseprotokollen enthaltene <handlerSettings>-Klasse für die web.config-Datei der Live-App über die Kudu-Konsole hinzu:
      1. Öffnen Sie Erweiterte Tools im Bereich Entwicklungstools. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
      2. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
      3. Öffnen Sie die Ordner unter dem Pfad site>wwwroot. Bearbeiten Sie die Datei web.config, indem Sie auf die Bleistiftschaltfläche klicken. Fügen Sie den Abschnitt <handlerSettings> wie in den erweiterten Diagnoseprotokollen dargestellt hinzu. Klicken Sie auf die Schaltfläche Speichern.
  2. Öffnen Sie Erweiterte Tools im Bereich Entwicklungstools. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  3. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
  4. Öffnen Sie die Ordner unter dem Pfad site>wwwroot. Wenn Sie keinen Pfad für die aspnetcore-debug.log-Datei angegeben haben, wird die Datei in der Liste aufgeführt. Wenn Sie jedoch einen Pfad angegeben haben, navigieren Sie zum Speicherort der Protokolldatei.
  5. Öffnen Sie die Protokolldatei über die Bleistiftschaltfläche neben dem Dateinamen.

Deaktivieren Sie die Debugprotokollierung, wenn die Problembehandlung abgeschlossen ist.

Führen Sie einen der folgenden Schritte aus, um das erweiterte Debugprotokoll zu deaktivieren:

  • Entfernen Sie <handlerSettings> aus der lokalen web.config-Datei, und stellen Sie die App erneut bereit.
  • Verwenden Sie die Kudu-Konsole, um die web.config-Datei zu bearbeiten und den Abschnitt <handlerSettings> zu entfernen. Speichern Sie die Datei.

Weitere Informationen finden Sie unter Protokollerstellung und -umleitung mit dem ASP.NET Core-Modul.

Warnung

Wenn das Debugprotokoll nicht deaktiviert werden kann, können App- oder Serverfehler auftreten. Es gibt keine Begrenzung für die Größe der Protokolldatei. Nutzen Sie die Debugprotokollierung nur für die Behandlung von App-Startproblemen.

Verwenden Sie für die allgemeine Protokollierung in einer ASP.NET Core-App nach dem Start eine Protokollierungsbibliothek, die die Protokolldateigröße beschränkt und Protokolle rotiert. Weitere Informationen finden Sie im Artikel zur Protokollierung von Drittanbietern.

Langsame oder nicht reagierende App (Azure App Service)

Wenn eine App langsam reagiert oder auf eine Anfrage nicht reagiert, lesen Sie die folgenden Artikel:

Überwachungsblätter

Überwachungsblätter bieten eine Alternative zur Problembehandlung mit den weiter oben in diesem Thema beschriebenen Methoden. Die Blätter können zur Diagnose von Serie 500-Fehlern verwendet werden.

Vergewissern Sie sich, dass ASP.NET Core-Erweiterungen installiert sind. Wenn die Erweiterungen nicht installiert sind, installieren Sie diese manuell:

  1. Wählen Sie im Blattabschnitt ENTWICKLUNGSTOOLS das Blatt Erweiterungen aus.
  2. Die ASP.NET Core-Erweiterungen werden in der Liste angezeigt.
  3. Wenn die Erweiterungen nicht installiert sind, klicken Sie auf Hinzufügen.
  4. Wählen Sie die ASP.NET Core-Erweiterungen aus der Liste.
  5. Klicken Sie auf OK, um die rechtlichen Bedingungen zu akzeptieren.
  6. Klicken Sie auf OK auf dem Blatt Erweiterung hinzufügen.
  7. Mit einer Popup-Informationsmeldung wird die erfolgreiche Installation der Erweiterungen angezeigt.

Wenn die stdout-Protokollierung nicht aktiviert ist, gehen Sie folgendermaßen vor:

  1. Wählen Sie im Azure-Portal das Blatt Erweiterte Tools im Bereich ENTWICKLUNGSTOOLS aus. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  2. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
  3. Öffnen Sie die Ordner unter dem Pfad site>wwwroot, und scrollen Sie nach unten, um die Datei web.config am Ende der Liste einzublenden.
  4. Klicken Sie auf den Bleistift neben der Datei web.config.
  5. Setzen Sie stdoutLogEnabled auf true, und ändern Sie den Pfad stdoutLogFile in: \\?\%home%\LogFiles\stdout.
  6. Wählen Sie Speichern aus, um die aktualisierte Datei web.config zu speichern.

Fahren Sie mit der Aktivierung der Diagnoseprotokollierung fort:

  1. Wählen Sie im Azure-Portal das Blatt Diagnoseprotokolle aus.
  2. Wählen Sie den Parameter On für Anwendungsprotokollierung (Dateisystem) und Detaillierte Fehlermeldungen aus. Klicken Sie auf Speichern am oberen Rand des Blatts.
  3. Um die Ablaufverfolgung für Anforderungsfehler, auch bekannt als Protokollierung der Anforderungsfehler-Ereignispufferung (FREB), einzuschließen, wählen Sie den Parameter On für Ablaufverfolgung für Anforderungsfehler aus.
  4. Wählen Sie das Blatt Protokollstream aus, das direkt unter dem Blatt Diagnoseprotokolle im Portal angezeigt wird.
  5. Führen Sie eine Anforderung an die App aus.
  6. In den Protokollstreamdaten wird die Ursache des Fehlers angegeben.

Achten Sie darauf, die stdout-Protokollierung zu deaktivieren, wenn die Problembehandlung abgeschlossen ist.

So zeigen Sie die Ablaufverfolgungsprotokolle für Anforderungsfehler (FREB-Protokolle) an:

  1. Navigieren Sie zum Blatt Diagnose und Problembehandlung im Azure-Portal.
  2. Wählen Sie Failed Request Tracing Logs (Ablaufverfolgungsprotokolle für Anforderungsfehler) im Bereich SUPPORTTOOLS der Seitenleiste aus.

Weitere Informationen finden Sie im Abschnitt „Failed request traces“ im Thema „Enable diagnostics logging for apps in Azure App Service“ und unter Häufig gestellte Fragen zur Anwendungsleistung von Web-Apps in Azure: Wie schalte ich die Ablaufverfolgung für Anforderungsfehler ein?

Aktivieren der Diagnoseprotokollierung für Apps in Azure App Service.

Warnung

Wenn das stdout-Protokoll nicht deaktiviert wird, können App- oder Serverfehler auftreten. Für die Protokollgröße oder die Anzahl von erstellten Protokolldateien ist kein Grenzwert festgelegt.

Verwenden Sie für die routinemäßige Protokollierung in einer ASP.NET Core-App eine Protokollierungsbibliothek, die die Protokolldateigröße beschränkt und die Protokolle rotiert. Weitere Informationen finden Sie im Artikel zur Protokollierung von Drittanbietern.

Problembehandlung bei den Internetinformationsdiensten (IIS)

Anwendungsereignisprotokoll (IIS)

Greifen Sie auf das Anwendungsereignisprotokoll zu:

  1. Öffnen Sie das Startmenü, suchen Sie nach der Ereignisanzeige, und wählen Sie dann die App Ereignisanzeige aus.
  2. Öffnen Sie unter Ereignisanzeige den Knoten Windows-Protokolle.
  3. Wählen Sie Anwendung aus, um das Anwendungsereignisprotokoll zu öffnen.
  4. Suchen Sie nach Fehlern, die mit der fehlerhaften App im Zusammenhang stehen. Fehler weisen in der Spalte Quelle den Wert IIS AspNetCore-Modul oder IIS Express AspNetCore-Modul auf.

Ausführen der App in einer Eingabeaufforderung

Viele Startfehler erzeugen keine nützlichen Informationen im Anwendungsereignisprotokoll. Sie können die Ursache für einige Fehler ermitteln, indem Sie die App in einer Eingabeaufforderung auf dem Hostsystem ausführen.

Framework-abhängige Bereitstellung

Wenn es sich bei der App um eine Framework-abhängige Bereitstellung handelt:

  1. Navigieren Sie in einer Eingabeaufforderung zum Bereitstellungsordner und führen Sie die App aus, indem Sie die Assembly der App mit dotnet.exe ausführen. Ersetzen Sie in folgendem Befehl den Namen der Assembly der App durch<assembly_name>: dotnet .\<assembly_name>.dll.
  2. Die Konsolenausgabe der App, die Fehler anzeigt, wird in das Konsolenfenster geschrieben.
  3. Wenn der Fehler während einer Anforderung an die App auftritt, führen Sie eine Anforderung an den Host und Port aus, auf dem Kestrel empfangsbereit ist. Führen Sie unter Verwendung der Standardhosts und -ports eine Anforderung für http://localhost:5000/ aus. Wenn die App normalerweise auf die Kestrel-Endpunktadresse reagiert, ist die Problemursache wahrscheinlich die Hostingkonfiguration (anstelle der App).

Eigenständige Bereitstellung

Wenn es sich bei der App um eine eigenständige Bereitstellung handelt:

  1. Navigieren Sie in einer Eingabeaufforderung zum Bereitstellungsordner und führen Sie die ausführbaren Dateien der App aus. Ersetzen Sie in folgendem Befehl den Namen der Assembly der App durch <assembly_name>: <assembly_name>.exe.
  2. Die Konsolenausgabe der App, die Fehler anzeigt, wird in das Konsolenfenster geschrieben.
  3. Wenn der Fehler während einer Anforderung an die App auftritt, führen Sie eine Anforderung an den Host und Port aus, auf dem Kestrel empfangsbereit ist. Führen Sie unter Verwendung der Standardhosts und -ports eine Anforderung für http://localhost:5000/ aus. Wenn die App normalerweise auf die Kestrel-Endpunktadresse reagiert, ist die Problemursache wahrscheinlich die Hostingkonfiguration (anstelle der App).

stdout-Protokoll des ASP.NET Core-Moduls (IIS)

So aktivieren Sie stdout-Protokolle und zeigen diese an:

  1. Navigieren Sie zum Bereitstellungsordner der Website auf dem Hostsystem.
  2. Erstellen Sie den Ordner logs, wenn dieser nicht vorhanden ist. Anweisungen zum Aktivieren von MSBuild für die automatische Erstellung des Ordners logs in der Bereitstellung finden Sie im Thema Verzeichnisstruktur.
  3. Bearbeiten Sie die Datei web.config. Legen Sie stdoutLogEnabled auf true fest, und ändern Sie den Pfad von stdoutLogFile so, dass auf den Ordner logs verwiesen wird (Beispiel: .\logs\stdout). stdout im Pfad ist das Präfix des Protokolldateinamens. Ein Zeitstempel, eine Prozess-ID und eine Dateierweiterung werden bei der Protokollerstellung automatisch hinzugefügt. Mit stdout als Präfix des Dateinamens wird eine typische Protokolldatei als stdout_20180205184032_5412.log benannt.
  4. Stellen Sie sicher, dass die Identität des Anwendungspools über Schreibberechtigungen für den Ordner Protokolle verfügt.
  5. Speichern Sie die aktualisierte Datei web.config.
  6. Führen Sie eine Anforderung an die App aus.
  7. Navigieren Sie zu dem Ordner logs. Suchen und öffnen Sie das aktuelle stdout-Protokoll.
  8. Untersuchen Sie das Protokoll auf Fehler.

Deaktivieren Sie die stdout-Protokollierung, wenn die Problembehandlung abgeschlossen ist:

  1. Bearbeiten Sie die Datei web.config.
  2. Legen Sie stdoutLogEnabled auf false fest.
  3. Speichern Sie die Datei.

Weitere Informationen finden Sie im Artikel ASP.NET Core-Modul (ANCM) für IIS:

Warnung

Wenn das stdout-Protokoll nicht deaktiviert wird, können App- oder Serverfehler auftreten. Für die Protokollgröße oder die Anzahl von erstellten Protokolldateien ist kein Grenzwert festgelegt.

Verwenden Sie für die routinemäßige Protokollierung in einer ASP.NET Core-App eine Protokollierungsbibliothek, die die Protokolldateigröße beschränkt und die Protokolle rotiert. Weitere Informationen finden Sie im Artikel zur Protokollierung von Drittanbietern.

Debugprotokoll des ASP.NET Core-Moduls (IIS)

Fügen Sie der web.config-Datei der App die folgenden Handlereinstellungen hinzu, um das Debugprotokoll des ASP.NET Core-Moduls zu aktivieren:

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

Überprüfen Sie, ob der für das Protokoll angegebene Pfad vorhanden ist und ob die Identität des Anwendungspools Schreibberechtigungen für den Speicherort hat.

Weitere Informationen finden Sie unter Protokollerstellung und -umleitung mit dem ASP.NET Core-Modul.

Aktivieren der Seite mit Ausnahmen für Entwickler

Die ASPNETCORE_ENVIRONMENT Umgebungsvariable kann zur Datei web.config hinzugefügt werden, um die App in der Entwicklungsumgebung auszuführen. Solange die Umgebung nicht beim Starten der App von UseEnvironment im Host-Builder außer Kraft gesetzt wird, kann die Seite mit Ausnahmen für Entwickler durch Festlegen der Umgebungsvariable angezeigt werden, wenn die App ausgeführt wird.

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

Das Festlegen der Umgebungsvariablen für ASPNETCORE_ENVIRONMENT wird nur bei der Verwendung von Staging- und Testservern empfohlen, die nicht für das Internet verfügbar gemacht werden. Entfernen Sie nach der Fehlerbehebung die Umgebungsvariable aus der Datei web.config. Informationen zum Festlegen von Umgebungsvariablen in der Datei web.config finden Sie unter Untergeordnetes environmentVariables-Element von aspNetCore.

Abrufen von Daten aus einer App

Wenn eine App in der Lage sind, auf Anforderungen zu reagieren, erhalten Sie Anforderungen, Verbindungen und zusätzliche Daten von den Apps über die Inlinemiddleware des Terminals. Weitere Informationen und Beispielcode finden Sie unter Problembehandlung und Debuggen von ASP.NET Core-Projekten.

Langsame oder nicht reagierende App (IIS)

Ein Absturzabbild ist eine Momentaufnahme des Systemarbeitsspeichers, die Ihnen dabei behilflich sein kann, die Ursache eines App-Absturzes, eines Startfehlers oder einer langsamen App zu ermitteln.

App stürzt ab, oder es tritt eine Ausnahme auf

Abrufen und Analysieren eines Speicherabbilds aus der Windows-Fehlerberichterstattung (WER):

  1. Erstellen Sie einen Ordner zum Speichern von Absturzabbilddateien unter c:\dumps. Der App-Pool muss über Schreibzugriff auf den Ordner verfügen.

  2. Führen Sie das PowerShell-Skript „EnableDumps“ aus:

    • Wenn die App das In-Process-Hostingmodell verwendet, führen Sie das Skript für w3wp.exe aus:

      .\EnableDumps w3wp.exe c:\dumps

    • Wenn die App das Out-of-Process-Hostingmodell verwendet, führen Sie das Skript für dotnet.exe aus:

      .\EnableDumps dotnet.exe c:\dumps

  3. Führen Sie die App unter den Bedingungen aus, die dazu führen, dass der Absturz auftritt.

  4. Nachdem der Absturz stattgefunden hat, führen Sie das PowerShell-Skript „DisableDumps“ aus:

Nachdem eine Anwendung abgestürzt ist und die Absturzabbildsammlung abgeschlossen ist, kann die App ordnungsgemäß beendet werden. Das PowerShell-Skript konfiguriert WER für die Erfassung von bis zu fünf Absturzabbildern pro App.

Warnung

Absturzabbilder können eine große Menge Speicherplatz in Anspruch nehmen (jeweils bis zu mehreren GB).

Die App reagiert nicht, schlägt während des Starts fehl oder wird normal ausgeführt.

Wenn eine App nicht mehr reagiert, aber nicht abstürzt, beim Start fehlschlägt oder normal läuft, finden Sie unter Benutzermodus-Dumpdateien: Auswählen des besten Tools ein geeignetes Tool zur Erstellung des Speicherabbilds.

Analysieren des Speicherabbilds

Ein Speicherabbild kann mithilfe mehrerer Ansätze analysiert werden. Weitere Informationen finden Sie unter Analysieren einer Benutzermodus-Speicherabbilddatei.

Bereinigen der Paketcaches

Eine funktionsfähige App kann direkt nach der Durchführung eines Upgrades für das .NET Core SDK auf dem Entwicklungscomputer oder einer Änderung der Paketversionen in der App fehlschlagen. In einigen Fällen können inkohärente Pakete eine App beschädigen, wenn größere Upgrades durchgeführt werden. Die meisten dieser Probleme können durch Befolgung der folgenden Anweisungen behoben werden:

  1. Löschen Sie die Ordner bin und obj.

  2. Bereinigen Sie die Paketcaches, indem Sie dotnet nuget locals all --clear über eine Befehlsshell ausführen.

    Sie können die Paketcaches auch mit dem Tool nuget.exe und dem Befehl nuget locals all -clear bereinigen. nuget.exe ist wird unter dem Windows Desktop-Betriebssystem nicht gebündelt installiert und muss separat von der NuGet-Website abgerufen werden.

  3. Stellen Sie das Projekt wieder her und erstellen Sie es neu.

  4. Löschen Sie alle Dateien im Bereitstellungsordner auf dem Server, bevor Sie die App noch mal bereitstellen.

Zusätzliche Ressourcen

Azure-Dokumentation

Visual Studio-Dokumentation

Dokumentation zu Visual Studio Code

Dieser Artikel enthält Informationen über häufige Fehler beim Starten von Apps und Anweisungen zur Fehlerdiagnose bei der Bereitstellung einer App für den Azure App Service oder für IIS:

App-Startfehler
Erläutert allgemeine HTTP-Statuscodeszenarien.

Problembehandlung in Azure App Service
Bietet Ratschläge zur Problembehandlung für Apps, die in Azure App Service bereitgestellt werden.

Problembehandlung bei den Internetinformationsdiensten (IIS)
Bietet Ratschläge zur Problembehandlung für Apps, die in IIS bereitgestellt oder lokal unter IIS Express ausgeführt werden. Die Anleitung gilt sowohl für Windows Server- als auch für Windows-Desktopbereitstellungen.

Bereinigen der Paketcaches
Erläutert die zu erledigenden Aktionen, wenn inkohärente Pakete eine App beim Durchführen größerer Upgrades oder beim Ändern von Paketversionen beschädigen.

Zusätzliche Ressourcen
Listet weitere Themen zur Problembehandlung auf.

App-Startfehler

In Visual Studio entspricht ein ASP.NET Core-Projekt standardmäßig dem IIS Express-Hosting während des Debuggens. Ein 502.5: Prozessfehler, der beim lokalen Debuggen auftritt, kann mithilfe der Hinweise in diesem Thema diagnostiziert werden.

403.14 Unzulässig

Die App startet nicht. Der folgende Fehler wird protokolliert:

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

Der Fehler wird in der Regel durch eine fehlerhafte Bereitstellung auf dem Hostsystem verursacht, wozu eines der folgenden Szenarien gehört:

  • Die App wird im falschen Ordner auf dem Hostsystem bereitgestellt.
  • Der Bereitstellungsprozess konnte nicht alle Dateien und Ordner der App in den Bereitstellungsordner auf dem Hostsystem verschieben.
  • Die Datei web.config fehlt bei der Bereitstellung, oder der Inhalt der Datei web.config ist falsch formatiert.

Führen Sie die folgenden Schritte aus:

  1. Löschen Sie alle Dateien und Ordner aus dem Bereitstellungsordner auf dem Hostsystem.
  2. Stellen Sie den Inhalt des Ordners publish der App mit Ihrer normalen Bereitstellungsmethode wie Visual Studio, PowerShell oder über die manuelle Bereitstellung erneut auf dem Hostsystem bereit:
    • Bestätigen Sie, dass die Datei web.config in der Bereitstellung vorhanden und ihr Inhalt korrekt ist.
    • Wenn Sie in Azure App Service hosten, bestätigen Sie, dass die App im Ordner D:\home\site\wwwroot bereitgestellt wird.
    • Wenn die App von IIS gehostet wird, bestätigen Sie, dass die App im physischen Pfad von IIS bereitgestellt wird, der in den grundlegenden Einstellungen des IIS-Managers angezeigt wird.
  3. Bestätigen Sie, dass alle Dateien und Ordner der App bereitgestellt werden, indem Sie die Bereitstellung auf dem Hostsystem mit dem Inhalt des Ordners publish des Projekts vergleichen.

Weitere Informationen zum Layout einer veröffentlichten ASP.NET Core-App finden Sie unter ASP.NET Core-Verzeichnisstruktur. Weitere Informationen zur Datei web.config finden Sie unter ASP.NET Core-Modul (ANCM) für IIS.

500: Interner Serverfehler

Die App wird gestartet, aber ein Fehler verhindert, dass der Server auf die Anforderung eingeht.

Dieser Fehler tritt im Code der App während des Starts oder bei der Erstellung einer Antwort auf. Die Antwort enthält möglicherweise keinen Inhalt oder die Antwort wird als 500: Interner Serverfehler im Browser angezeigt. Das Anwendungsereignisprotokoll gibt normalerweise an, dass die Anwendung normal gestartet wurde. Aus Sicht des Servers ist dies richtig. Die App wurde gestartet, aber sie kann keine gültige Antwort generieren. Führen Sie die App in einer Eingabeaufforderung auf dem Server aus oder aktivieren Sie das stdout-Protokoll des ASP.NET Core-Moduls, um das Problem zu beheben.

Dieser Fehler kann auch auftreten, wenn das .NET Core-Hostingpaket nicht installiert oder beschädigt ist. Durch die Installation oder Reparatur der Installation des .NET Core-Hostingpakets (für IIS) oder Visual Studio (für IIS Express) kann das Problem behoben werden.

502.5: Prozessfehler

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Das ASP.NET Core-Modul kann den Workerprozess nicht starten. Die Ursache für einen Fehler beim Starten eines Prozesses kann in der Regel über Einträge im Anwendungsereignisprotokoll und im stdout-Protokoll des ASP.NET Core-Moduls ermittelt werden.

Eine allgemeine Fehlerbedingung ist, dass die App aufgrund einer Version des freigegebenen ASP.NET Core-Frameworks falsch konfiguriert ist, die nicht vorhanden ist. Überprüfen Sie, welche Versionen des freigegebenen ASP.NET Core-Frameworks auf dem Zielcomputer installiert sind. Das freigegebene Framework ist der Satz der Assemblys (DLL-Dateien), die auf dem Computer installiert werden und auf die ein Metapaket wie Microsoft.AspNetCore.App verweist. Der Metapaketverweis kann eine mindestens erforderliche Version angeben. Weitere Informationen finden Sie unter The shared framework (Das freigegebene Framework).

Die Fehlerseite 502.5: Prozessfehler wird zurückgegeben, wenn ein falsch konfiguriertes Hosting oder eine falsch konfigurierte App bewirkt, dass der Workerprozess fehlschlägt:

Fehler beim Starten der Anwendung (ErrorCode 0x800700c1)

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

Die App konnte nicht gestartet werden, weil die Assembly der App ( .dll) nicht geladen werden konnte.

Dieser Fehler tritt bei einem Bitanzahlkonflikt zwischen der veröffentlichten App und dem w3wp/iisexpress-Prozess auf.

Überprüfen Sie, ob die 32-Bit-Einstellung des Anwendungspools korrekt ist:

  1. Wählen Sie im IIS-Manager unter Anwendungspools den Anwendungspool aus.
  2. Wählen Sie im Bereich Aktionen unter Anwendungspool bearbeitenErweiterte Einstellungen aus.
  3. Wählen Sie 32-Bit-Anwendungen aktivieren aus:
    • Wenn Sie eine 32-Bit-(x86)-App bereitstellen, legen Sie den Wert auf True fest.
    • Wenn Sie eine 64-Bit-(x64)-App bereitstellen, legen Sie den Wert auf False fest.

Bestätigen Sie, dass es keinen Konflikt zwischen einer <Platform> MSBuild-Eigenschaft in der Projektdatei und der veröffentlichten Bitanzahl der App gibt.

Verbindungszurücksetzung

Falls ein Fehler auftritt, nachdem die Header gesendet wurden, ist es zu spät für den Server, einen 500: Interner Serverfehler zu senden, wenn ein Fehler auftritt. Dies ist häufig der Fall, wenn während der Serialisierung komplexer Objekte für eine Antwort ein Fehler auftritt. Diese Art von Fehler wird angezeigt, wenn ein Verbindungszurücksetzungsfehler auf dem Client auftritt. Mithilfe der Anwendungsprotokollierung können diese Fehlertypen behoben werden.

Standardstarteinschränkungen

Das ASP.NET Core-Modul wurde mit dem Standardwert 120 Sekunden für das startupTimeLimit konfiguriert. Wenn der Standardwert beibehalten wird, dauert der Start einer App möglicherweise bis zu zwei Minuten. Erst danach kann das Modul einen Prozessfehler protokollieren. Weitere Informationen zum Konfigurieren des Moduls finden Sie unter Attribute des aspNetCore-Elements.

Problembehandlung in Azure App Service

Wichtig

ASP.NET Core-Vorschauversion mit Azure App Service

ASP.NET Core-Vorschauversionen werden nicht standardmäßig in Azure App Service bereitgestellt. Weitere Informationen zum Hosten einer App, die eine ASP.NET Core-Vorschauversion verwendet, finden Sie unter Deploy ASP.NET Core preview release to Azure App Service (Bereitstellen der ASP.NET Core-Vorschauversion in Azure App Service).

Anwendungsereignisprotokoll (Azure App Service)

Verwenden Sie das Blatt Diagnose und Problembehandlung im Azure-Portal, um auf das Anwendungsereignisprotokoll zuzugreifen:

  1. Öffnen Sie die App im Azure-Portal unter App Services.
  2. Klicken Sie auf Diagnose und Problembehandlung.
  3. Wählen Sie die Überschrift Diagnosetools aus.
  4. Klicken Sie unter Supporttools auf die Schaltfläche Anwendungsereignisse.
  5. Überprüfen Sie den letzten vom Eintrag IIS AspNetCoreModule oder IIS AspNetCoreModule V2 in der Spalte Quelle angegebenen Fehler.

Anstatt das Blatt Diagnose und Problembehandlung zu verwenden, können Sie die Anwendungsereignisprotokoll-Datei auch direkt mit Kudu untersuchen:

  1. Öffnen Sie Erweiterte Tools im Bereich Entwicklungstools. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  2. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
  3. Öffnen Sie den Ordner LogFiles.
  4. Wählen Sie den Bleistift neben der Datei eventlog.xml aus.
  5. Untersuchen Sie das Protokoll. Scrollen Sie zum Ende des Protokolls, um die aktuellsten Ereignisse anzuzeigen.

Führen Sie die App in der Kudu-Konsole aus

Viele Startfehler erzeugen keine nützlichen Informationen im Anwendungsereignisprotokoll. Sie können die App in der Kudu-Remote-Ausführungskonsole ausführen, um den Fehler zu ermitteln:

  1. Öffnen Sie Erweiterte Tools im Bereich Entwicklungstools. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  2. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.

Testen einer 32-Bit-App (x86)

Aktuelles Release

  1. cd d:\home\site\wwwroot
  2. Führen Sie die App aus:

Die Konsolenausgabe der App, die Fehler anzeigt, wird an die Kudu-Konsole weitergeleitet.

Frameworkabhängige Bereitstellung, die in einem Vorschaurelease ausgeführt wird

Erfordert die Installation der Runtimeerweiterung für ASP.NET Core {VERSION} (x86).

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} ist die Runtimeversion.)
  2. Führen Sie die App aus: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Die Konsolenausgabe der App, in der alle Fehler angezeigt werden, wird per Pipe an die Kudu-Konsole weitergeleitet.

Testen einer 64-Bit-App (x64)

Aktuelles Release

  • Wenn es sich bei der App um eine frameworkabhängige Bereitstellung (64-Bit, x64) handelt:
    1. cd D:\Program Files\dotnet
    2. Führen Sie die App aus: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
  • Wenn es sich bei der App um eine eigenständige Bereitstellung handelt:
    1. cd D:\home\site\wwwroot
    2. Führen Sie die App aus: {ASSEMBLY NAME}.exe

Die Konsolenausgabe der App, in der alle Fehler angezeigt werden, wird per Pipe an die Kudu-Konsole weitergeleitet.

Frameworkabhängige Bereitstellung, die in einem Vorschaurelease ausgeführt wird

Erfordert die Installation der Runtimeerweiterung für ASP.NET Core {VERSION} (x64).

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} ist die Runtimeversion.)
  2. Führen Sie die App aus: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Die Konsolenausgabe der App, die Fehler anzeigt, wird an die Kudu-Konsole weitergeleitet.

stdout-Protokoll im ASP.NET Core-Modul (Azure App Service)

Das stdout-Protokoll des ASP.NET Core-Moduls zeichnet häufig nützliche Fehlermeldungen auf, die nicht im Anwendungsereignisprotokoll enthalten sind. So aktivieren Sie stdout-Protokolle und zeigen diese an:

  1. Navigieren Sie zum Blatt Diagnose und Problembehandlung im Azure-Portal.
  2. Wählen Sie unter SELECT PROBLEM CATEGORY (PROBLEMKATEGORIE WÄHLEN) die Schaltfläche Web App Down (Web-App ausgefallen) aus.
  3. Klicken Sie unter Suggested Solutions (Vorgeschlagene Lösungen) >Enable Stdout Log Redirection (stdout-Protokollumleitung aktivieren) auf Open Kudu Console to edit Web.Config (Kudu-Konsole öffnen, um web.config zu bearbeiten).
  4. Öffnen Sie in der Diagnosekonsole die Ordner unter dem Pfad site>wwwroot. Scrollen Sie nach unten, um die Datei web.config am Ende der Liste einzublenden.
  5. Klicken Sie auf den Bleistift neben der Datei web.config.
  6. Setzen Sie stdoutLogEnabled auf true, und ändern Sie den Pfad stdoutLogFile in: \\?\%home%\LogFiles\stdout.
  7. Wählen Sie Speichern aus, um die aktualisierte Datei web.config zu speichern.
  8. Führen Sie eine Anforderung an die App aus.
  9. Kehren Sie zum Azure-Portal zurück. Wählen Sie das Blatt Erweiterte Tools im Bereich ENTWICKLUNGSTOOLS aus. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  10. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
  11. Wählen Sie den Ordner LogFiles aus.
  12. Überprüfen Sie die Spalte Geändert, und wählen Sie den Bleistift aus, um das stdout-Protokoll mit dem letzten Änderungsdatum zu bearbeiten.
  13. Wenn die Protokolldatei geöffnet wird, wird der Fehler angezeigt.

Deaktivieren Sie die stdout-Protokollierung, wenn die Problembehandlung abgeschlossen ist:

  1. Kehren Sie in der Kudu-Diagnosekonsole zum Pfad site>wwwroot zurück, um die Datei web.config einzublenden. Öffnen Sie die Datei web.config erneut, indem Sie den Bleistift auswählen.
  2. Legen Sie stdoutLogEnabled auf false fest.
  3. Wählen Sie Speichern aus, um die Datei zu speichern.

Weitere Informationen finden Sie im Artikel ASP.NET Core-Modul (ANCM) für IIS:

Warnung

Wenn das stdout-Protokoll nicht deaktiviert wird, können App- oder Serverfehler auftreten. Für die Protokollgröße oder die Anzahl von erstellten Protokolldateien ist kein Grenzwert festgelegt. Verwenden Sie die stdout-Protokollierung nur für die Behandlung von App-Startproblemen.

Verwenden Sie für die allgemeine Protokollierung in einer ASP.NET Core-App nach dem Start eine Protokollierungsbibliothek, die die Protokolldateigröße beschränkt und Protokolle rotiert. Weitere Informationen finden Sie im Artikel zur Protokollierung von Drittanbietern.

Langsame oder nicht reagierende App (Azure App Service)

Wenn eine App langsam reagiert oder auf eine Anfrage nicht reagiert, lesen Sie die folgenden Artikel:

Überwachungsblätter

Überwachungsblätter bieten eine Alternative zur Problembehandlung mit den weiter oben in diesem Thema beschriebenen Methoden. Die Blätter können zur Diagnose von Serie 500-Fehlern verwendet werden.

Vergewissern Sie sich, dass ASP.NET Core-Erweiterungen installiert sind. Wenn die Erweiterungen nicht installiert sind, installieren Sie diese manuell:

  1. Wählen Sie im Blattabschnitt ENTWICKLUNGSTOOLS das Blatt Erweiterungen aus.
  2. Die ASP.NET Core-Erweiterungen werden in der Liste angezeigt.
  3. Wenn die Erweiterungen nicht installiert sind, klicken Sie auf Hinzufügen.
  4. Wählen Sie die ASP.NET Core-Erweiterungen aus der Liste.
  5. Klicken Sie auf OK, um die rechtlichen Bedingungen zu akzeptieren.
  6. Klicken Sie auf OK auf dem Blatt Erweiterung hinzufügen.
  7. Mit einer Popup-Informationsmeldung wird die erfolgreiche Installation der Erweiterungen angezeigt.

Wenn die stdout-Protokollierung nicht aktiviert ist, gehen Sie folgendermaßen vor:

  1. Wählen Sie im Azure-Portal das Blatt Erweiterte Tools im Bereich ENTWICKLUNGSTOOLS aus. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  2. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
  3. Öffnen Sie die Ordner unter dem Pfad site>wwwroot, und scrollen Sie nach unten, um die Datei web.config am Ende der Liste einzublenden.
  4. Klicken Sie auf den Bleistift neben der Datei web.config.
  5. Setzen Sie stdoutLogEnabled auf true, und ändern Sie den Pfad stdoutLogFile in: \\?\%home%\LogFiles\stdout.
  6. Wählen Sie Speichern aus, um die aktualisierte Datei web.config zu speichern.

Fahren Sie mit der Aktivierung der Diagnoseprotokollierung fort:

  1. Wählen Sie im Azure-Portal das Blatt Diagnoseprotokolle aus.
  2. Wählen Sie den Parameter On für Anwendungsprotokollierung (Dateisystem) und Detaillierte Fehlermeldungen aus. Klicken Sie auf Speichern am oberen Rand des Blatts.
  3. Um die Ablaufverfolgung für Anforderungsfehler, auch bekannt als Protokollierung der Anforderungsfehler-Ereignispufferung (FREB), einzuschließen, wählen Sie den Parameter On für Ablaufverfolgung für Anforderungsfehler aus.
  4. Wählen Sie das Blatt Protokollstream aus, das direkt unter dem Blatt Diagnoseprotokolle im Portal angezeigt wird.
  5. Führen Sie eine Anforderung an die App aus.
  6. In den Protokollstreamdaten wird die Ursache des Fehlers angegeben.

Achten Sie darauf, die stdout-Protokollierung zu deaktivieren, wenn die Problembehandlung abgeschlossen ist.

So zeigen Sie die Ablaufverfolgungsprotokolle für Anforderungsfehler (FREB-Protokolle) an:

  1. Navigieren Sie zum Blatt Diagnose und Problembehandlung im Azure-Portal.
  2. Wählen Sie Failed Request Tracing Logs (Ablaufverfolgungsprotokolle für Anforderungsfehler) im Bereich SUPPORTTOOLS der Seitenleiste aus.

Weitere Informationen finden Sie im Abschnitt „Failed request traces“ im Thema „Enable diagnostics logging for apps in Azure App Service“ und unter Häufig gestellte Fragen zur Anwendungsleistung von Web-Apps in Azure: Wie schalte ich die Ablaufverfolgung für Anforderungsfehler ein?

Aktivieren der Diagnoseprotokollierung für Apps in Azure App Service.

Warnung

Wenn das stdout-Protokoll nicht deaktiviert wird, können App- oder Serverfehler auftreten. Für die Protokollgröße oder die Anzahl von erstellten Protokolldateien ist kein Grenzwert festgelegt.

Verwenden Sie für die routinemäßige Protokollierung in einer ASP.NET Core-App eine Protokollierungsbibliothek, die die Protokolldateigröße beschränkt und die Protokolle rotiert. Weitere Informationen finden Sie im Artikel zur Protokollierung von Drittanbietern.

Problembehandlung bei den Internetinformationsdiensten (IIS)

Anwendungsereignisprotokoll (IIS)

Greifen Sie auf das Anwendungsereignisprotokoll zu:

  1. Öffnen Sie das Startmenü, suchen Sie nach der Ereignisanzeige, und wählen Sie dann die App Ereignisanzeige aus.
  2. Öffnen Sie unter Ereignisanzeige den Knoten Windows-Protokolle.
  3. Wählen Sie Anwendung aus, um das Anwendungsereignisprotokoll zu öffnen.
  4. Suchen Sie nach Fehlern, die mit der fehlerhaften App im Zusammenhang stehen. Fehler weisen in der Spalte Quelle den Wert IIS AspNetCore-Modul oder IIS Express AspNetCore-Modul auf.

Ausführen der App in einer Eingabeaufforderung

Viele Startfehler erzeugen keine nützlichen Informationen im Anwendungsereignisprotokoll. Sie können die Ursache für einige Fehler ermitteln, indem Sie die App in einer Eingabeaufforderung auf dem Hostsystem ausführen.

Framework-abhängige Bereitstellung

Wenn es sich bei der App um eine Framework-abhängige Bereitstellung handelt:

  1. Navigieren Sie in einer Eingabeaufforderung zum Bereitstellungsordner und führen Sie die App aus, indem Sie die Assembly der App mit dotnet.exe ausführen. Ersetzen Sie in folgendem Befehl den Namen der Assembly der App durch<assembly_name>: dotnet .\<assembly_name>.dll.
  2. Die Konsolenausgabe der App, die Fehler anzeigt, wird in das Konsolenfenster geschrieben.
  3. Wenn der Fehler während einer Anforderung an die App auftritt, führen Sie eine Anforderung an den Host und Port aus, auf dem Kestrel empfangsbereit ist. Führen Sie unter Verwendung der Standardhosts und -ports eine Anforderung für http://localhost:5000/ aus. Wenn die App normalerweise auf die Kestrel-Endpunktadresse reagiert, ist die Problemursache wahrscheinlich die Hostingkonfiguration (anstelle der App).

Eigenständige Bereitstellung

Wenn es sich bei der App um eine eigenständige Bereitstellung handelt:

  1. Navigieren Sie in einer Eingabeaufforderung zum Bereitstellungsordner und führen Sie die ausführbaren Dateien der App aus. Ersetzen Sie in folgendem Befehl den Namen der Assembly der App durch <assembly_name>: <assembly_name>.exe.
  2. Die Konsolenausgabe der App, die Fehler anzeigt, wird in das Konsolenfenster geschrieben.
  3. Wenn der Fehler während einer Anforderung an die App auftritt, führen Sie eine Anforderung an den Host und Port aus, auf dem Kestrel empfangsbereit ist. Führen Sie unter Verwendung der Standardhosts und -ports eine Anforderung für http://localhost:5000/ aus. Wenn die App normalerweise auf die Kestrel-Endpunktadresse reagiert, ist die Problemursache wahrscheinlich die Hostingkonfiguration (anstelle der App).

stdout-Protokoll des ASP.NET Core-Moduls (IIS)

So aktivieren Sie stdout-Protokolle und zeigen diese an:

  1. Navigieren Sie zum Bereitstellungsordner der Website auf dem Hostsystem.
  2. Erstellen Sie den Ordner logs, wenn dieser nicht vorhanden ist. Anweisungen zum Aktivieren von MSBuild für die automatische Erstellung des Ordners logs in der Bereitstellung finden Sie im Thema Verzeichnisstruktur.
  3. Bearbeiten Sie die Datei web.config. Legen Sie stdoutLogEnabled auf true fest, und ändern Sie den Pfad von stdoutLogFile so, dass auf den Ordner logs verwiesen wird (Beispiel: .\logs\stdout). stdout im Pfad ist das Präfix des Protokolldateinamens. Ein Zeitstempel, eine Prozess-ID und eine Dateierweiterung werden bei der Protokollerstellung automatisch hinzugefügt. Mit stdout als Präfix des Dateinamens wird eine typische Protokolldatei als stdout_20180205184032_5412.log benannt.
  4. Stellen Sie sicher, dass die Identität des Anwendungspools über Schreibberechtigungen für den Ordner Protokolle verfügt.
  5. Speichern Sie die aktualisierte Datei web.config.
  6. Führen Sie eine Anforderung an die App aus.
  7. Navigieren Sie zu dem Ordner logs. Suchen und öffnen Sie das aktuelle stdout-Protokoll.
  8. Untersuchen Sie das Protokoll auf Fehler.

Deaktivieren Sie die stdout-Protokollierung, wenn die Problembehandlung abgeschlossen ist:

  1. Bearbeiten Sie die Datei web.config.
  2. Legen Sie stdoutLogEnabled auf false fest.
  3. Speichern Sie die Datei.

Weitere Informationen finden Sie im Artikel ASP.NET Core-Modul (ANCM) für IIS:

Warnung

Wenn das stdout-Protokoll nicht deaktiviert wird, können App- oder Serverfehler auftreten. Für die Protokollgröße oder die Anzahl von erstellten Protokolldateien ist kein Grenzwert festgelegt.

Verwenden Sie für die routinemäßige Protokollierung in einer ASP.NET Core-App eine Protokollierungsbibliothek, die die Protokolldateigröße beschränkt und die Protokolle rotiert. Weitere Informationen finden Sie im Artikel zur Protokollierung von Drittanbietern.

Aktivieren der Seite mit Ausnahmen für Entwickler

Die ASPNETCORE_ENVIRONMENT Umgebungsvariable kann zur Datei web.config hinzugefügt werden, um die App in der Entwicklungsumgebung auszuführen. Solange die Umgebung nicht beim Starten der App von UseEnvironment im Host-Builder außer Kraft gesetzt wird, kann die Seite mit Ausnahmen für Entwickler durch Festlegen der Umgebungsvariable angezeigt werden, wenn die App ausgeführt wird.

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

Das Festlegen der Umgebungsvariablen für ASPNETCORE_ENVIRONMENT wird nur bei der Verwendung von Staging- und Testservern empfohlen, die nicht für das Internet verfügbar gemacht werden. Entfernen Sie nach der Fehlerbehebung die Umgebungsvariable aus der Datei web.config. Informationen zum Festlegen von Umgebungsvariablen in der Datei web.config finden Sie unter Untergeordnetes environmentVariables-Element von aspNetCore.

Abrufen von Daten aus einer App

Wenn eine App in der Lage sind, auf Anforderungen zu reagieren, erhalten Sie Anforderungen, Verbindungen und zusätzliche Daten von den Apps über die Inlinemiddleware des Terminals. Weitere Informationen und Beispielcode finden Sie unter Problembehandlung und Debuggen von ASP.NET Core-Projekten.

Langsame oder nicht reagierende App (IIS)

Ein Absturzabbild ist eine Momentaufnahme des Systemarbeitsspeichers, die Ihnen dabei behilflich sein kann, die Ursache eines App-Absturzes, eines Startfehlers oder einer langsamen App zu ermitteln.

App stürzt ab, oder es tritt eine Ausnahme auf

Abrufen und Analysieren eines Speicherabbilds aus der Windows-Fehlerberichterstattung (WER):

  1. Erstellen Sie einen Ordner zum Speichern von Absturzabbilddateien unter c:\dumps. Der App-Pool muss über Schreibzugriff auf den Ordner verfügen.

  2. Führen Sie das PowerShell-Skript „EnableDumps“ aus:

    • Wenn die App das In-Process-Hostingmodell verwendet, führen Sie das Skript für w3wp.exe aus:

      .\EnableDumps w3wp.exe c:\dumps

    • Wenn die App das Out-of-Process-Hostingmodell verwendet, führen Sie das Skript für dotnet.exe aus:

      .\EnableDumps dotnet.exe c:\dumps

  3. Führen Sie die App unter den Bedingungen aus, die dazu führen, dass der Absturz auftritt.

  4. Nachdem der Absturz stattgefunden hat, führen Sie das PowerShell-Skript „DisableDumps“ aus:

Nachdem eine Anwendung abgestürzt ist und die Absturzabbildsammlung abgeschlossen ist, kann die App ordnungsgemäß beendet werden. Das PowerShell-Skript konfiguriert WER für die Erfassung von bis zu fünf Absturzabbildern pro App.

Warnung

Absturzabbilder können eine große Menge Speicherplatz in Anspruch nehmen (jeweils bis zu mehreren GB).

Die App reagiert nicht, schlägt während des Starts fehl oder wird normal ausgeführt.

Wenn eine App nicht mehr reagiert, aber nicht abstürzt, beim Start fehlschlägt oder normal läuft, finden Sie unter Benutzermodus-Dumpdateien: Auswählen des besten Tools ein geeignetes Tool zur Erstellung des Speicherabbilds.

Analysieren des Speicherabbilds

Ein Speicherabbild kann mithilfe mehrerer Ansätze analysiert werden. Weitere Informationen finden Sie unter Analysieren einer Benutzermodus-Speicherabbilddatei.

Bereinigen der Paketcaches

Eine funktionsfähige App kann direkt nach der Durchführung eines Upgrades für das .NET Core SDK auf dem Entwicklungscomputer oder einer Änderung der Paketversionen in der App fehlschlagen. In einigen Fällen können inkohärente Pakete eine App beschädigen, wenn größere Upgrades durchgeführt werden. Die meisten dieser Probleme können durch Befolgung der folgenden Anweisungen behoben werden:

  1. Löschen Sie die Ordner bin und obj.

  2. Bereinigen Sie die Paketcaches, indem Sie dotnet nuget locals all --clear über eine Befehlsshell ausführen.

    Sie können die Paketcaches auch mit dem Tool nuget.exe und dem Befehl nuget locals all -clear bereinigen. nuget.exe ist wird unter dem Windows Desktop-Betriebssystem nicht gebündelt installiert und muss separat von der NuGet-Website abgerufen werden.

  3. Stellen Sie das Projekt wieder her und erstellen Sie es neu.

  4. Löschen Sie alle Dateien im Bereitstellungsordner auf dem Server, bevor Sie die App noch mal bereitstellen.

Zusätzliche Ressourcen

Azure-Dokumentation

Visual Studio-Dokumentation

Dokumentation zu Visual Studio Code

Dieser Artikel enthält Informationen über häufige Fehler beim Starten von Apps und Anweisungen zur Fehlerdiagnose bei der Bereitstellung einer App für den Azure App Service oder für IIS:

App-Startfehler
Erläutert allgemeine HTTP-Statuscodeszenarien.

Problembehandlung in Azure App Service
Bietet Ratschläge zur Problembehandlung für Apps, die in Azure App Service bereitgestellt werden.

Problembehandlung bei den Internetinformationsdiensten (IIS)
Bietet Ratschläge zur Problembehandlung für Apps, die in IIS bereitgestellt oder lokal unter IIS Express ausgeführt werden. Die Anleitung gilt sowohl für Windows Server- als auch für Windows-Desktopbereitstellungen.

Bereinigen der Paketcaches
Erläutert die zu erledigenden Aktionen, wenn inkohärente Pakete eine App beim Durchführen größerer Upgrades oder beim Ändern von Paketversionen beschädigen.

Zusätzliche Ressourcen
Listet weitere Themen zur Problembehandlung auf.

App-Startfehler

In Visual Studio ist Kestrel der ASP.NET Core-Projektstandardserver. Visual Studio kann für die Verwendung von IIS Express konfiguriert werden. Ein 502.5: Prozessfehler oder 500.30: Startfehler, der beim lokalen Debuggen mit IIS Express auftritt, kann mithilfe der Hinweise in diesem Thema diagnostiziert werden.

403.14 Unzulässig

Die App startet nicht. Der folgende Fehler wird protokolliert:

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

Der Fehler wird in der Regel durch eine fehlerhafte Bereitstellung auf dem Hostsystem verursacht, wozu eines der folgenden Szenarien gehört:

  • Die App wird im falschen Ordner auf dem Hostsystem bereitgestellt.
  • Der Bereitstellungsprozess konnte nicht alle Dateien und Ordner der App in den Bereitstellungsordner auf dem Hostsystem verschieben.
  • Die Datei web.config fehlt bei der Bereitstellung, oder der Inhalt der Datei web.config ist falsch formatiert.

Führen Sie die folgenden Schritte aus:

  1. Löschen Sie alle Dateien und Ordner aus dem Bereitstellungsordner auf dem Hostsystem.
  2. Stellen Sie den Inhalt des Ordners publish der App mit Ihrer normalen Bereitstellungsmethode wie Visual Studio, PowerShell oder über die manuelle Bereitstellung erneut auf dem Hostsystem bereit:
    • Bestätigen Sie, dass die Datei web.config in der Bereitstellung vorhanden und ihr Inhalt korrekt ist.
    • Wenn Sie in Azure App Service hosten, bestätigen Sie, dass die App im Ordner D:\home\site\wwwroot bereitgestellt wird.
    • Wenn die App von IIS gehostet wird, bestätigen Sie, dass die App im physischen Pfad von IIS bereitgestellt wird, der in den grundlegenden Einstellungen des IIS-Managers angezeigt wird.
  3. Bestätigen Sie, dass alle Dateien und Ordner der App bereitgestellt werden, indem Sie die Bereitstellung auf dem Hostsystem mit dem Inhalt des Ordners publish des Projekts vergleichen.

Weitere Informationen zum Layout einer veröffentlichten ASP.NET Core-App finden Sie unter ASP.NET Core-Verzeichnisstruktur. Weitere Informationen zur Datei web.config finden Sie unter ASP.NET Core-Modul (ANCM) für IIS.

500: Interner Serverfehler

Die App wird gestartet, aber ein Fehler verhindert, dass der Server auf die Anforderung eingeht.

Dieser Fehler tritt im Code der App während des Starts oder bei der Erstellung einer Antwort auf. Die Antwort enthält möglicherweise keinen Inhalt oder die Antwort wird als 500: Interner Serverfehler im Browser angezeigt. Das Anwendungsereignisprotokoll gibt normalerweise an, dass die Anwendung normal gestartet wurde. Aus Sicht des Servers ist dies richtig. Die App wurde gestartet, aber sie kann keine gültige Antwort generieren. Führen Sie die App in einer Eingabeaufforderung auf dem Server aus oder aktivieren Sie das stdout-Protokoll des ASP.NET Core-Moduls, um das Problem zu beheben.

Dieser Fehler kann auch auftreten, wenn das .NET Core-Hostingpaket nicht installiert oder beschädigt ist. Durch die Installation oder Reparatur der Installation des .NET Core-Hostingpakets (für IIS) oder Visual Studio (für IIS Express) kann das Problem behoben werden.

500.0: Fehler beim Laden des prozessinternen Handlers

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Beim Laden von Komponenten des ASP.NET Core-Moduls ist ein unbekannter Fehler aufgetreten. Führen Sie eine der folgenden Aktionen aus:

  • Wenden Sie sich an den Microsoft-Support (über Entwicklertools > ASP.NET Core).
  • Stellen Sie Ihre Frage auf Stack Overflow.
  • Melden Sie das Problem im GitHub-Repository.

500.30: Prozessinterner Startupfehler

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Das ASP.NET Core-Modul kann den .NET Core-CLR-In-Process nicht starten. Die Ursache für einen Fehler beim Starten eines Prozesses kann in der Regel über Einträge im Anwendungsereignisprotokoll und im stdout-Protokoll des ASP.NET Core-Moduls ermittelt werden.

Häufige Fehlerbedingungen:

  • Die App ist aufgrund einer Version des freigegebenen ASP.NET Core-Frameworks falsch konfiguriert ist, die nicht vorhanden ist. Überprüfen Sie, welche Versionen des freigegebenen ASP.NET Core-Frameworks auf dem Zielcomputer installiert sind.
  • Bei Verwendung von Azure Key Vault fehlen die Berechtigungen für den Schlüsseltresor. Überprüfen Sie die Zugriffsrichtlinien im angestrebten Schlüsseltresor, um sicherzustellen, dass die richtigen Berechtigungen gewährt werden.

500.31: Fehler bei der Suche nach nativen Abhängigkeiten in ANCM

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Das ASP.NET Core-Modul kann die prozessinterne .NET Core-Runtime nicht starten. Die häufigste Ursache dieses Startfehlers ist die fehlende Installation der Laufzeiten Microsoft.NETCore.App oder Microsoft.AspNetCore.App. Dieser Fehler tritt auf, wenn die App für die Zielversion 3.0 von ASP.NET Core bereitgestellt wurde, die aber auf dem Computer nicht vorhanden ist. Es wird beispielsweise folgende Fehlermeldung angezeigt:

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]

In der Fehlermeldung werden alle installierten .NET Core-Versionen aufgelistet sowie die für die App erforderliche Version. Sie haben folgende Möglichkeiten, um diesen Fehler zu beheben:

  • Installieren Sie die entsprechende .NET Core-Version auf Ihrem Computer.
  • Ändern Sie die Zielversion der App in eine .NET Core-Version, die auf Ihrem Computer vorhanden ist.
  • Veröffentlichen Sie die App als eine eigenständige Bereitstellung.

Beim Ausführen im Entwicklungsmodus (wenn die Umgebungsvariable ASPNETCORE_ENVIRONMENT auf Development festgelegt ist) wird der jeweilige Fehler in die HTTP-Antwort geschrieben. Die Ursache für einen Fehler beim Starten eines Prozesses kann auch über das Anwendungsereignisprotokoll ermittelt werden.

500.32: Fehler beim Laden der DLL in ANCM

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Die häufigste Ursache für diesen Fehler ist die Veröffentlichung der App für eine nicht kompatible Prozessorarchitektur. Der Fehler tritt auf, wenn der Arbeitsprozess als 32-Bit-App ausgeführt wird, die App aber für eine 64-Bit-Ausführung veröffentlicht wurde.

Sie haben folgende Möglichkeiten, um diesen Fehler zu beheben:

  • Veröffentlichen Sie die App erneut, sodass Prozessorarchitektur und Arbeitsprozess übereinstimmen.
  • Veröffentlichen Sie die App als eine Framework-abhängige Bereitstellung.

500.33: Fehler beim Laden des Anforderungshandlers in ANCM

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Die App verweist nicht auf das Framework Microsoft.AspNetCore.App. Das ASP.NET Core-Modul hostet nur Apps mit Microsoft.AspNetCore.App als Zielframework.

Vergewissern Sie sich, dass das Zielframework der App Microsoft.AspNetCore.App ist, um den Fehler zu beheben. Überprüfen Sie .runtimeconfig.json, um das Zielframework der App anzuzeigen.

500.34: Gemischte Hostingmodelle in ANCM nicht unterstützt

Im selben Arbeitsprozess können nicht gleichzeitig eine In-Process- und eine Out-of-Process-App ausgeführt werden.

Führen Sie die Apps in separaten IIS-Anwendungspools aus, um diesen Fehler zu beheben.

500.35: Mehrere In-Process-Anwendungen im selben Prozess in ANCM

Der Workerprozess kann nicht mehrere prozessinterne Apps im selben Prozess ausführen.

Führen Sie die Apps in separaten IIS-Anwendungspools aus, um diesen Fehler zu beheben.

500.36: Fehler beim Laden des Out-of-Process-Handlers in ANCM

Der Out-of-Process-Anforderungshandler aspnetcorev2_outofprocess.dll befindet sich nicht neben der Datei aspnetcorev2.dll. Dies deutet auf eine fehlerhafte Installation des ASP.NET Core-Moduls hin.

Reparieren Sie die Installation des .NET Core-Hostingpakets (für IIS) oder von Visual Studio (für IIS Express), um diesen Fehler zu beheben.

500.37: Fehler beim Starten von ANCM innerhalb des Zeitlimits für den Start

ANCM konnte nicht innerhalb des angegebenen Zeitlimits für den Start gestartet werden. Das Standardzeitlimit beträgt 120 Sekunden.

Dieser Fehler kann beim Starten einer großen Anzahl von Apps auf dem gleichen Computer auftreten. Überprüfen Sie, ob beim Starten CPU-/Speicherauslastungsspitzen auf dem Server vorhanden sind. In diesem Fall sollten Sie möglicherweise den Startvorgang einiger Apps staffeln.

500.38 ANCM-Anwendungs-DLL nicht gefunden.

Das ANCM konnte die Anwendungs-DLL nicht finden, die sich neben der ausführbaren Datei befinden sollte.

Dieser Fehler tritt auf, wenn eine als einzelne ausführbare Datei gepackte App mithilfe des In-Process-Hostingmodells gehostet wird. Das In-Process-Modell erfordert, dass das ANCM die .NET Core-App in den vorhandenen IIS-Prozess lädt. Dieses Szenario wird vom Einzeldatei-Bereitstellungsmodell nicht unterstützt. Verwenden Sie einen der folgenden Ansätze in der Projektdatei der App, um diesen Fehler zu korrigieren:

  1. Deaktivieren Sie die Einzeldateiveröffentlichung, indem Sie die MSBuild-Eigenschaft PublishSingleFile auf false festlegen.
  2. Wechseln Sie zum Out-of-Process-Hostingmodell, indem Sie die MSBuild-Eigenschaft AspNetCoreHostingModel auf OutOfProcess festlegen.

502.5: Prozessfehler

Der Workerprozess schlägt fehl. Die App wird nicht gestartet.

Das ASP.NET Core-Modul kann den Workerprozess nicht starten. Die Ursache für einen Fehler beim Starten eines Prozesses kann in der Regel über Einträge im Anwendungsereignisprotokoll und im stdout-Protokoll des ASP.NET Core-Moduls ermittelt werden.

Eine allgemeine Fehlerbedingung ist, dass die App aufgrund einer Version des freigegebenen ASP.NET Core-Frameworks falsch konfiguriert ist, die nicht vorhanden ist. Überprüfen Sie, welche Versionen des freigegebenen ASP.NET Core-Frameworks auf dem Zielcomputer installiert sind. Das freigegebene Framework ist der Satz der Assemblys (DLL-Dateien), die auf dem Computer installiert werden und auf die ein Metapaket wie Microsoft.AspNetCore.App verweist. Der Metapaketverweis kann eine mindestens erforderliche Version angeben. Weitere Informationen finden Sie unter The shared framework (Das freigegebene Framework).

Die Fehlerseite 502.5: Prozessfehler wird zurückgegeben, wenn ein falsch konfiguriertes Hosting oder eine falsch konfigurierte App bewirkt, dass der Workerprozess fehlschlägt:

Fehler beim Starten der Anwendung (ErrorCode 0x800700c1)

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

Die App konnte nicht gestartet werden, weil die Assembly der App ( .dll) nicht geladen werden konnte.

Dieser Fehler tritt bei einem Bitanzahlkonflikt zwischen der veröffentlichten App und dem w3wp/iisexpress-Prozess auf.

Überprüfen Sie, ob die 32-Bit-Einstellung des Anwendungspools korrekt ist:

  1. Wählen Sie im IIS-Manager unter Anwendungspools den Anwendungspool aus.
  2. Wählen Sie im Bereich Aktionen unter Anwendungspool bearbeitenErweiterte Einstellungen aus.
  3. Wählen Sie 32-Bit-Anwendungen aktivieren aus:
    • Wenn Sie eine 32-Bit-(x86)-App bereitstellen, legen Sie den Wert auf True fest.
    • Wenn Sie eine 64-Bit-(x64)-App bereitstellen, legen Sie den Wert auf False fest.

Bestätigen Sie, dass es keinen Konflikt zwischen einer <Platform> MSBuild-Eigenschaft in der Projektdatei und der veröffentlichten Bitanzahl der App gibt.

Fehler beim Starten der Anwendung (Fehlercode „0x800701b1“)

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

Die App konnte nicht gestartet werden, da ein Windows-Dienst nicht geladen werden konnte.

Ein allgemeiner Dienst, der aktiviert werden muss, ist der „NULL“-Dienst. Mit dem folgenden Befehl wird der Windows-Dienst „null“ aktiviert:

sc.exe start null

Verbindungszurücksetzung

Falls ein Fehler auftritt, nachdem die Header gesendet wurden, ist es zu spät für den Server, einen 500: Interner Serverfehler zu senden, wenn ein Fehler auftritt. Dies ist häufig der Fall, wenn während der Serialisierung komplexer Objekte für eine Antwort ein Fehler auftritt. Diese Art von Fehler wird angezeigt, wenn ein Verbindungszurücksetzungsfehler auf dem Client auftritt. Mithilfe der Anwendungsprotokollierung können diese Fehlertypen behoben werden.

Standardstarteinschränkungen

Das ASP.NET Core-Modul wurde mit dem Standardwert 120 Sekunden für das startupTimeLimit konfiguriert. Wenn der Standardwert beibehalten wird, dauert der Start einer App möglicherweise bis zu zwei Minuten. Erst danach kann das Modul einen Prozessfehler protokollieren. Weitere Informationen zum Konfigurieren des Moduls finden Sie unter Attribute des aspNetCore-Elements.

Problembehandlung in Azure App Service

Wichtig

ASP.NET Core-Vorschauversion mit Azure App Service

ASP.NET Core-Vorschauversionen werden nicht standardmäßig in Azure App Service bereitgestellt. Weitere Informationen zum Hosten einer App, die eine ASP.NET Core-Vorschauversion verwendet, finden Sie unter Deploy ASP.NET Core preview release to Azure App Service (Bereitstellen der ASP.NET Core-Vorschauversion in Azure App Service).

Azure App Service-Protokollstream

Die Azure App Service-Protokollstreams protokollieren Informationen, sobald sie aufkommen. So zeigen Sie Streamingprotokolle an:

  1. Öffnen Sie die App im Azure-Portal unter App Services.
  2. Navigieren Sie im linken Bereich zu Überwachung>App Service-Protokolle. App Service-Protokolle
  3. Wählen Sie Dateisystem für Webserverprotokollierung aus. Aktivieren Sie optional die Anwendungsprotokollierung. Protokollierung aktivieren
  4. Navigieren Sie im linken Bereich zu Überwachung>Protokollstream, und wählen Sie dann Anwendungsprotokolle oder Webserverprotokolle aus.

Überwachung > Protokollstream

Die folgenden Abbildungen zeigen die Ausgabe der Anwendungsprotokolle:

App-Protokolle

Streamingprotokolle haben eine etwas höhere Latenz und werden möglicherweise nicht sofort angezeigt.

Anwendungsereignisprotokoll (Azure App Service)

Verwenden Sie das Blatt Diagnose und Problembehandlung im Azure-Portal, um auf das Anwendungsereignisprotokoll zuzugreifen:

  1. Öffnen Sie die App im Azure-Portal unter App Services.
  2. Klicken Sie auf Diagnose und Problembehandlung.
  3. Wählen Sie die Überschrift Diagnosetools aus.
  4. Klicken Sie unter Supporttools auf die Schaltfläche Anwendungsereignisse.
  5. Überprüfen Sie den letzten vom Eintrag IIS AspNetCoreModule oder IIS AspNetCoreModule V2 in der Spalte Quelle angegebenen Fehler.

Anstatt das Blatt Diagnose und Problembehandlung zu verwenden, können Sie die Anwendungsereignisprotokoll-Datei auch direkt mit Kudu untersuchen:

  1. Öffnen Sie Erweiterte Tools im Bereich Entwicklungstools. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  2. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
  3. Öffnen Sie den Ordner LogFiles.
  4. Wählen Sie den Bleistift neben der Datei eventlog.xml aus.
  5. Untersuchen Sie das Protokoll. Scrollen Sie zum Ende des Protokolls, um die aktuellsten Ereignisse anzuzeigen.

Führen Sie die App in der Kudu-Konsole aus

Viele Startfehler erzeugen keine nützlichen Informationen im Anwendungsereignisprotokoll. Sie können die App in der Kudu-Remote-Ausführungskonsole ausführen, um den Fehler zu ermitteln:

  1. Öffnen Sie Erweiterte Tools im Bereich Entwicklungstools. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  2. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.

Testen einer 32-Bit-App (x86)

Aktuelles Release

  1. cd d:\home\site\wwwroot
  2. Führen Sie die App aus:

Die Konsolenausgabe der App, die Fehler anzeigt, wird an die Kudu-Konsole weitergeleitet.

Frameworkabhängige Bereitstellung, die in einem Vorschaurelease ausgeführt wird

Erfordert die Installation der Runtimeerweiterung für ASP.NET Core {VERSION} (x86).

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} ist die Runtimeversion.)
  2. Führen Sie die App aus: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Die Konsolenausgabe der App, in der alle Fehler angezeigt werden, wird per Pipe an die Kudu-Konsole weitergeleitet.

Testen einer 64-Bit-App (x64)

Aktuelles Release

  • Wenn es sich bei der App um eine frameworkabhängige Bereitstellung (64-Bit, x64) handelt:
    1. cd D:\Program Files\dotnet
    2. Führen Sie die App aus: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
  • Wenn es sich bei der App um eine eigenständige Bereitstellung handelt:
    1. cd D:\home\site\wwwroot
    2. Führen Sie die App aus: {ASSEMBLY NAME}.exe

Die Konsolenausgabe der App, in der alle Fehler angezeigt werden, wird per Pipe an die Kudu-Konsole weitergeleitet.

Frameworkabhängige Bereitstellung, die in einem Vorschaurelease ausgeführt wird

Erfordert die Installation der Runtimeerweiterung für ASP.NET Core {VERSION} (x64).

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} ist die Runtimeversion.)
  2. Führen Sie die App aus: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Die Konsolenausgabe der App, die Fehler anzeigt, wird an die Kudu-Konsole weitergeleitet.

stdout-Protokoll im ASP.NET Core-Modul (Azure App Service)

Warnung

Wenn das stdout-Protokoll nicht deaktiviert wird, können App- oder Serverfehler auftreten. Für die Protokollgröße oder die Anzahl von erstellten Protokolldateien ist kein Grenzwert festgelegt. Verwenden Sie die stdout-Protokollierung nur für die Behandlung von App-Startproblemen.

Verwenden Sie für die allgemeine Protokollierung in einer ASP.NET Core-App nach dem Start eine Protokollierungsbibliothek, die die Protokolldateigröße beschränkt und Protokolle rotiert. Weitere Informationen finden Sie im Artikel zur Protokollierung von Drittanbietern.

Das stdout-Protokoll des ASP.NET Core-Moduls zeichnet häufig nützliche Fehlermeldungen auf, die nicht im Anwendungsereignisprotokoll enthalten sind. So aktivieren Sie stdout-Protokolle und zeigen diese an:

  1. Navigieren Sie im Azure-Portal zur Web-App.
  2. Geben Sie auf dem Blatt App Service in das Suchfeld kudu ein.
  3. Wählen Sie Erweiterte Tools>Los aus.
  4. Wählen Sie Debugkonsole > CMD aus.
  5. Navigieren Sie zu site/wwwroot.
  6. Klicken Sie auf das Bleistiftsymbol, um die Datei web.config zu bearbeiten.
  7. Legen Sie im <aspNetCore />-Element stdoutLogEnabled="true" fest, und klicken Sie dann auf Speichern.

Deaktivieren Sie die stdout-Protokollierung, wenn die Problembehandlung abgeschlossen ist, indem Sie stdoutLogEnabled="false" festlegen.

Weitere Informationen finden Sie im Artikel ASP.NET Core-Modul (ANCM) für IIS:

Debugprotokoll im ASP.NET Core-Modul (Azure App Service)

Das Debugprotokoll des ASP.NET Core-Moduls ermöglicht die zusätzliche und ausführlichere Protokollierung über das ASP.NET Core-Modul. So aktivieren Sie stdout-Protokolle und zeigen diese an:

  1. Führen Sie einen der folgenden Schritte aus, um das erweiterte Diagnoseprotokoll zu aktivieren:
    • Befolgen Sie den Anweisungen in den erweiterten Diagnoseprotokollen, um die App für die erweiterte Diagnoseprotokollierung zu konfigurieren. Stellen Sie die App erneut bereit.
    • Fügen Sie die in unter Erweiterte Diagnoseprotokollen enthaltene <handlerSettings>-Klasse für die web.config-Datei der Live-App über die Kudu-Konsole hinzu:
      1. Öffnen Sie Erweiterte Tools im Bereich Entwicklungstools. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
      2. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
      3. Öffnen Sie die Ordner unter dem Pfad site>wwwroot. Bearbeiten Sie die Datei web.config, indem Sie auf die Bleistiftschaltfläche klicken. Fügen Sie den Abschnitt <handlerSettings> wie in den erweiterten Diagnoseprotokollen dargestellt hinzu. Klicken Sie auf die Schaltfläche Speichern.
  2. Öffnen Sie Erweiterte Tools im Bereich Entwicklungstools. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  3. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
  4. Öffnen Sie die Ordner unter dem Pfad site>wwwroot. Wenn Sie keinen Pfad für die aspnetcore-debug.log-Datei angegeben haben, wird die Datei in der Liste aufgeführt. Wenn Sie jedoch einen Pfad angegeben haben, navigieren Sie zum Speicherort der Protokolldatei.
  5. Öffnen Sie die Protokolldatei über die Bleistiftschaltfläche neben dem Dateinamen.

Deaktivieren Sie die Debugprotokollierung, wenn die Problembehandlung abgeschlossen ist.

Führen Sie einen der folgenden Schritte aus, um das erweiterte Debugprotokoll zu deaktivieren:

  • Entfernen Sie <handlerSettings> aus der lokalen web.config-Datei, und stellen Sie die App erneut bereit.
  • Verwenden Sie die Kudu-Konsole, um die web.config-Datei zu bearbeiten und den Abschnitt <handlerSettings> zu entfernen. Speichern Sie die Datei.

Weitere Informationen finden Sie unter Protokollerstellung und -umleitung mit dem ASP.NET Core-Modul.

Warnung

Wenn das Debugprotokoll nicht deaktiviert werden kann, können App- oder Serverfehler auftreten. Es gibt keine Begrenzung für die Größe der Protokolldatei. Nutzen Sie die Debugprotokollierung nur für die Behandlung von App-Startproblemen.

Verwenden Sie für die allgemeine Protokollierung in einer ASP.NET Core-App nach dem Start eine Protokollierungsbibliothek, die die Protokolldateigröße beschränkt und Protokolle rotiert. Weitere Informationen finden Sie im Artikel zur Protokollierung von Drittanbietern.

Langsame oder nicht reagierende App (Azure App Service)

Wenn eine App langsam reagiert oder auf eine Anfrage nicht reagiert, lesen Sie den Artikel Fehlerbehebung bei Problemen mit der Leistung langsamer Web-Apps in Azure App Service.

Überwachungsblätter

Überwachungsblätter bieten eine Alternative zur Problembehandlung mit den weiter oben in diesem Thema beschriebenen Methoden. Die Blätter können zur Diagnose von Serie 500-Fehlern verwendet werden.

Vergewissern Sie sich, dass ASP.NET Core-Erweiterungen installiert sind. Wenn die Erweiterungen nicht installiert sind, installieren Sie diese manuell:

  1. Wählen Sie im Blattabschnitt ENTWICKLUNGSTOOLS das Blatt Erweiterungen aus.
  2. Die ASP.NET Core-Erweiterungen werden in der Liste angezeigt.
  3. Wenn die Erweiterungen nicht installiert sind, klicken Sie auf Hinzufügen.
  4. Wählen Sie die ASP.NET Core-Erweiterungen aus der Liste.
  5. Klicken Sie auf OK, um die rechtlichen Bedingungen zu akzeptieren.
  6. Klicken Sie auf OK auf dem Blatt Erweiterung hinzufügen.
  7. Mit einer Popup-Informationsmeldung wird die erfolgreiche Installation der Erweiterungen angezeigt.

Wenn die stdout-Protokollierung nicht aktiviert ist, gehen Sie folgendermaßen vor:

  1. Wählen Sie im Azure-Portal das Blatt Erweiterte Tools im Bereich ENTWICKLUNGSTOOLS aus. Klicken Sie auf die SchaltflächeLos→. Die Kudu-Konsole wird in einer neuen Browserregisterkarte oder in einem neuen Fenster geöffnet.
  2. Öffnen Sie mithilfe der Navigationsleiste am oberen Rand der Seite die Debugging-Konsole, und wählen Sie CMD aus.
  3. Öffnen Sie die Ordner unter dem Pfad site>wwwroot, und scrollen Sie nach unten, um die Datei web.config am Ende der Liste einzublenden.
  4. Klicken Sie auf den Bleistift neben der Datei web.config.
  5. Setzen Sie stdoutLogEnabled auf true, und ändern Sie den Pfad stdoutLogFile in: \\?\%home%\LogFiles\stdout.
  6. Wählen Sie Speichern aus, um die aktualisierte Datei web.config zu speichern.

Fahren Sie mit der Aktivierung der Diagnoseprotokollierung fort:

  1. Wählen Sie im Azure-Portal das Blatt Diagnoseprotokolle aus.
  2. Wählen Sie den Parameter On für Anwendungsprotokollierung (Dateisystem) und Detaillierte Fehlermeldungen aus. Klicken Sie auf Speichern am oberen Rand des Blatts.
  3. Um die Ablaufverfolgung für Anforderungsfehler, auch bekannt als Protokollierung der Anforderungsfehler-Ereignispufferung (FREB), einzuschließen, wählen Sie den Parameter On für Ablaufverfolgung für Anforderungsfehler aus.
  4. Wählen Sie das Blatt Protokollstream aus, das direkt unter dem Blatt Diagnoseprotokolle im Portal angezeigt wird.
  5. Führen Sie eine Anforderung an die App aus.
  6. In den Protokollstreamdaten wird die Ursache des Fehlers angegeben.

Achten Sie darauf, die stdout-Protokollierung zu deaktivieren, wenn die Problembehandlung abgeschlossen ist.

So zeigen Sie die Ablaufverfolgungsprotokolle für Anforderungsfehler (FREB-Protokolle) an:

  1. Navigieren Sie zum Blatt Diagnose und Problembehandlung im Azure-Portal.
  2. Wählen Sie Failed Request Tracing Logs (Ablaufverfolgungsprotokolle für Anforderungsfehler) im Bereich SUPPORTTOOLS der Seitenleiste aus.

Weitere Informationen finden Sie im Abschnitt „Failed request traces“ im Thema „Enable diagnostics logging for apps in Azure App Service“ und unter Häufig gestellte Fragen zur Anwendungsleistung von Web-Apps in Azure: Wie schalte ich die Ablaufverfolgung für Anforderungsfehler ein?

Aktivieren der Diagnoseprotokollierung für Apps in Azure App Service.

Warnung

Wenn das stdout-Protokoll nicht deaktiviert wird, können App- oder Serverfehler auftreten. Für die Protokollgröße oder die Anzahl von erstellten Protokolldateien ist kein Grenzwert festgelegt.

Verwenden Sie für die routinemäßige Protokollierung in einer ASP.NET Core-App eine Protokollierungsbibliothek, die die Protokolldateigröße beschränkt und die Protokolle rotiert. Weitere Informationen finden Sie im Artikel zur Protokollierung von Drittanbietern.

Problembehandlung bei den Internetinformationsdiensten (IIS)

Anwendungsereignisprotokoll (IIS)

Greifen Sie auf das Anwendungsereignisprotokoll zu:

  1. Öffnen Sie das Startmenü, suchen Sie nach der Ereignisanzeige, und wählen Sie dann die App Ereignisanzeige aus.
  2. Öffnen Sie unter Ereignisanzeige den Knoten Windows-Protokolle.
  3. Wählen Sie Anwendung aus, um das Anwendungsereignisprotokoll zu öffnen.
  4. Suchen Sie nach Fehlern, die mit der fehlerhaften App im Zusammenhang stehen. Fehler weisen in der Spalte Quelle den Wert IIS AspNetCore-Modul oder IIS Express AspNetCore-Modul auf.

Ausführen der App in einer Eingabeaufforderung

Viele Startfehler erzeugen keine nützlichen Informationen im Anwendungsereignisprotokoll. Sie können die Ursache für einige Fehler ermitteln, indem Sie die App in einer Eingabeaufforderung auf dem Hostsystem ausführen.

Framework-abhängige Bereitstellung

Wenn es sich bei der App um eine Framework-abhängige Bereitstellung handelt:

  1. Navigieren Sie in einer Eingabeaufforderung zum Bereitstellungsordner und führen Sie die App aus, indem Sie die Assembly der App mit dotnet.exe ausführen. Ersetzen Sie in folgendem Befehl den Namen der Assembly der App durch<assembly_name>: dotnet .\<assembly_name>.dll.
  2. Die Konsolenausgabe der App, die Fehler anzeigt, wird in das Konsolenfenster geschrieben.
  3. Wenn der Fehler während einer Anforderung an die App auftritt, führen Sie eine Anforderung an den Host und Port aus, auf dem Kestrel empfangsbereit ist. Führen Sie unter Verwendung der Standardhosts und -ports eine Anforderung für http://localhost:5000/ aus. Wenn die App normalerweise auf die Kestrel-Endpunktadresse reagiert, ist die Problemursache wahrscheinlich die Hostingkonfiguration (anstelle der App).

Eigenständige Bereitstellung

Wenn es sich bei der App um eine eigenständige Bereitstellung handelt:

  1. Navigieren Sie in einer Eingabeaufforderung zum Bereitstellungsordner und führen Sie die ausführbaren Dateien der App aus. Ersetzen Sie in folgendem Befehl den Namen der Assembly der App durch <assembly_name>: <assembly_name>.exe.
  2. Die Konsolenausgabe der App, die Fehler anzeigt, wird in das Konsolenfenster geschrieben.
  3. Wenn der Fehler während einer Anforderung an die App auftritt, führen Sie eine Anforderung an den Host und Port aus, auf dem Kestrel empfangsbereit ist. Führen Sie unter Verwendung der Standardhosts und -ports eine Anforderung für http://localhost:5000/ aus. Wenn die App normalerweise auf die Kestrel-Endpunktadresse reagiert, ist die Problemursache wahrscheinlich die Hostingkonfiguration (anstelle der App).

stdout-Protokoll des ASP.NET Core-Moduls (IIS)

So aktivieren Sie stdout-Protokolle und zeigen diese an:

  1. Navigieren Sie zum Bereitstellungsordner der Website auf dem Hostsystem.
  2. Erstellen Sie den Ordner logs, wenn dieser nicht vorhanden ist. Anweisungen zum Aktivieren von MSBuild für die automatische Erstellung des Ordners logs in der Bereitstellung finden Sie im Thema Verzeichnisstruktur.
  3. Bearbeiten Sie die Datei web.config. Legen Sie stdoutLogEnabled auf true fest, und ändern Sie den Pfad von stdoutLogFile so, dass auf den Ordner logs verwiesen wird (Beispiel: .\logs\stdout). stdout im Pfad ist das Präfix des Protokolldateinamens. Ein Zeitstempel, eine Prozess-ID und eine Dateierweiterung werden bei der Protokollerstellung automatisch hinzugefügt. Mit stdout als Präfix des Dateinamens wird eine typische Protokolldatei als stdout_20180205184032_5412.log benannt.
  4. Stellen Sie sicher, dass die Identität des Anwendungspools über Schreibberechtigungen für den Ordner Protokolle verfügt.
  5. Speichern Sie die aktualisierte Datei web.config.
  6. Führen Sie eine Anforderung an die App aus.
  7. Navigieren Sie zu dem Ordner logs. Suchen und öffnen Sie das aktuelle stdout-Protokoll.
  8. Untersuchen Sie das Protokoll auf Fehler.

Deaktivieren Sie die stdout-Protokollierung, wenn die Problembehandlung abgeschlossen ist:

  1. Bearbeiten Sie die Datei web.config.
  2. Legen Sie stdoutLogEnabled auf false fest.
  3. Speichern Sie die Datei.

Weitere Informationen finden Sie im Artikel ASP.NET Core-Modul (ANCM) für IIS:

Warnung

Wenn das stdout-Protokoll nicht deaktiviert wird, können App- oder Serverfehler auftreten. Für die Protokollgröße oder die Anzahl von erstellten Protokolldateien ist kein Grenzwert festgelegt.

Verwenden Sie für die routinemäßige Protokollierung in einer ASP.NET Core-App eine Protokollierungsbibliothek, die die Protokolldateigröße beschränkt und die Protokolle rotiert. Weitere Informationen finden Sie im Artikel zur Protokollierung von Drittanbietern.

Debugprotokoll des ASP.NET Core-Moduls (IIS)

Fügen Sie der web.config-Datei der App die folgenden Handlereinstellungen hinzu, um das Debugprotokoll des ASP.NET Core-Moduls zu aktivieren:

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

Überprüfen Sie, ob der für das Protokoll angegebene Pfad vorhanden ist und ob die Identität des Anwendungspools Schreibberechtigungen für den Speicherort hat.

Weitere Informationen finden Sie unter Protokollerstellung und -umleitung mit dem ASP.NET Core-Modul.

Aktivieren der Seite mit Ausnahmen für Entwickler

Die ASPNETCORE_ENVIRONMENT Umgebungsvariable kann zur Datei web.config hinzugefügt werden, um die App in der Entwicklungsumgebung auszuführen. Solange die Umgebung nicht beim Starten der App von UseEnvironment im Host-Builder außer Kraft gesetzt wird, kann die Seite mit Ausnahmen für Entwickler durch Festlegen der Umgebungsvariable angezeigt werden, wenn die App ausgeführt wird.

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

Das Festlegen der Umgebungsvariablen für ASPNETCORE_ENVIRONMENT wird nur bei der Verwendung von Staging- und Testservern empfohlen, die nicht für das Internet verfügbar gemacht werden. Entfernen Sie nach der Fehlerbehebung die Umgebungsvariable aus der Datei web.config. Informationen zum Festlegen von Umgebungsvariablen in der Datei web.config finden Sie unter Untergeordnetes environmentVariables-Element von aspNetCore.

Abrufen von Daten aus einer App

Wenn eine App in der Lage sind, auf Anforderungen zu reagieren, erhalten Sie Anforderungen, Verbindungen und zusätzliche Daten von den Apps über die Inlinemiddleware des Terminals. Weitere Informationen und Beispielcode finden Sie unter Problembehandlung und Debuggen von ASP.NET Core-Projekten.

Langsame oder nicht reagierende App (IIS)

Ein Absturzabbild ist eine Momentaufnahme des Systemarbeitsspeichers, die Ihnen dabei behilflich sein kann, die Ursache eines App-Absturzes, eines Startfehlers oder einer langsamen App zu ermitteln.

App stürzt ab, oder es tritt eine Ausnahme auf

Abrufen und Analysieren eines Speicherabbilds aus der Windows-Fehlerberichterstattung (WER):

  1. Erstellen Sie einen Ordner zum Speichern von Absturzabbilddateien unter c:\dumps. Der App-Pool muss über Schreibzugriff auf den Ordner verfügen.

  2. Führen Sie das PowerShell-Skript „EnableDumps“ aus:

    • Wenn die App das In-Process-Hostingmodell verwendet, führen Sie das Skript für w3wp.exe aus:

      .\EnableDumps w3wp.exe c:\dumps

    • Wenn die App das Out-of-Process-Hostingmodell verwendet, führen Sie das Skript für dotnet.exe aus:

      .\EnableDumps dotnet.exe c:\dumps

  3. Führen Sie die App unter den Bedingungen aus, die dazu führen, dass der Absturz auftritt.

  4. Nachdem der Absturz stattgefunden hat, führen Sie das PowerShell-Skript „DisableDumps“ aus:

Nachdem eine Anwendung abgestürzt ist und die Absturzabbildsammlung abgeschlossen ist, kann die App ordnungsgemäß beendet werden. Das PowerShell-Skript konfiguriert WER für die Erfassung von bis zu fünf Absturzabbildern pro App.

Warnung

Absturzabbilder können eine große Menge Speicherplatz in Anspruch nehmen (jeweils bis zu mehreren GB).

Die App reagiert nicht, schlägt während des Starts fehl oder wird normal ausgeführt.

Wenn eine App nicht mehr reagiert, aber nicht abstürzt, beim Start fehlschlägt oder normal läuft, finden Sie unter Benutzermodus-Dumpdateien: Auswählen des besten Tools ein geeignetes Tool zur Erstellung des Speicherabbilds.

Analysieren des Speicherabbilds

Ein Speicherabbild kann mithilfe mehrerer Ansätze analysiert werden. Weitere Informationen finden Sie unter Analysieren einer Benutzermodus-Speicherabbilddatei.

Bereinigen der Paketcaches

Eine funktionsfähige App kann direkt nach der Durchführung eines Upgrades für das .NET Core SDK auf dem Entwicklungscomputer oder einer Änderung der Paketversionen in der App fehlschlagen. In einigen Fällen können inkohärente Pakete eine App beschädigen, wenn größere Upgrades durchgeführt werden. Die meisten dieser Probleme können durch Befolgung der folgenden Anweisungen behoben werden:

  1. Löschen Sie die Ordner bin und obj.

  2. Bereinigen Sie die Paketcaches, indem Sie dotnet nuget locals all --clear über eine Befehlsshell ausführen.

    Sie können die Paketcaches auch mit dem Tool nuget.exe und dem Befehl nuget locals all -clear bereinigen. nuget.exe ist wird unter dem Windows Desktop-Betriebssystem nicht gebündelt installiert und muss separat von der NuGet-Website abgerufen werden.

  3. Stellen Sie das Projekt wieder her und erstellen Sie es neu.

  4. Löschen Sie alle Dateien im Bereitstellungsordner auf dem Server, bevor Sie die App noch mal bereitstellen.

Zusätzliche Ressourcen

Azure-Dokumentation

Visual Studio-Dokumentation

Dokumentation zu Visual Studio Code