Řešení potíží s ASP.NET Core v Azure App Service a ve službě IIS

Autor: Justin Kotalik

Tento článek obsahuje informace o běžných chybách při spuštění aplikace a pokyny k diagnostice chyb při nasazení aplikace do služby Aplikace Azure service nebo služby IIS:

Chyby při spuštění aplikace
Vysvětluje běžné scénáře stavových kódů HTTP při spuštění.

Řešení potíží se službou Aplikace Azure Service
Poskytuje rady pro řešení potíží pro aplikace nasazené do služby Aplikace Azure Service.

Odstraňování potíží ve službě IIS
Poskytuje rady pro řešení potíží pro aplikace nasazené ve službě IIS nebo spuštěné místně ve službě IIS Express. Pokyny platí pro nasazení Windows Serveru i plochy Windows.

Vymazání mezipamětí balíčků
Vysvětluje, co dělat, když inkoherentní balíčky přeruší aplikaci při provádění hlavních upgradů nebo změn verzí balíčků.

Další materiály
Obsahuje další témata pro řešení potíží.

Chyby při spuštění aplikace

V sadě Visual Studio je Kestrelvýchozí server projektu ASP.NET Core . Visual Studio je možné nakonfigurovat tak, aby používalo službu IIS Express. A 502.5 – Selhání procesu nebo 500.30 – Selhání spuštění, ke kterému dochází při místním ladění pomocí služby IIS Express, je možné diagnostikovat pomocí rad v tomto tématu.

403.14 Zakázáno

Aplikace se nespustí. Zaprotokoluje se následující chyba:

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

Příčinou chyby je obvykle poškozené nasazení v hostitelském systému, které zahrnuje některý z následujících scénářů:

  • Aplikace se nasadí do nesprávné složky v hostitelském systému.
  • Proces nasazení se nepovedlo přesunout všechny soubory a složky aplikace do složky nasazení v hostitelském systému.
  • V nasazení chybí soubor web.config nebo je poškozený obsah souboru web.config .

Proveďte následující kroky:

  1. Odstraňte všechny soubory a složky ze složky nasazení v hostitelském systému.
  2. Znovu nasaďte obsah složky publikování aplikace do hostitelského systému pomocí normální metody nasazení, jako je Visual Studio, PowerShell nebo ruční nasazení:
    • Ověřte, že se soubor web.config nachází v nasazení a zda je jeho obsah správný.
    • Při hostování ve službě Aplikace Azure Service ověřte, že je aplikace nasazená do D:\home\site\wwwroot složky.
    • Když je aplikace hostovaná službou IIS, ověřte, že je aplikace nasazená na fyzickou cestu IIS zobrazenou ve správci služby IIS Basic Nastavení.
  3. Ověřte, že jsou všechny soubory a složky aplikace nasazené tak, že porovnáte nasazení v hostitelském systému s obsahem složky publikování projektu.

Další informace o rozložení publikované aplikace ASP.NET Core najdete v tématu ASP.NET Základní adresářová struktura. Další informace o souboru web.config naleznete v tématu ASP.NET Základní modul (ANCM) pro službu IIS.

500 – Vnitřní chyba serveru

Aplikace se spustí, ale chyba brání serveru v plnění požadavku.

K této chybě dochází v kódu aplikace během spuštění nebo při vytváření odpovědi. Odpověď nemusí obsahovat žádný obsah nebo se může v prohlížeči zobrazit jako 500 vnitřní chyba serveru. Protokol událostí aplikace obvykle uvádí, že aplikace začala normálně. Z pohledu serveru je to správné. Aplikace se spustila, ale nemůže vygenerovat platnou odpověď. Spusťte aplikaci na příkazovém řádku na serveru nebo povolte protokol stdout modulu ASP.NET core a problém vyřešte.

K této chybě může dojít také v případě, že není nainstalovaná nebo poškozená sada hostingu .NET Core. Problém může vyřešit instalace nebo opravy sady .NET Core Hosting Bundle (pro IIS) nebo sady Visual Studio (pro SLUŽBU IIS Express).

Chyba načtení obslužné rutiny v procesu 500.0

Pracovní proces selže. Aplikace se nespustí.

Při načítání komponent základního modulu ASP.NET došlo k neznámé chybě. Proveďte jednu z následujících akcí:

  • Kontaktujte podpora Microsoftu (vyberte Vývojářské nástroje a pak ASP.NET Core).
  • Položte otázku na Stack Overflow.
  • Napište problém v našem úložišti GitHub.

500.30 Selhání spuštění v procesu

Pracovní proces selže. Aplikace se nespustí.

Modul ASP.NET Core se pokusí spustit proces .NET Core CLR, ale nejde spustit. Příčinu selhání spuštění procesu je obvykle možné určit z položek v protokolu událostí aplikace a protokolu stdout modulu ASP.NET Core Module stdout.

Běžné stavy selhání:

  • Aplikace je chybně nakonfigurovaná kvůli cílení na verzi sdílené architektury ASP.NET Core, která není k dispozici. Zkontrolujte, které verze sdílené architektury ASP.NET Core jsou nainstalované na cílovém počítači.
  • Pomocí služby Azure Key Vault nemáte oprávnění ke službě Key Vault. Zkontrolujte zásady přístupu v cílové službě Key Vault a ujistěte se, že jsou udělena správná oprávnění.

500.31 Nepodařilo se najít nativní závislosti ANCM

Pracovní proces selže. Aplikace se nespustí.

Modul ASP.NET Core se pokusí spustit modul runtime .NET Core v procesu, ale nejde spustit. Nejběžnější příčinou tohoto selhání spuštění je, když Microsoft.NETCore.App není nainstalovaný modul runtime nebo Microsoft.AspNetCore.App modul runtime. Pokud je aplikace nasazená do cíle ASP.NET Core 3.0 a tato verze na počítači neexistuje, dojde k této chybě. Příklad chybové zprávy:

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]

Chybová zpráva obsahuje všechny nainstalované verze .NET Core a verzi požadovanou aplikací. Pokud chcete tuto chybu opravit, proveďte jednu z těchto akcí:

  • Nainstalujte na počítač odpovídající verzi .NET Core.
  • Změňte aplikaci tak, aby cílila na verzi .NET Core, která se nachází na počítači.
  • Publikujte aplikaci jako samostatné nasazení.

Při spuštění ve vývoji ( ASPNETCORE_ENVIRONMENT proměnná prostředí je nastavená na Development), konkrétní chyba se zapíše do odpovědi HTTP. V protokolu událostí aplikace se také nachází příčina selhání spuštění procesu.

500.32 AnCM se nepodařilo načíst knihovnu DLL

Pracovní proces selže. Aplikace se nespustí.

Nejběžnější příčinou této chyby je, že aplikace je publikovaná pro nekompatibilní architekturu procesoru. Pokud je pracovní proces spuštěný jako 32bitová aplikace a aplikace byla publikována do cílové 64bitové verze, dojde k této chybě.

Pokud chcete tuto chybu opravit, proveďte jednu z těchto akcí:

  • Znovu publikujte aplikaci pro stejnou architekturu procesoru jako pracovní proces.
  • Publikujte aplikaci jako nasazení závislé na rozhraní.

500.33 Selhání načtení obslužné rutiny požadavku ANCM

Pracovní proces selže. Aplikace se nespustí.

Aplikace neodkazovala na architekturu Microsoft.AspNetCore.App . Základní modul ASP.NET může hostovat jenom aplikace, které cílí na Microsoft.AspNetCore.App architekturu.

Pokud chcete tuto chybu opravit, ověřte, že aplikace cílí na architekturu Microsoft.AspNetCore.App . Zkontrolujte, jestli .runtimeconfig.json chcete ověřit architekturu, na kterou aplikace cílí.

500.34 Smíšené hostitelské modely ANCM se nepodporují

Pracovní proces nemůže spustit aplikaci v procesu i aplikaci mimo proces ve stejném procesu.

Pokud chcete tuto chybu opravit, spusťte aplikace v samostatných fondech aplikací služby IIS.

500.35 ANCM více aplikací v procesu ve stejném procesu

Pracovní proces nemůže spustit více aplikací v procesu ve stejném procesu.

Pokud chcete tuto chybu opravit, spusťte aplikace v samostatných fondech aplikací služby IIS.

500.36 Selhání načtení obslužné rutiny mimo proces

Obslužná rutina požadavku mimo proces, aspnetcorev2_outofprocess.dll, není vedle souboru aspnetcorev2.dll. Označuje poškozenou instalaci modulu ASP.NET Core.

Pokud chcete tuto chybu opravit, opravte instalaci sady hostingu .NET Core (pro iis) nebo sady Visual Studio (pro SLUŽBU IIS Express).

500.37 AnCM se nepodařilo spustit v rámci časového limitu spuštění

Službě ANCM se nepodařilo spustit během zadaného časového limitu spuštění. Ve výchozím nastavení je časový limit 120 sekund.

K této chybě může dojít při spouštění velkého počtu aplikací na stejném počítači. Zkontrolujte špičky využití procesoru a paměti na serveru během spouštění. Možná budete muset rozběhnou proces spouštění více aplikací.

500.38 Knihovna DLL aplikace ANCM nebyla nalezena.

Službě ANCM se nepodařilo najít knihovnu DLL aplikace, která by měla být vedle spustitelného souboru.

K této chybě dochází při hostování aplikace zabalené jako spustitelný soubor s jedním souborem pomocí modelu hostování v procesu. Model v procesu vyžaduje, aby ANCM načetl aplikaci .NET Core do existujícího procesu SLUŽBY IIS. Tento scénář nepodporuje model nasazení s jedním souborem. K opravě této chyby použijte jeden z následujících přístupů v souboru projektu aplikace:

  1. Zakažte publikování s jedním souborem nastavením PublishSingleFile vlastnosti MSBuild na falsehodnotu .
  2. Přepněte na model hostování mimo proces nastavením AspNetCoreHostingModel vlastnosti MSBuild na OutOfProcesshodnotu .

Selhání procesu 502.5

Pracovní proces selže. Aplikace se nespustí.

Modul ASP.NET Core se pokusí spustit pracovní proces, ale nepodaří se ho spustit. Příčinu selhání spuštění procesu je obvykle možné určit z položek v protokolu událostí aplikace a protokolu stdout modulu ASP.NET Core Module stdout.

Běžnou chybovou podmínkou je, že aplikace je chybně nakonfigurovaná kvůli cílení na verzi sdílené architektury ASP.NET Core, která není k dispozici. Zkontrolujte, které verze sdílené architektury ASP.NET Core jsou nainstalované na cílovém počítači. Sdílená architektura je sada sestavení (soubory .dll ), které jsou nainstalovány v počítači a odkazovány metabalíkem, jako Microsoft.AspNetCore.Appje . Odkaz na metabalídu může určit minimální požadovanou verzi. Další informace naleznete v části Sdílená architektura.

Chybová stránka selhání procesu 502.5 se vrátí, když hostitelský nebo aplikační chybná konfigurace způsobí selhání pracovního procesu:

Spuštění aplikace (ErrorCode 0x800700c1) se nezdařilo.

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

Aplikaci se nepodařilo spustit, protože sestavení aplikace (.dll) se nepodařilo načíst.

K této chybě dochází v případě neshody bitů mezi publikovanou aplikací a procesem w3wp/iisexpress.

Ověřte správnost nastavení 32bitového fondu aplikací:

  1. Vyberte fond aplikací ve fondech aplikací Správce služby IIS.
  2. V části Upravit fond aplikací na panelu Akce vyberte Upřesnit Nastavení.
  3. Nastavení povolení 32bitových aplikací:
    • Pokud nasazujete 32bitovou aplikaci (x86), nastavte hodnotu na True.
    • Pokud nasazujete 64bitovou (x64) aplikaci, nastavte hodnotu na Falsehodnotu .

Ověřte, že mezi vlastností MSBuild v souboru projektu a publikovanou bitovou verzí aplikace není konflikt <Platform> .

Spuštění aplikace (ErrorCode 0x800701b1) se nezdařilo.

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

Aplikaci se nepodařilo spustit, protože se službě Windows nepodařilo načíst.

Jednou z běžných služeb, které je potřeba povolit, je služba null. Následující příkaz povolí null službu systému Windows:

sc.exe start null

resetování Připojení

Pokud po odeslání hlaviček dojde k chybě, je příliš pozdě na to, aby server při výskytu chyby odeslal chybu 500 Interní server . K tomu často dochází v případě, že dojde k chybě během serializace složitých objektů pro odpověď. Tento typ chyby se v klientovi zobrazí jako chyba resetování připojení. Protokolování aplikace může pomoct při řešení těchto typů chyb.

Výchozí limity spouštění

Modul ASP.NET Core je nakonfigurovaný s výchozí hodnotou startupTimeLimit 120 sekund. Když ponecháte výchozí hodnotu, může spuštění aplikace trvat až dvě minuty, než modul zaznamená selhání procesu. Informace o konfiguraci modulu naleznete v tématu Atributy aspNetCore elementu.

Řešení potíží se službou Aplikace Azure Service

Důležité

verze ASP.NET Core Preview se službou Aplikace Azure Service

ASP.NET verze Preview core se ve výchozím nastavení nenasazují do služby Aplikace Azure Service. Pokud chcete hostovat aplikaci, která používá verzi ASP.NET Core Preview, přečtěte si téma Nasazení verze ASP.NET Core Preview do služby Aplikace Azure Service.

Stream protokolu služby Aplikace Azure Services

Protokol služby Aplikace Azure streamuje informace protokolování, jak se vyskytují. Zobrazení protokolů streamování:

  1. Na webu Azure Portal otevřete aplikaci ve službě App Services.
  2. V levém podokně přejděte do části Monitorování>protokolů služby App Service. App Service Logs
  3. Vyberte systém souborů pro protokolování webového serveru. Volitelně můžete povolit protokolování aplikace. enable logging
  4. V levém podokně přejděte do streamu protokolu monitorování>a pak vyberte Protokoly aplikací nebo Protokoly webového serveru.

Monitoring Log stream

Následující obrázky znázorňují výstup protokolů aplikace:

app logs

Protokoly streamování mají určitou latenci a nemusí se zobrazit okamžitě.

Protokol událostí aplikace (služba Aplikace Azure)

Pokud chcete získat přístup k protokolu událostí aplikace, použijte okno Diagnostika a řešení problémů na webu Azure Portal:

  1. Na webu Azure Portal otevřete aplikaci ve službě App Services.
  2. Vyberte Diagnostikovat a řešit problémy.
  3. Vyberte nadpis Diagnostické nástroje.
  4. V části Nástroje podpory vyberte tlačítko Události aplikace.
  5. Zkontrolujte nejnovější chybu, kterou poskytuje položka IIS AspNetCoreModule nebo IIS AspNetCoreModule V2 ve sloupci Zdroj .

Alternativou k použití okna Diagnostika a řešení problémů je prozkoumání souboru protokolu událostí aplikace přímo pomocí Kudu:

  1. Otevřete rozšířené nástroje v oblasti Vývojové nástroje. Vyberte tlačítko Přejít→. Konzola Kudu se otevře na nové kartě nebo okně prohlížeče.
  2. Pomocí navigačního panelu v horní části stránky otevřete konzolu Ladění a vyberte CMD.
  3. Otevřete složku LogFiles.
  4. Vyberte ikonu tužky eventlog.xml vedle souboru.
  5. Zkontrolujte protokol. Posuňte se do dolní části protokolu a zobrazte nejnovější události.

Spuštění aplikace v konzole Kudu

Mnoho chyb při spuštění negeneruje užitečné informace v protokolu událostí aplikace. Aplikaci můžete spustit v konzole vzdáleného spuštění Kudu a zjistit chybu:

  1. Otevřete rozšířené nástroje v oblasti Vývojové nástroje. Vyberte tlačítko Přejít→. Konzola Kudu se otevře na nové kartě nebo okně prohlížeče.
  2. Pomocí navigačního panelu v horní části stránky otevřete konzolu Ladění a vyberte CMD.

Testování 32bitové aplikace (x86)

Aktuální verze

  1. cd d:\home\site\wwwroot
  2. Spusťte aplikaci:

Výstup konzoly z aplikace zobrazující případné chyby se předá do konzoly Kudu.

Nasazení závislé na rozhraní spuštěné ve verzi Preview

Vyžaduje instalaci rozšíření lokality modulu runtime ASP.NET Core {VERSION} (x86).

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} je verze modulu runtime)
  2. Spusťte aplikaci: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Výstup konzoly z aplikace zobrazující případné chyby se předá do konzoly Kudu.

Testování 64bitové aplikace (x64)

Aktuální verze

  • Pokud je aplikace 64bitové (x64) nasazení závislé na rozhraní:
    1. cd D:\Program Files\dotnet
    2. Spusťte aplikaci: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
  • Pokud se jedná o samostatné nasazení:
    1. cd D:\home\site\wwwroot
    2. Spusťte aplikaci: {ASSEMBLY NAME}.exe

Výstup konzoly z aplikace zobrazující případné chyby se předá do konzoly Kudu.

Nasazení závislé na rozhraní spuštěné ve verzi Preview

Vyžaduje instalaci rozšíření lokality modulu runtime ASP.NET Core {VERSION} (x64).

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} je verze modulu runtime)
  2. Spusťte aplikaci: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Výstup konzoly z aplikace zobrazující případné chyby se předá do konzoly Kudu.

protokol stdout modulu ASP.NET Core (služba Aplikace Azure)

Upozorňující

Selhání zakázání protokolu stdout může vést k selhání aplikace nebo serveru. Velikost souboru protokolu ani počet vytvořených souborů protokolu není nijak omezený. K řešení problémů se spuštěním aplikace používejte pouze protokolování stdout.

Pro obecné protokolování v aplikaci ASP.NET Core po spuštění použijte knihovnu protokolování, která omezuje velikost souboru protokolu a obměňuje protokoly. Další informace najdete v tématu Zprostředkovatelé protokolování třetích stran.

Protokol stdout základního modulu ASP.NET často zaznamenává užitečné chybové zprávy, které se v protokolu událostí aplikace nenašly. Povolení a zobrazení protokolů stdout:

  1. Na webu Azure Portal přejděte do webové aplikace.
  2. V okně Služby App Service zadejte do vyhledávacího pole kudu .
  3. Vyberte Přejít na Pokročilé nástroje>.
  4. Vyberte CMD konzoly > ladění.
  5. Přejděte na web nebo wwwroot.
  6. Výběrem ikony tužky upravte soubor web.config .
  7. V elementu <aspNetCore /> nastavte stdoutLogEnabled="true" a vyberte Uložit.

Pokud je odstraňování potíží dokončeno, zakažte protokolování stdout nastavením stdoutLogEnabled="false".

Další informace najdete v tématu Modul ASP.NET Core (ANCM) pro službu IIS.

protokol ladění základního modulu ASP.NET (služba Aplikace Azure)

Protokol ladění základního modulu ASP.NET poskytuje další podrobnější protokolování z modulu ASP.NET Core. Povolení a zobrazení protokolů stdout:

  1. Pokud chcete povolit rozšířený diagnostický protokol, proveďte jednu z následujících akcí:
    • Podle pokynů v rozšířených diagnostických protokolech nakonfigurujte aplikaci pro rozšířené protokolování diagnostiky. Opětovné nasazení aplikace.
    • <handlerSettings> Pomocí konzoly Kudu přidejte do souboru web.config živé aplikace zobrazené v rozšířených diagnostických protokolech:
      1. Otevřete rozšířené nástroje v oblasti Vývojové nástroje. Vyberte tlačítko Přejít→. Konzola Kudu se otevře na nové kartě nebo okně prohlížeče.
      2. Pomocí navigačního panelu v horní části stránky otevřete konzolu Ladění a vyberte CMD.
      3. Otevřete složky na webu wwwroot> cesty. Upravte soubor web.config tak, že vyberete tlačítko tužky. <handlerSettings> Přidejte oddíl, jak je znázorněno v rozšířených diagnostických protokolech. Vyberte tlačítko Uložit.
  2. Otevřete rozšířené nástroje v oblasti Vývojové nástroje. Vyberte tlačítko Přejít→. Konzola Kudu se otevře na nové kartě nebo okně prohlížeče.
  3. Pomocí navigačního panelu v horní části stránky otevřete konzolu Ladění a vyberte CMD.
  4. Otevřete složky na webu wwwroot> cesty. Pokud jste pro soubor aspnetcore-debug.log nezadali cestu, soubor se zobrazí v seznamu. Pokud jste zadali cestu, přejděte do umístění souboru protokolu.
  5. Otevřete soubor protokolu pomocí tlačítka tužky vedle názvu souboru.

Po dokončení řešení potíží zakažte protokolování ladění:

Pokud chcete rozšířený protokol ladění zakázat, proveďte jednu z následujících akcí:

  • <handlerSettings> Odeberte soubor web.config místně a znovu nasaďte aplikaci.
  • Pomocí konzoly Kudu upravte soubor web.config a odeberte <handlerSettings> oddíl. Soubor uložte.

Další informace najdete v tématu Vytvoření protokolu a přesměrování pomocí modulu ASP.NET Core.

Upozorňující

Selhání zakázání protokolu ladění může vést k selhání aplikace nebo serveru. Velikost souboru protokolu není nijak omezena. K řešení problémů se spuštěním aplikace používejte protokolování ladění.

Pro obecné protokolování v aplikaci ASP.NET Core po spuštění použijte knihovnu protokolování, která omezuje velikost souboru protokolu a obměňuje protokoly. Další informace najdete v tématu Zprostředkovatelé protokolování třetích stran.

Pomalá nebo zablokovat aplikace (služba Aplikace Azure)

Pokud aplikace reaguje pomalu nebo přestane reagovat na žádost, přečtěte si téma Řešení potíží s nízkým výkonem webové aplikace ve službě Aplikace Azure Service.

Okna monitorování

Okna monitorování poskytují alternativní řešení potíží s metodami popsanými výše v tématu. Tato okna se dají použít k diagnostice chyb řady 500.

Ověřte, že jsou nainstalovaná rozšíření ASP.NET Core Extensions. Pokud se rozšíření nenainstalují, nainstalujte je ručně:

  1. V části OKNA VÝVOJOVÉ NÁSTROJE vyberte okno Rozšíření.
  2. V seznamu by se měla zobrazit ASP.NET základní rozšíření .
  3. Pokud rozšíření nejsou nainstalovaná, vyberte tlačítko Přidat .
  4. Ze seznamu vyberte ASP.NET Core Extensions.
  5. Výběrem OK přijměte právní podmínky.
  6. V okně Přidat rozšíření vyberte OK.
  7. Informační automaticky otevíraná zpráva indikuje, kdy se rozšíření úspěšně nainstalují.

Pokud není povolené protokolování stdout, postupujte takto:

  1. Na webu Azure Portal vyberte okno Rozšířené nástroje v oblasti VÝVOJOVÉ NÁSTROJE . Vyberte tlačítko Přejít→. Konzola Kudu se otevře na nové kartě nebo okně prohlížeče.
  2. Pomocí navigačního panelu v horní části stránky otevřete konzolu Ladění a vyberte CMD.
  3. Otevřete složky na webu wwwroot> cesty a posuňte se dolů a zobrazte soubor web.config v dolní části seznamu.
  4. Klikněte na ikonu tužky vedle souboru web.config .
  5. Nastavte stdoutLogEnabled na true a změňte cestu stdoutLogFile na: \\?\%home%\LogFiles\stdout.
  6. Výběrem možnosti Uložit uložte aktualizovaný soubor web.config .

Pokračujte aktivací protokolování diagnostiky:

  1. Na webu Azure Portal vyberte okno Diagnostické protokoly .
  2. Vyberte přepínač Zapnuto pro protokolování aplikace (systém souborů) a podrobné chybové zprávy. Vyberte tlačítko Uložit v horní části okna.
  3. Pokud chcete zahrnout trasování neúspěšných požadavků, označované také jako protokolování ukládání do vyrovnávací paměti neúspěšných požadavků (FREB), vyberte přepínač Zapnuto pro trasování neúspěšných požadavků.
  4. Vyberte okno Stream protokolu, které se zobrazí okamžitě v okně Diagnostické protokoly na portálu.
  5. Vytvořte žádost o aplikaci.
  6. V rámci dat datového proudu protokolu je uvedena příčina chyby.

Po dokončení řešení potíží nezapomeňte protokolování stdout zakázat.

Zobrazení protokolů trasování neúspěšných požadavků (protokoly FREB):

  1. Na webu Azure Portal přejděte do okna Diagnostika a řešení problémů .
  2. V oblasti NÁSTROJE PODPORY na bočním panelu vyberte protokoly trasování neúspěšných požadavků.

Další informace najdete v části Trasování neúspěšných požadavků v tématu Povolení protokolování diagnostiky pro webové aplikace v tématu služby Aplikace Azure Service a nejčastější dotazy k výkonu aplikací pro Web Apps v Azure: Návody zapnout trasování neúspěšných požadavků?

Další informace najdete v tématu Povolení protokolování diagnostiky pro webové aplikace ve službě Aplikace Azure Service.

Upozorňující

Selhání zakázání protokolu stdout může vést k selhání aplikace nebo serveru. Velikost souboru protokolu ani počet vytvořených souborů protokolu není nijak omezený.

Pro rutinní protokolování v aplikaci ASP.NET Core použijte knihovnu protokolování, která omezuje velikost souboru protokolu a obměňuje protokoly. Další informace najdete v tématu Zprostředkovatelé protokolování třetích stran.

Odstraňování potíží ve službě IIS

Protokol událostí aplikace (IIS)

Přístup k protokolu událostí aplikace:

  1. Otevřete nabídka Start, vyhledejte Prohlížeč událostí a vyberte aplikaci Prohlížeč událostí.
  2. V Prohlížeč událostí otevřete uzel Protokoly systému Windows.
  3. Výběrem možnosti Aplikace otevřete protokol událostí aplikace.
  4. Vyhledejte chyby spojené s neúspěšnou aplikací. Chyby mají hodnotu modulu IIS AspNetCore nebo modulu IIS Express AspNetCore ve sloupci Zdroj .

Spuštění aplikace na příkazovém řádku

Mnoho chyb při spuštění negeneruje užitečné informace v protokolu událostí aplikace. Příčinu některých chyb můžete zjistit spuštěním aplikace na příkazovém řádku v hostitelském systému.

Nasazení závislé na rozhraní

Pokud je aplikace nasazení závislé na rozhraní:

  1. Na příkazovém řádku přejděte do složky nasazení a spusťte aplikaci spuštěním sestavení aplikace s dotnet.exe. V následujícím příkazu nahraďte název sestavení aplikace assembly_name<>: dotnet .\<assembly_name>.dll.
  2. Výstup konzoly z aplikace zobrazující případné chyby se zapíše do okna konzoly.
  3. Pokud dojde k chybám při vytváření požadavku na aplikaci, odešlete žádost hostiteli a portu, kde Kestrel naslouchá. Pomocí výchozího hostitele a příspěvku proveďte požadavek na http://localhost:5000/. Pokud aplikace normálně reaguje na adrese koncového Kestrel bodu, problém pravděpodobně souvisí s konfigurací hostování a méně pravděpodobné v rámci aplikace.

Samostatné nasazení

Pokud se jedná o samostatné nasazení:

  1. Na příkazovém řádku přejděte do složky nasazení a spusťte spustitelný soubor aplikace. V následujícím příkazu nahraďte název sestavení aplikace assembly_name<>: <assembly_name>.exe.
  2. Výstup konzoly z aplikace zobrazující případné chyby se zapíše do okna konzoly.
  3. Pokud dojde k chybám při vytváření požadavku na aplikaci, odešlete žádost hostiteli a portu, kde Kestrel naslouchá. Pomocí výchozího hostitele a příspěvku proveďte požadavek na http://localhost:5000/. Pokud aplikace normálně reaguje na adrese koncového Kestrel bodu, problém pravděpodobně souvisí s konfigurací hostování a méně pravděpodobné v rámci aplikace.

protokol stdout modulu ASP.NET Core (IIS)

Povolení a zobrazení protokolů stdout:

  1. Přejděte do složky nasazení webu v hostitelském systému.
  2. Pokud složka protokolů není k dispozici, vytvořte ji. Pokyny k automatickému vytvoření složky protokolů v nasazení pomocí nástroje MSBuild najdete v tématu Struktura adresářů .
  3. Upravte soubor web.config. Nastavte stdoutLogEnabled a změňte cestu stdoutLogFile tak, aby odkazovala na složku protokolů (například.\logs\stdout).true stdout v cestě je předpona názvu souboru protokolu. Při vytváření protokolu se automaticky přidá časové razítko, ID procesu a přípona souboru. Jako stdout předponu názvu souboru se typický soubor protokolu nazývá stdout_20180205184032_5412.log.
  4. Ujistěte se, že identita fondu aplikací má oprávnění k zápisu do složky protokolů .
  5. Uložte aktualizovaný soubor web.config .
  6. Vytvořte žádost o aplikaci.
  7. Přejděte do složky protokolů . Vyhledejte a otevřete nejnovější protokol stdout.
  8. Prostudujte protokol chyb.

Po dokončení řešení potíží zakažte protokolování stdout:

  1. Upravte soubor web.config.
  2. Nastavte stdoutLogEnabled na false.
  3. Soubor uložte.

Další informace najdete v tématu Modul ASP.NET Core (ANCM) pro službu IIS.

Upozorňující

Selhání zakázání protokolu stdout může vést k selhání aplikace nebo serveru. Velikost souboru protokolu ani počet vytvořených souborů protokolu není nijak omezený.

Pro rutinní protokolování v aplikaci ASP.NET Core použijte knihovnu protokolování, která omezuje velikost souboru protokolu a obměňuje protokoly. Další informace najdete v tématu Zprostředkovatelé protokolování třetích stran.

protokol ladění základního modulu ASP.NET (IIS)

Do souboru web.config aplikace přidejte následující nastavení obslužné rutiny, aby se povolil protokol ladění základního modulu ASP.NET:

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

Ověřte, že cesta zadaná pro protokol existuje a že identita fondu aplikací má oprávnění k zápisu do umístění.

Další informace najdete v tématu Vytvoření protokolu a přesměrování pomocí modulu ASP.NET Core.

Povolení stránky výjimek pro vývojáře

Proměnnou ASPNETCORE_ENVIRONMENTprostředí je možné přidat do souboru web.config , aby se aplikace spustila ve vývojovém prostředí. Pokud se prostředí nepřepíše při spuštění aplikace v UseEnvironment tvůrci hostitelů, nastavení proměnné prostředí umožňuje , aby se při spuštění aplikace zobrazila stránka výjimky vývojáře.

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

Nastavení proměnné ASPNETCORE_ENVIRONMENT prostředí se doporučuje jenom pro pracovní a testovací servery, které nejsou vystavené internetu. Po řešení potíží odeberte proměnnou prostředí ze souboru web.config . Informace o nastavení proměnných prostředí ve web.config naleznete v tématu environmentVariables podřízený prvek aspNetCore.

Získání dat z aplikace

Pokud aplikace dokáže reagovat na požadavky, získat požadavek, připojení a další data z aplikace pomocí vloženého middlewaru terminálu. Další informace a vzorový kód najdete v tématu Řešení potíží a ladění ASP.NET základních projektů.

Pomalé nebo zablokování aplikace (IIS)

Výpis stavu systému je snímek paměti systému a může pomoct určit příčinu chybového ukončení aplikace, selhání spuštění nebo pomalé aplikace.

Aplikace se chybově ukončí nebo dojde k výjimce

Získání a analýza výpisu paměti z Zasílání zpráv o chybách systému Windows (WER):

  1. Vytvořte složku pro ukládání souborů s výpisem stavu systému na adrese c:\dumps. Fond aplikací musí mít ke složce přístup pro zápis.

  2. Spusťte skript PowerShellu EnableDumps:

    • Pokud aplikace používá model hostování v procesu, spusťte skript pro w3wp.exe:

      .\EnableDumps w3wp.exe c:\dumps
      
    • Pokud aplikace používá model hostování mimo proces, spusťte skript pro dotnet.exe:

      .\EnableDumps dotnet.exe c:\dumps
      
  3. Spusťte aplikaci za podmínek, které způsobují chybové ukončení.

  4. Po chybě spusťte skript DisableDumps PowerShellu:

    • Pokud aplikace používá model hostování v procesu, spusťte skript pro w3wp.exe:

      .\DisableDumps w3wp.exe
      
    • Pokud aplikace používá model hostování mimo proces, spusťte skript pro dotnet.exe:

      .\DisableDumps dotnet.exe
      

Po chybovém ukončení aplikace a dokončení shromažďování výpisů paměti se aplikace může normálně ukončit. Skript PowerShellu konfiguruje WER tak, aby shromáždil až pět výpisů paměti na aplikaci.

Upozorňující

Výpisy stavu systému můžou zabírat velké množství místa na disku (až několik gigabajtů).

Aplikace přestane reagovat, selže při spuštění nebo se normálně spustí

Když aplikace přestane reagovat (přestane reagovat, ale neuspěje), selže při spuštění nebo se spustí normálně, přečtěte si téma Soubory výpisu stavu stavu systému v uživatelském režimu: Volba nejvhodnějšího nástroje pro výběr vhodného nástroje pro vytvoření výpisu paměti.

Analýza výpisu paměti

Výpis paměti je možné analyzovat pomocí několika přístupů. Další informace naleznete v tématu Analýza souboru výpisu stavu systému v uživatelském režimu.

Vymazání mezipamětí balíčků

Funkční aplikace může selhat okamžitě po upgradu sady .NET Core SDK na vývojovém počítači nebo změně verzí balíčků v aplikaci. V některých případech můžou inkoherentní balíčky přerušit aplikaci při provádění hlavních upgradů. Většinu těchto problémů je možné vyřešit pomocí těchto pokynů:

  1. Odstraňte přihrádku a složky obj.

  2. Vymažte mezipaměti balíčků spuštěním dotnet nuget locals all --clear z příkazového prostředí.

    Vymazání mezipaměti balíčků lze také provést pomocí nástroje nuget.exe a spuštění příkazu nuget locals all -clear. nuget.exe není sbalené instalace s desktopovým operačním systémem Windows a musí být získána odděleně od webu NuGet.

  3. Obnovte a znovu sestavte projekt.

  4. Před opětovným nasazením aplikace odstraňte všechny soubory ve složce nasazení na serveru.

Další prostředky

Dokumentace Azure

Dokumentace sady Visual Studio

Dokumentace k editoru Visual Studio Code

Tento článek obsahuje informace o běžných chybách při spuštění aplikace a pokyny k diagnostice chyb při nasazení aplikace do služby Aplikace Azure service nebo služby IIS:

Chyby při spuštění aplikace
Vysvětluje běžné scénáře stavových kódů HTTP při spuštění.

Řešení potíží se službou Aplikace Azure Service
Poskytuje rady pro řešení potíží pro aplikace nasazené do služby Aplikace Azure Service.

Odstraňování potíží ve službě IIS
Poskytuje rady pro řešení potíží pro aplikace nasazené ve službě IIS nebo spuštěné místně ve službě IIS Express. Pokyny platí pro nasazení Windows Serveru i plochy Windows.

Vymazání mezipamětí balíčků
Vysvětluje, co dělat, když inkoherentní balíčky přeruší aplikaci při provádění hlavních upgradů nebo změn verzí balíčků.

Další materiály
Obsahuje další témata pro řešení potíží.

Chyby při spuštění aplikace

V sadě Visual Studio se ve výchozím nastavení projektu ASP.NET Core hostuje služba IIS Express během ladění. A 502.5 – Selhání procesu nebo 500.30 – Selhání spuštění, ke kterému dochází při místním ladění, lze diagnostikovat pomocí rad v tomto tématu.

403.14 Zakázáno

Aplikace se nespustí. Zaprotokoluje se následující chyba:

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

Příčinou chyby je obvykle poškozené nasazení v hostitelském systému, které zahrnuje některý z následujících scénářů:

  • Aplikace se nasadí do nesprávné složky v hostitelském systému.
  • Proces nasazení se nepovedlo přesunout všechny soubory a složky aplikace do složky nasazení v hostitelském systému.
  • V nasazení chybí soubor web.config nebo je poškozený obsah souboru web.config .

Proveďte následující kroky:

  1. Odstraňte všechny soubory a složky ze složky nasazení v hostitelském systému.
  2. Znovu nasaďte obsah složky publikování aplikace do hostitelského systému pomocí normální metody nasazení, jako je Visual Studio, PowerShell nebo ruční nasazení:
    • Ověřte, že se soubor web.config nachází v nasazení a zda je jeho obsah správný.
    • Při hostování ve službě Aplikace Azure Service ověřte, že je aplikace nasazená do D:\home\site\wwwroot složky.
    • Když je aplikace hostovaná službou IIS, ověřte, že je aplikace nasazená na fyzickou cestu IIS zobrazenou ve správci služby IIS Basic Nastavení.
  3. Ověřte, že jsou všechny soubory a složky aplikace nasazené tak, že porovnáte nasazení v hostitelském systému s obsahem složky publikování projektu.

Další informace o rozložení publikované aplikace ASP.NET Core najdete v tématu ASP.NET Základní adresářová struktura. Další informace o souboru web.config naleznete v tématu ASP.NET Základní modul (ANCM) pro službu IIS.

500 – Vnitřní chyba serveru

Aplikace se spustí, ale chyba brání serveru v plnění požadavku.

K této chybě dochází v kódu aplikace během spuštění nebo při vytváření odpovědi. Odpověď nemusí obsahovat žádný obsah nebo se může v prohlížeči zobrazit jako 500 vnitřní chyba serveru. Protokol událostí aplikace obvykle uvádí, že aplikace začala normálně. Z pohledu serveru je to správné. Aplikace se spustila, ale nemůže vygenerovat platnou odpověď. Spusťte aplikaci na příkazovém řádku na serveru nebo povolte protokol stdout modulu ASP.NET core a problém vyřešte.

K této chybě může dojít také v případě, že není nainstalovaná nebo poškozená sada hostingu .NET Core. Problém může vyřešit instalace nebo opravy sady .NET Core Hosting Bundle (pro IIS) nebo sady Visual Studio (pro SLUŽBU IIS Express).

Chyba načtení obslužné rutiny v procesu 500.0

Pracovní proces selže. Aplikace se nespustí.

Modul ASP.NET Core nedokáže najít modul CLR .NET Core a najít obslužnou rutinu žádosti v procesu (aspnetcorev2_inprocess.dll). Zkontrolujte, že:

500.0 Selhání načtení obslužné rutiny mimo proces

Pracovní proces selže. Aplikace se nespustí.

Základní modul ASP.NET nedokáže zjistit obslužnou rutinu žádosti o hostování mimo proces. Ujistěte se, že je aspnetcorev2_outofprocess.dll v podsložce vedle aspnetcorev2.dll.

Selhání procesu 502.5

Pracovní proces selže. Aplikace se nespustí.

Modul ASP.NET Core se pokusí spustit pracovní proces, ale nepodaří se ho spustit. Příčinu selhání spuštění procesu je obvykle možné určit z položek v protokolu událostí aplikace a protokolu stdout modulu ASP.NET Core Module stdout.

Běžnou chybovou podmínkou je, že aplikace je chybně nakonfigurovaná kvůli cílení na verzi sdílené architektury ASP.NET Core, která není k dispozici. Zkontrolujte, které verze sdílené architektury ASP.NET Core jsou nainstalované na cílovém počítači. Sdílená architektura je sada sestavení (soubory .dll ), které jsou nainstalovány v počítači a odkazovány metabalíkem, jako Microsoft.AspNetCore.Appje . Odkaz na metabalídu může určit minimální požadovanou verzi. Další informace naleznete v části Sdílená architektura.

Chybová stránka selhání procesu 502.5 se vrátí, když hostitelský nebo aplikační chybná konfigurace způsobí selhání pracovního procesu:

Spuštění aplikace (ErrorCode 0x800700c1) se nezdařilo.

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

Aplikaci se nepodařilo spustit, protože sestavení aplikace (.dll) se nepodařilo načíst.

K této chybě dochází v případě neshody bitů mezi publikovanou aplikací a procesem w3wp/iisexpress.

Ověřte správnost nastavení 32bitového fondu aplikací:

  1. Vyberte fond aplikací ve fondech aplikací Správce služby IIS.
  2. V části Upravit fond aplikací na panelu Akce vyberte Upřesnit Nastavení.
  3. Nastavení povolení 32bitových aplikací:
    • Pokud nasazujete 32bitovou aplikaci (x86), nastavte hodnotu na True.
    • Pokud nasazujete 64bitovou (x64) aplikaci, nastavte hodnotu na Falsehodnotu .

Ověřte, že mezi vlastností MSBuild v souboru projektu a publikovanou bitovou verzí aplikace není konflikt <Platform> .

resetování Připojení

Pokud po odeslání hlaviček dojde k chybě, je příliš pozdě na to, aby server při výskytu chyby odeslal chybu 500 Interní server . K tomu často dochází v případě, že dojde k chybě během serializace složitých objektů pro odpověď. Tento typ chyby se v klientovi zobrazí jako chyba resetování připojení. Protokolování aplikace může pomoct při řešení těchto typů chyb.

Výchozí limity spouštění

Modul ASP.NET Core je nakonfigurovaný s výchozí hodnotou startupTimeLimit 120 sekund. Když ponecháte výchozí hodnotu, může spuštění aplikace trvat až dvě minuty, než modul zaznamená selhání procesu. Informace o konfiguraci modulu naleznete v tématu Atributy aspNetCore elementu.

Řešení potíží se službou Aplikace Azure Service

Důležité

verze ASP.NET Core Preview se službou Aplikace Azure Service

ASP.NET verze Preview core se ve výchozím nastavení nenasazují do služby Aplikace Azure Service. Pokud chcete hostovat aplikaci, která používá verzi ASP.NET Core Preview, přečtěte si téma Nasazení verze ASP.NET Core Preview do služby Aplikace Azure Service.

Protokol událostí aplikace (služba Aplikace Azure)

Pokud chcete získat přístup k protokolu událostí aplikace, použijte okno Diagnostika a řešení problémů na webu Azure Portal:

  1. Na webu Azure Portal otevřete aplikaci ve službě App Services.
  2. Vyberte Diagnostikovat a řešit problémy.
  3. Vyberte nadpis Diagnostické nástroje.
  4. V části Nástroje podpory vyberte tlačítko Události aplikace.
  5. Zkontrolujte nejnovější chybu, kterou poskytuje položka IIS AspNetCoreModule nebo IIS AspNetCoreModule V2 ve sloupci Zdroj .

Alternativou k použití okna Diagnostika a řešení problémů je prozkoumání souboru protokolu událostí aplikace přímo pomocí Kudu:

  1. Otevřete rozšířené nástroje v oblasti Vývojové nástroje. Vyberte tlačítko Přejít→. Konzola Kudu se otevře na nové kartě nebo okně prohlížeče.
  2. Pomocí navigačního panelu v horní části stránky otevřete konzolu Ladění a vyberte CMD.
  3. Otevřete složku LogFiles.
  4. Vyberte ikonu tužky eventlog.xml vedle souboru.
  5. Zkontrolujte protokol. Posuňte se do dolní části protokolu a zobrazte nejnovější události.

Spuštění aplikace v konzole Kudu

Mnoho chyb při spuštění negeneruje užitečné informace v protokolu událostí aplikace. Aplikaci můžete spustit v konzole vzdáleného spuštění Kudu a zjistit chybu:

  1. Otevřete rozšířené nástroje v oblasti Vývojové nástroje. Vyberte tlačítko Přejít→. Konzola Kudu se otevře na nové kartě nebo okně prohlížeče.
  2. Pomocí navigačního panelu v horní části stránky otevřete konzolu Ladění a vyberte CMD.

Testování 32bitové aplikace (x86)

Aktuální verze

  1. cd d:\home\site\wwwroot
  2. Spusťte aplikaci:

Výstup konzoly z aplikace zobrazující případné chyby se předá do konzoly Kudu.

Nasazení závislé na rozhraní spuštěné ve verzi Preview

Vyžaduje instalaci rozšíření lokality modulu runtime ASP.NET Core {VERSION} (x86).

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} je verze modulu runtime)
  2. Spusťte aplikaci: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Výstup konzoly z aplikace zobrazující případné chyby se předá do konzoly Kudu.

Testování 64bitové aplikace (x64)

Aktuální verze

  • Pokud je aplikace 64bitové (x64) nasazení závislé na rozhraní:
    1. cd D:\Program Files\dotnet
    2. Spusťte aplikaci: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
  • Pokud se jedná o samostatné nasazení:
    1. cd D:\home\site\wwwroot
    2. Spusťte aplikaci: {ASSEMBLY NAME}.exe

Výstup konzoly z aplikace zobrazující případné chyby se předá do konzoly Kudu.

Nasazení závislé na rozhraní spuštěné ve verzi Preview

Vyžaduje instalaci rozšíření lokality modulu runtime ASP.NET Core {VERSION} (x64).

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} je verze modulu runtime)
  2. Spusťte aplikaci: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Výstup konzoly z aplikace zobrazující případné chyby se předá do konzoly Kudu.

protokol stdout modulu ASP.NET Core (služba Aplikace Azure)

Protokol stdout základního modulu ASP.NET často zaznamenává užitečné chybové zprávy, které se v protokolu událostí aplikace nenašly. Povolení a zobrazení protokolů stdout:

  1. Na webu Azure Portal přejděte do okna Diagnostika a řešení problémů .
  2. V části SELECT PROBLEM CATEGORY (VYBRAT KATEGORII PROBLÉMU) vyberte tlačítko Web App Down (Webová aplikace dolů ).
  3. V části Navrhovaná řešení>povolit přesměrování protokolu stdout vyberte tlačítko otevřít konzolu Kudu pro úpravu Web.Config.
  4. V konzole diagnostiky Kudu otevřete složky na webu wwwroot> cesty. Posuňte se dolů a zobrazte soubor web.config v dolní části seznamu.
  5. Klikněte na ikonu tužky vedle souboru web.config .
  6. Nastavte stdoutLogEnabled na true a změňte cestu stdoutLogFile na: \\?\%home%\LogFiles\stdout.
  7. Výběrem možnosti Uložit uložte aktualizovaný soubor web.config .
  8. Vytvořte žádost o aplikaci.
  9. Vraťte se na Azure Portal. V oblasti VÝVOJOVÉ NÁSTROJE vyberte okno Rozšířené nástroje. Vyberte tlačítko Přejít→. Konzola Kudu se otevře na nové kartě nebo okně prohlížeče.
  10. Pomocí navigačního panelu v horní části stránky otevřete konzolu Ladění a vyberte CMD.
  11. Vyberte složku LogFiles.
  12. Zkontrolujte sloupec Změněno a výběrem ikony tužky upravte protokol stdout s datem poslední úpravy.
  13. Po otevření souboru protokolu se zobrazí chyba.

Po dokončení řešení potíží zakažte protokolování stdout:

  1. V konzole diagnostiky Kudu se vraťte na web cesty> wwwroot a zobrazte soubor web.config. Znovu otevřete soubor web.config tak, že vyberete ikonu tužky.
  2. Nastavte stdoutLogEnabled na false.
  3. Výběrem možnosti Uložit soubor uložte.

Další informace najdete v tématu Modul ASP.NET Core (ANCM) pro službu IIS.

Upozorňující

Selhání zakázání protokolu stdout může vést k selhání aplikace nebo serveru. Velikost souboru protokolu ani počet vytvořených souborů protokolu není nijak omezený. K řešení problémů se spuštěním aplikace používejte pouze protokolování stdout.

Pro obecné protokolování v aplikaci ASP.NET Core po spuštění použijte knihovnu protokolování, která omezuje velikost souboru protokolu a obměňuje protokoly. Další informace najdete v tématu Zprostředkovatelé protokolování třetích stran.

protokol ladění základního modulu ASP.NET (služba Aplikace Azure)

Protokol ladění základního modulu ASP.NET poskytuje další podrobnější protokolování z modulu ASP.NET Core. Povolení a zobrazení protokolů stdout:

  1. Pokud chcete povolit rozšířený diagnostický protokol, proveďte jednu z následujících akcí:
    • Podle pokynů v rozšířených diagnostických protokolech nakonfigurujte aplikaci pro rozšířené protokolování diagnostiky. Opětovné nasazení aplikace.
    • <handlerSettings> Pomocí konzoly Kudu přidejte do souboru web.config živé aplikace zobrazené v rozšířených diagnostických protokolech:
      1. Otevřete rozšířené nástroje v oblasti Vývojové nástroje. Vyberte tlačítko Přejít→. Konzola Kudu se otevře na nové kartě nebo okně prohlížeče.
      2. Pomocí navigačního panelu v horní části stránky otevřete konzolu Ladění a vyberte CMD.
      3. Otevřete složky na webu wwwroot> cesty. Upravte soubor web.config tak, že vyberete tlačítko tužky. <handlerSettings> Přidejte oddíl, jak je znázorněno v rozšířených diagnostických protokolech. Vyberte tlačítko Uložit.
  2. Otevřete rozšířené nástroje v oblasti Vývojové nástroje. Vyberte tlačítko Přejít→. Konzola Kudu se otevře na nové kartě nebo okně prohlížeče.
  3. Pomocí navigačního panelu v horní části stránky otevřete konzolu Ladění a vyberte CMD.
  4. Otevřete složky na webu wwwroot> cesty. Pokud jste pro soubor aspnetcore-debug.log nezadali cestu, soubor se zobrazí v seznamu. Pokud jste zadali cestu, přejděte do umístění souboru protokolu.
  5. Otevřete soubor protokolu pomocí tlačítka tužky vedle názvu souboru.

Po dokončení řešení potíží zakažte protokolování ladění:

Pokud chcete rozšířený protokol ladění zakázat, proveďte jednu z následujících akcí:

  • <handlerSettings> Odeberte soubor web.config místně a znovu nasaďte aplikaci.
  • Pomocí konzoly Kudu upravte soubor web.config a odeberte <handlerSettings> oddíl. Soubor uložte.

Další informace najdete v tématu Vytvoření protokolu a přesměrování pomocí modulu ASP.NET Core.

Upozorňující

Selhání zakázání protokolu ladění může vést k selhání aplikace nebo serveru. Velikost souboru protokolu není nijak omezena. K řešení problémů se spuštěním aplikace používejte protokolování ladění.

Pro obecné protokolování v aplikaci ASP.NET Core po spuštění použijte knihovnu protokolování, která omezuje velikost souboru protokolu a obměňuje protokoly. Další informace najdete v tématu Zprostředkovatelé protokolování třetích stran.

Pomalá nebo zablokovat aplikace (služba Aplikace Azure)

Když aplikace na žádost reaguje pomalu nebo zablokuje, přečtěte si následující články:

Okna monitorování

Okna monitorování poskytují alternativní řešení potíží s metodami popsanými výše v tématu. Tato okna se dají použít k diagnostice chyb řady 500.

Ověřte, že jsou nainstalovaná rozšíření ASP.NET Core Extensions. Pokud se rozšíření nenainstalují, nainstalujte je ručně:

  1. V části OKNA VÝVOJOVÉ NÁSTROJE vyberte okno Rozšíření.
  2. V seznamu by se měla zobrazit ASP.NET základní rozšíření .
  3. Pokud rozšíření nejsou nainstalovaná, vyberte tlačítko Přidat .
  4. Ze seznamu vyberte ASP.NET Core Extensions.
  5. Výběrem OK přijměte právní podmínky.
  6. V okně Přidat rozšíření vyberte OK.
  7. Informační automaticky otevíraná zpráva indikuje, kdy se rozšíření úspěšně nainstalují.

Pokud není povolené protokolování stdout, postupujte takto:

  1. Na webu Azure Portal vyberte okno Rozšířené nástroje v oblasti VÝVOJOVÉ NÁSTROJE . Vyberte tlačítko Přejít→. Konzola Kudu se otevře na nové kartě nebo okně prohlížeče.
  2. Pomocí navigačního panelu v horní části stránky otevřete konzolu Ladění a vyberte CMD.
  3. Otevřete složky na webu wwwroot> cesty a posuňte se dolů a zobrazte soubor web.config v dolní části seznamu.
  4. Klikněte na ikonu tužky vedle souboru web.config .
  5. Nastavte stdoutLogEnabled na true a změňte cestu stdoutLogFile na: \\?\%home%\LogFiles\stdout.
  6. Výběrem možnosti Uložit uložte aktualizovaný soubor web.config .

Pokračujte aktivací protokolování diagnostiky:

  1. Na webu Azure Portal vyberte okno Diagnostické protokoly .
  2. Vyberte přepínač Zapnuto pro protokolování aplikace (systém souborů) a podrobné chybové zprávy. Vyberte tlačítko Uložit v horní části okna.
  3. Pokud chcete zahrnout trasování neúspěšných požadavků, označované také jako protokolování ukládání do vyrovnávací paměti neúspěšných požadavků (FREB), vyberte přepínač Zapnuto pro trasování neúspěšných požadavků.
  4. Vyberte okno Stream protokolu, které se zobrazí okamžitě v okně Diagnostické protokoly na portálu.
  5. Vytvořte žádost o aplikaci.
  6. V rámci dat datového proudu protokolu je uvedena příčina chyby.

Po dokončení řešení potíží nezapomeňte protokolování stdout zakázat.

Zobrazení protokolů trasování neúspěšných požadavků (protokoly FREB):

  1. Na webu Azure Portal přejděte do okna Diagnostika a řešení problémů .
  2. V oblasti NÁSTROJE PODPORY na bočním panelu vyberte protokoly trasování neúspěšných požadavků.

Další informace najdete v části Trasování neúspěšných požadavků v tématu Povolení protokolování diagnostiky pro webové aplikace v tématu služby Aplikace Azure Service a nejčastější dotazy k výkonu aplikací pro Web Apps v Azure: Návody zapnout trasování neúspěšných požadavků?

Další informace najdete v tématu Povolení protokolování diagnostiky pro webové aplikace ve službě Aplikace Azure Service.

Upozorňující

Selhání zakázání protokolu stdout může vést k selhání aplikace nebo serveru. Velikost souboru protokolu ani počet vytvořených souborů protokolu není nijak omezený.

Pro rutinní protokolování v aplikaci ASP.NET Core použijte knihovnu protokolování, která omezuje velikost souboru protokolu a obměňuje protokoly. Další informace najdete v tématu Zprostředkovatelé protokolování třetích stran.

Odstraňování potíží ve službě IIS

Protokol událostí aplikace (IIS)

Přístup k protokolu událostí aplikace:

  1. Otevřete nabídka Start, vyhledejte Prohlížeč událostí a vyberte aplikaci Prohlížeč událostí.
  2. V Prohlížeč událostí otevřete uzel Protokoly systému Windows.
  3. Výběrem možnosti Aplikace otevřete protokol událostí aplikace.
  4. Vyhledejte chyby spojené s neúspěšnou aplikací. Chyby mají hodnotu modulu IIS AspNetCore nebo modulu IIS Express AspNetCore ve sloupci Zdroj .

Spuštění aplikace na příkazovém řádku

Mnoho chyb při spuštění negeneruje užitečné informace v protokolu událostí aplikace. Příčinu některých chyb můžete zjistit spuštěním aplikace na příkazovém řádku v hostitelském systému.

Nasazení závislé na rozhraní

Pokud je aplikace nasazení závislé na rozhraní:

  1. Na příkazovém řádku přejděte do složky nasazení a spusťte aplikaci spuštěním sestavení aplikace s dotnet.exe. V následujícím příkazu nahraďte název sestavení aplikace assembly_name<>: dotnet .\<assembly_name>.dll.
  2. Výstup konzoly z aplikace zobrazující případné chyby se zapíše do okna konzoly.
  3. Pokud dojde k chybám při vytváření požadavku na aplikaci, odešlete žádost hostiteli a portu, kde Kestrel naslouchá. Pomocí výchozího hostitele a příspěvku proveďte požadavek na http://localhost:5000/. Pokud aplikace normálně reaguje na adrese koncového Kestrel bodu, problém pravděpodobně souvisí s konfigurací hostování a méně pravděpodobné v rámci aplikace.

Samostatné nasazení

Pokud se jedná o samostatné nasazení:

  1. Na příkazovém řádku přejděte do složky nasazení a spusťte spustitelný soubor aplikace. V následujícím příkazu nahraďte název sestavení aplikace assembly_name<>: <assembly_name>.exe.
  2. Výstup konzoly z aplikace zobrazující případné chyby se zapíše do okna konzoly.
  3. Pokud dojde k chybám při vytváření požadavku na aplikaci, odešlete žádost hostiteli a portu, kde Kestrel naslouchá. Pomocí výchozího hostitele a příspěvku proveďte požadavek na http://localhost:5000/. Pokud aplikace normálně reaguje na adrese koncového Kestrel bodu, problém pravděpodobně souvisí s konfigurací hostování a méně pravděpodobné v rámci aplikace.

protokol stdout modulu ASP.NET Core (IIS)

Povolení a zobrazení protokolů stdout:

  1. Přejděte do složky nasazení webu v hostitelském systému.
  2. Pokud složka protokolů není k dispozici, vytvořte ji. Pokyny k automatickému vytvoření složky protokolů v nasazení pomocí nástroje MSBuild najdete v tématu Struktura adresářů .
  3. Upravte soubor web.config. Nastavte stdoutLogEnabled a změňte cestu stdoutLogFile tak, aby odkazovala na složku protokolů (například.\logs\stdout).true stdout v cestě je předpona názvu souboru protokolu. Při vytváření protokolu se automaticky přidá časové razítko, ID procesu a přípona souboru. Jako stdout předponu názvu souboru se typický soubor protokolu nazývá stdout_20180205184032_5412.log.
  4. Ujistěte se, že identita fondu aplikací má oprávnění k zápisu do složky protokolů .
  5. Uložte aktualizovaný soubor web.config .
  6. Vytvořte žádost o aplikaci.
  7. Přejděte do složky protokolů . Vyhledejte a otevřete nejnovější protokol stdout.
  8. Prostudujte protokol chyb.

Po dokončení řešení potíží zakažte protokolování stdout:

  1. Upravte soubor web.config.
  2. Nastavte stdoutLogEnabled na false.
  3. Soubor uložte.

Další informace najdete v tématu Modul ASP.NET Core (ANCM) pro službu IIS.

Upozorňující

Selhání zakázání protokolu stdout může vést k selhání aplikace nebo serveru. Velikost souboru protokolu ani počet vytvořených souborů protokolu není nijak omezený.

Pro rutinní protokolování v aplikaci ASP.NET Core použijte knihovnu protokolování, která omezuje velikost souboru protokolu a obměňuje protokoly. Další informace najdete v tématu Zprostředkovatelé protokolování třetích stran.

protokol ladění základního modulu ASP.NET (IIS)

Do souboru web.config aplikace přidejte následující nastavení obslužné rutiny, aby se povolil protokol ladění základního modulu ASP.NET:

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

Ověřte, že cesta zadaná pro protokol existuje a že identita fondu aplikací má oprávnění k zápisu do umístění.

Další informace najdete v tématu Vytvoření protokolu a přesměrování pomocí modulu ASP.NET Core.

Povolení stránky výjimek pro vývojáře

Proměnnou ASPNETCORE_ENVIRONMENTprostředí je možné přidat do souboru web.config , aby se aplikace spustila ve vývojovém prostředí. Pokud se prostředí nepřepíše při spuštění aplikace v UseEnvironment tvůrci hostitelů, nastavení proměnné prostředí umožňuje , aby se při spuštění aplikace zobrazila stránka výjimky vývojáře.

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

Nastavení proměnné ASPNETCORE_ENVIRONMENT prostředí se doporučuje jenom pro pracovní a testovací servery, které nejsou vystavené internetu. Po řešení potíží odeberte proměnnou prostředí ze souboru web.config . Informace o nastavení proměnných prostředí ve web.config naleznete v tématu environmentVariables podřízený prvek aspNetCore.

Získání dat z aplikace

Pokud aplikace dokáže reagovat na požadavky, získat požadavek, připojení a další data z aplikace pomocí vloženého middlewaru terminálu. Další informace a vzorový kód najdete v tématu Řešení potíží a ladění ASP.NET základních projektů.

Pomalé nebo zablokování aplikace (IIS)

Výpis stavu systému je snímek paměti systému a může pomoct určit příčinu chybového ukončení aplikace, selhání spuštění nebo pomalé aplikace.

Aplikace se chybově ukončí nebo dojde k výjimce

Získání a analýza výpisu paměti z Zasílání zpráv o chybách systému Windows (WER):

  1. Vytvořte složku pro ukládání souborů s výpisem stavu systému na adrese c:\dumps. Fond aplikací musí mít ke složce přístup pro zápis.

  2. Spusťte skript PowerShellu EnableDumps:

    • Pokud aplikace používá model hostování v procesu, spusťte skript pro w3wp.exe:

      .\EnableDumps w3wp.exe c:\dumps
      
    • Pokud aplikace používá model hostování mimo proces, spusťte skript pro dotnet.exe:

      .\EnableDumps dotnet.exe c:\dumps
      
  3. Spusťte aplikaci za podmínek, které způsobují chybové ukončení.

  4. Po chybě spusťte skript DisableDumps PowerShellu:

    • Pokud aplikace používá model hostování v procesu, spusťte skript pro w3wp.exe:

      .\DisableDumps w3wp.exe
      
    • Pokud aplikace používá model hostování mimo proces, spusťte skript pro dotnet.exe:

      .\DisableDumps dotnet.exe
      

Po chybovém ukončení aplikace a dokončení shromažďování výpisů paměti se aplikace může normálně ukončit. Skript PowerShellu konfiguruje WER tak, aby shromáždil až pět výpisů paměti na aplikaci.

Upozorňující

Výpisy stavu systému můžou zabírat velké množství místa na disku (až několik gigabajtů).

Aplikace přestane reagovat, selže při spuštění nebo se normálně spustí

Když aplikace přestane reagovat (přestane reagovat, ale neuspěje), selže při spuštění nebo se spustí normálně, přečtěte si téma Soubory výpisu stavu stavu systému v uživatelském režimu: Volba nejvhodnějšího nástroje pro výběr vhodného nástroje pro vytvoření výpisu paměti.

Analýza výpisu paměti

Výpis paměti je možné analyzovat pomocí několika přístupů. Další informace naleznete v tématu Analýza souboru výpisu stavu systému v uživatelském režimu.

Vymazání mezipamětí balíčků

Funkční aplikace může selhat okamžitě po upgradu sady .NET Core SDK na vývojovém počítači nebo změně verzí balíčků v aplikaci. V některých případech můžou inkoherentní balíčky přerušit aplikaci při provádění hlavních upgradů. Většinu těchto problémů je možné vyřešit pomocí těchto pokynů:

  1. Odstraňte přihrádku a složky obj.

  2. Vymažte mezipaměti balíčků spuštěním dotnet nuget locals all --clear z příkazového prostředí.

    Vymazání mezipaměti balíčků lze také provést pomocí nástroje nuget.exe a spuštění příkazu nuget locals all -clear. nuget.exe není sbalené instalace s desktopovým operačním systémem Windows a musí být získána odděleně od webu NuGet.

  3. Obnovte a znovu sestavte projekt.

  4. Před opětovným nasazením aplikace odstraňte všechny soubory ve složce nasazení na serveru.

Další prostředky

Dokumentace Azure

Dokumentace sady Visual Studio

Dokumentace k editoru Visual Studio Code

Tento článek obsahuje informace o běžných chybách při spuštění aplikace a pokyny k diagnostice chyb při nasazení aplikace do služby Aplikace Azure service nebo služby IIS:

Chyby při spuštění aplikace
Vysvětluje běžné scénáře stavových kódů HTTP při spuštění.

Řešení potíží se službou Aplikace Azure Service
Poskytuje rady pro řešení potíží pro aplikace nasazené do služby Aplikace Azure Service.

Odstraňování potíží ve službě IIS
Poskytuje rady pro řešení potíží pro aplikace nasazené ve službě IIS nebo spuštěné místně ve službě IIS Express. Pokyny platí pro nasazení Windows Serveru i plochy Windows.

Vymazání mezipamětí balíčků
Vysvětluje, co dělat, když inkoherentní balíčky přeruší aplikaci při provádění hlavních upgradů nebo změn verzí balíčků.

Další materiály
Obsahuje další témata pro řešení potíží.

Chyby při spuštění aplikace

V sadě Visual Studio se ve výchozím nastavení projektu ASP.NET Core hostuje služba IIS Express během ladění. Selhání procesu 502.5, ke kterému dochází při místním ladění, lze diagnostikovat pomocí rad v tomto tématu.

403.14 Zakázáno

Aplikace se nespustí. Zaprotokoluje se následující chyba:

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

Příčinou chyby je obvykle poškozené nasazení v hostitelském systému, které zahrnuje některý z následujících scénářů:

  • Aplikace se nasadí do nesprávné složky v hostitelském systému.
  • Proces nasazení se nepovedlo přesunout všechny soubory a složky aplikace do složky nasazení v hostitelském systému.
  • V nasazení chybí soubor web.config nebo je poškozený obsah souboru web.config .

Proveďte následující kroky:

  1. Odstraňte všechny soubory a složky ze složky nasazení v hostitelském systému.
  2. Znovu nasaďte obsah složky publikování aplikace do hostitelského systému pomocí normální metody nasazení, jako je Visual Studio, PowerShell nebo ruční nasazení:
    • Ověřte, že se soubor web.config nachází v nasazení a zda je jeho obsah správný.
    • Při hostování ve službě Aplikace Azure Service ověřte, že je aplikace nasazená do D:\home\site\wwwroot složky.
    • Když je aplikace hostovaná službou IIS, ověřte, že je aplikace nasazená na fyzickou cestu IIS zobrazenou ve správci služby IIS Basic Nastavení.
  3. Ověřte, že jsou všechny soubory a složky aplikace nasazené tak, že porovnáte nasazení v hostitelském systému s obsahem složky publikování projektu.

Další informace o rozložení publikované aplikace ASP.NET Core najdete v tématu ASP.NET Základní adresářová struktura. Další informace o souboru web.config naleznete v tématu ASP.NET Základní modul (ANCM) pro službu IIS.

500 – Vnitřní chyba serveru

Aplikace se spustí, ale chyba brání serveru v plnění požadavku.

K této chybě dochází v kódu aplikace během spuštění nebo při vytváření odpovědi. Odpověď nemusí obsahovat žádný obsah nebo se může v prohlížeči zobrazit jako 500 vnitřní chyba serveru. Protokol událostí aplikace obvykle uvádí, že aplikace začala normálně. Z pohledu serveru je to správné. Aplikace se spustila, ale nemůže vygenerovat platnou odpověď. Spusťte aplikaci na příkazovém řádku na serveru nebo povolte protokol stdout modulu ASP.NET core a problém vyřešte.

K této chybě může dojít také v případě, že není nainstalovaná nebo poškozená sada hostingu .NET Core. Problém může vyřešit instalace nebo opravy sady .NET Core Hosting Bundle (pro IIS) nebo sady Visual Studio (pro SLUŽBU IIS Express).

Selhání procesu 502.5

Pracovní proces selže. Aplikace se nespustí.

Modul ASP.NET Core se pokusí spustit pracovní proces, ale nepodaří se ho spustit. Příčinu selhání spuštění procesu je obvykle možné určit z položek v protokolu událostí aplikace a protokolu stdout modulu ASP.NET Core Module stdout.

Běžnou chybovou podmínkou je, že aplikace je chybně nakonfigurovaná kvůli cílení na verzi sdílené architektury ASP.NET Core, která není k dispozici. Zkontrolujte, které verze sdílené architektury ASP.NET Core jsou nainstalované na cílovém počítači. Sdílená architektura je sada sestavení (soubory .dll ), které jsou nainstalovány v počítači a odkazovány metabalíkem, jako Microsoft.AspNetCore.Appje . Odkaz na metabalídu může určit minimální požadovanou verzi. Další informace naleznete v části Sdílená architektura.

Chybová stránka selhání procesu 502.5 se vrátí, když hostitelský nebo aplikační chybná konfigurace způsobí selhání pracovního procesu:

Spuštění aplikace (ErrorCode 0x800700c1) se nezdařilo.

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

Aplikaci se nepodařilo spustit, protože sestavení aplikace (.dll) se nepodařilo načíst.

K této chybě dochází v případě neshody bitů mezi publikovanou aplikací a procesem w3wp/iisexpress.

Ověřte správnost nastavení 32bitového fondu aplikací:

  1. Vyberte fond aplikací ve fondech aplikací Správce služby IIS.
  2. V části Upravit fond aplikací na panelu Akce vyberte Upřesnit Nastavení.
  3. Nastavení povolení 32bitových aplikací:
    • Pokud nasazujete 32bitovou aplikaci (x86), nastavte hodnotu na True.
    • Pokud nasazujete 64bitovou (x64) aplikaci, nastavte hodnotu na Falsehodnotu .

Ověřte, že mezi vlastností MSBuild v souboru projektu a publikovanou bitovou verzí aplikace není konflikt <Platform> .

resetování Připojení

Pokud po odeslání hlaviček dojde k chybě, je příliš pozdě na to, aby server při výskytu chyby odeslal chybu 500 Interní server . K tomu často dochází v případě, že dojde k chybě během serializace složitých objektů pro odpověď. Tento typ chyby se v klientovi zobrazí jako chyba resetování připojení. Protokolování aplikace může pomoct při řešení těchto typů chyb.

Výchozí limity spouštění

Modul ASP.NET Core je nakonfigurovaný s výchozí hodnotou startupTimeLimit 120 sekund. Když ponecháte výchozí hodnotu, může spuštění aplikace trvat až dvě minuty, než modul zaznamená selhání procesu. Informace o konfiguraci modulu naleznete v tématu Atributy aspNetCore elementu.

Řešení potíží se službou Aplikace Azure Service

Důležité

verze ASP.NET Core Preview se službou Aplikace Azure Service

ASP.NET verze Preview core se ve výchozím nastavení nenasazují do služby Aplikace Azure Service. Pokud chcete hostovat aplikaci, která používá verzi ASP.NET Core Preview, přečtěte si téma Nasazení verze ASP.NET Core Preview do služby Aplikace Azure Service.

Protokol událostí aplikace (služba Aplikace Azure)

Pokud chcete získat přístup k protokolu událostí aplikace, použijte okno Diagnostika a řešení problémů na webu Azure Portal:

  1. Na webu Azure Portal otevřete aplikaci ve službě App Services.
  2. Vyberte Diagnostikovat a řešit problémy.
  3. Vyberte nadpis Diagnostické nástroje.
  4. V části Nástroje podpory vyberte tlačítko Události aplikace.
  5. Zkontrolujte nejnovější chybu, kterou poskytuje položka IIS AspNetCoreModule nebo IIS AspNetCoreModule V2 ve sloupci Zdroj .

Alternativou k použití okna Diagnostika a řešení problémů je prozkoumání souboru protokolu událostí aplikace přímo pomocí Kudu:

  1. Otevřete rozšířené nástroje v oblasti Vývojové nástroje. Vyberte tlačítko Přejít→. Konzola Kudu se otevře na nové kartě nebo okně prohlížeče.
  2. Pomocí navigačního panelu v horní části stránky otevřete konzolu Ladění a vyberte CMD.
  3. Otevřete složku LogFiles.
  4. Vyberte ikonu tužky eventlog.xml vedle souboru.
  5. Zkontrolujte protokol. Posuňte se do dolní části protokolu a zobrazte nejnovější události.

Spuštění aplikace v konzole Kudu

Mnoho chyb při spuštění negeneruje užitečné informace v protokolu událostí aplikace. Aplikaci můžete spustit v konzole vzdáleného spuštění Kudu a zjistit chybu:

  1. Otevřete rozšířené nástroje v oblasti Vývojové nástroje. Vyberte tlačítko Přejít→. Konzola Kudu se otevře na nové kartě nebo okně prohlížeče.
  2. Pomocí navigačního panelu v horní části stránky otevřete konzolu Ladění a vyberte CMD.

Testování 32bitové aplikace (x86)

Aktuální verze

  1. cd d:\home\site\wwwroot
  2. Spusťte aplikaci:

Výstup konzoly z aplikace zobrazující případné chyby se předá do konzoly Kudu.

Nasazení závislé na rozhraní spuštěné ve verzi Preview

Vyžaduje instalaci rozšíření lokality modulu runtime ASP.NET Core {VERSION} (x86).

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} je verze modulu runtime)
  2. Spusťte aplikaci: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Výstup konzoly z aplikace zobrazující případné chyby se předá do konzoly Kudu.

Testování 64bitové aplikace (x64)

Aktuální verze

  • Pokud je aplikace 64bitové (x64) nasazení závislé na rozhraní:
    1. cd D:\Program Files\dotnet
    2. Spusťte aplikaci: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
  • Pokud se jedná o samostatné nasazení:
    1. cd D:\home\site\wwwroot
    2. Spusťte aplikaci: {ASSEMBLY NAME}.exe

Výstup konzoly z aplikace zobrazující případné chyby se předá do konzoly Kudu.

Nasazení závislé na rozhraní spuštěné ve verzi Preview

Vyžaduje instalaci rozšíření lokality modulu runtime ASP.NET Core {VERSION} (x64).

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} je verze modulu runtime)
  2. Spusťte aplikaci: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Výstup konzoly z aplikace zobrazující případné chyby se předá do konzoly Kudu.

protokol stdout modulu ASP.NET Core (služba Aplikace Azure)

Protokol stdout základního modulu ASP.NET často zaznamenává užitečné chybové zprávy, které se v protokolu událostí aplikace nenašly. Povolení a zobrazení protokolů stdout:

  1. Na webu Azure Portal přejděte do okna Diagnostika a řešení problémů .
  2. V části SELECT PROBLEM CATEGORY (VYBRAT KATEGORII PROBLÉMU) vyberte tlačítko Web App Down (Webová aplikace dolů ).
  3. V části Navrhovaná řešení>povolit přesměrování protokolu stdout vyberte tlačítko otevřít konzolu Kudu pro úpravu Web.Config.
  4. V konzole diagnostiky Kudu otevřete složky na webu wwwroot> cesty. Posuňte se dolů a zobrazte soubor web.config v dolní části seznamu.
  5. Klikněte na ikonu tužky vedle souboru web.config .
  6. Nastavte stdoutLogEnabled na true a změňte cestu stdoutLogFile na: \\?\%home%\LogFiles\stdout.
  7. Výběrem možnosti Uložit uložte aktualizovaný soubor web.config .
  8. Vytvořte žádost o aplikaci.
  9. Vraťte se na Azure Portal. V oblasti VÝVOJOVÉ NÁSTROJE vyberte okno Rozšířené nástroje. Vyberte tlačítko Přejít→. Konzola Kudu se otevře na nové kartě nebo okně prohlížeče.
  10. Pomocí navigačního panelu v horní části stránky otevřete konzolu Ladění a vyberte CMD.
  11. Vyberte složku LogFiles.
  12. Zkontrolujte sloupec Změněno a výběrem ikony tužky upravte protokol stdout s datem poslední úpravy.
  13. Po otevření souboru protokolu se zobrazí chyba.

Po dokončení řešení potíží zakažte protokolování stdout:

  1. V konzole diagnostiky Kudu se vraťte na web cesty> wwwroot a zobrazte soubor web.config. Znovu otevřete soubor web.config tak, že vyberete ikonu tužky.
  2. Nastavte stdoutLogEnabled na false.
  3. Výběrem možnosti Uložit soubor uložte.

Další informace najdete v tématu Modul ASP.NET Core (ANCM) pro službu IIS.

Upozorňující

Selhání zakázání protokolu stdout může vést k selhání aplikace nebo serveru. Velikost souboru protokolu ani počet vytvořených souborů protokolu není nijak omezený. K řešení problémů se spuštěním aplikace používejte pouze protokolování stdout.

Pro obecné protokolování v aplikaci ASP.NET Core po spuštění použijte knihovnu protokolování, která omezuje velikost souboru protokolu a obměňuje protokoly. Další informace najdete v tématu Zprostředkovatelé protokolování třetích stran.

Pomalá nebo zablokovat aplikace (služba Aplikace Azure)

Když aplikace na žádost reaguje pomalu nebo zablokuje, přečtěte si následující články:

Okna monitorování

Okna monitorování poskytují alternativní řešení potíží s metodami popsanými výše v tématu. Tato okna se dají použít k diagnostice chyb řady 500.

Ověřte, že jsou nainstalovaná rozšíření ASP.NET Core Extensions. Pokud se rozšíření nenainstalují, nainstalujte je ručně:

  1. V části OKNA VÝVOJOVÉ NÁSTROJE vyberte okno Rozšíření.
  2. V seznamu by se měla zobrazit ASP.NET základní rozšíření .
  3. Pokud rozšíření nejsou nainstalovaná, vyberte tlačítko Přidat .
  4. Ze seznamu vyberte ASP.NET Core Extensions.
  5. Výběrem OK přijměte právní podmínky.
  6. V okně Přidat rozšíření vyberte OK.
  7. Informační automaticky otevíraná zpráva indikuje, kdy se rozšíření úspěšně nainstalují.

Pokud není povolené protokolování stdout, postupujte takto:

  1. Na webu Azure Portal vyberte okno Rozšířené nástroje v oblasti VÝVOJOVÉ NÁSTROJE . Vyberte tlačítko Přejít→. Konzola Kudu se otevře na nové kartě nebo okně prohlížeče.
  2. Pomocí navigačního panelu v horní části stránky otevřete konzolu Ladění a vyberte CMD.
  3. Otevřete složky na webu wwwroot> cesty a posuňte se dolů a zobrazte soubor web.config v dolní části seznamu.
  4. Klikněte na ikonu tužky vedle souboru web.config .
  5. Nastavte stdoutLogEnabled na true a změňte cestu stdoutLogFile na: \\?\%home%\LogFiles\stdout.
  6. Výběrem možnosti Uložit uložte aktualizovaný soubor web.config .

Pokračujte aktivací protokolování diagnostiky:

  1. Na webu Azure Portal vyberte okno Diagnostické protokoly .
  2. Vyberte přepínač Zapnuto pro protokolování aplikace (systém souborů) a podrobné chybové zprávy. Vyberte tlačítko Uložit v horní části okna.
  3. Pokud chcete zahrnout trasování neúspěšných požadavků, označované také jako protokolování ukládání do vyrovnávací paměti neúspěšných požadavků (FREB), vyberte přepínač Zapnuto pro trasování neúspěšných požadavků.
  4. Vyberte okno Stream protokolu, které se zobrazí okamžitě v okně Diagnostické protokoly na portálu.
  5. Vytvořte žádost o aplikaci.
  6. V rámci dat datového proudu protokolu je uvedena příčina chyby.

Po dokončení řešení potíží nezapomeňte protokolování stdout zakázat.

Zobrazení protokolů trasování neúspěšných požadavků (protokoly FREB):

  1. Na webu Azure Portal přejděte do okna Diagnostika a řešení problémů .
  2. V oblasti NÁSTROJE PODPORY na bočním panelu vyberte protokoly trasování neúspěšných požadavků.

Další informace najdete v části Trasování neúspěšných požadavků v tématu Povolení protokolování diagnostiky pro webové aplikace v tématu služby Aplikace Azure Service a nejčastější dotazy k výkonu aplikací pro Web Apps v Azure: Návody zapnout trasování neúspěšných požadavků?

Další informace najdete v tématu Povolení protokolování diagnostiky pro webové aplikace ve službě Aplikace Azure Service.

Upozorňující

Selhání zakázání protokolu stdout může vést k selhání aplikace nebo serveru. Velikost souboru protokolu ani počet vytvořených souborů protokolu není nijak omezený.

Pro rutinní protokolování v aplikaci ASP.NET Core použijte knihovnu protokolování, která omezuje velikost souboru protokolu a obměňuje protokoly. Další informace najdete v tématu Zprostředkovatelé protokolování třetích stran.

Odstraňování potíží ve službě IIS

Protokol událostí aplikace (IIS)

Přístup k protokolu událostí aplikace:

  1. Otevřete nabídka Start, vyhledejte Prohlížeč událostí a vyberte aplikaci Prohlížeč událostí.
  2. V Prohlížeč událostí otevřete uzel Protokoly systému Windows.
  3. Výběrem možnosti Aplikace otevřete protokol událostí aplikace.
  4. Vyhledejte chyby spojené s neúspěšnou aplikací. Chyby mají hodnotu modulu IIS AspNetCore nebo modulu IIS Express AspNetCore ve sloupci Zdroj .

Spuštění aplikace na příkazovém řádku

Mnoho chyb při spuštění negeneruje užitečné informace v protokolu událostí aplikace. Příčinu některých chyb můžete zjistit spuštěním aplikace na příkazovém řádku v hostitelském systému.

Nasazení závislé na rozhraní

Pokud je aplikace nasazení závislé na rozhraní:

  1. Na příkazovém řádku přejděte do složky nasazení a spusťte aplikaci spuštěním sestavení aplikace s dotnet.exe. V následujícím příkazu nahraďte název sestavení aplikace assembly_name<>: dotnet .\<assembly_name>.dll.
  2. Výstup konzoly z aplikace zobrazující případné chyby se zapíše do okna konzoly.
  3. Pokud dojde k chybám při vytváření požadavku na aplikaci, odešlete žádost hostiteli a portu, kde Kestrel naslouchá. Pomocí výchozího hostitele a příspěvku proveďte požadavek na http://localhost:5000/. Pokud aplikace normálně reaguje na adrese koncového Kestrel bodu, problém pravděpodobně souvisí s konfigurací hostování a méně pravděpodobné v rámci aplikace.

Samostatné nasazení

Pokud se jedná o samostatné nasazení:

  1. Na příkazovém řádku přejděte do složky nasazení a spusťte spustitelný soubor aplikace. V následujícím příkazu nahraďte název sestavení aplikace assembly_name<>: <assembly_name>.exe.
  2. Výstup konzoly z aplikace zobrazující případné chyby se zapíše do okna konzoly.
  3. Pokud dojde k chybám při vytváření požadavku na aplikaci, odešlete žádost hostiteli a portu, kde Kestrel naslouchá. Pomocí výchozího hostitele a příspěvku proveďte požadavek na http://localhost:5000/. Pokud aplikace normálně reaguje na adrese koncového Kestrel bodu, problém pravděpodobně souvisí s konfigurací hostování a méně pravděpodobné v rámci aplikace.

protokol stdout modulu ASP.NET Core (IIS)

Povolení a zobrazení protokolů stdout:

  1. Přejděte do složky nasazení webu v hostitelském systému.
  2. Pokud složka protokolů není k dispozici, vytvořte ji. Pokyny k automatickému vytvoření složky protokolů v nasazení pomocí nástroje MSBuild najdete v tématu Struktura adresářů .
  3. Upravte soubor web.config. Nastavte stdoutLogEnabled a změňte cestu stdoutLogFile tak, aby odkazovala na složku protokolů (například.\logs\stdout).true stdout v cestě je předpona názvu souboru protokolu. Při vytváření protokolu se automaticky přidá časové razítko, ID procesu a přípona souboru. Jako stdout předponu názvu souboru se typický soubor protokolu nazývá stdout_20180205184032_5412.log.
  4. Ujistěte se, že identita fondu aplikací má oprávnění k zápisu do složky protokolů .
  5. Uložte aktualizovaný soubor web.config .
  6. Vytvořte žádost o aplikaci.
  7. Přejděte do složky protokolů . Vyhledejte a otevřete nejnovější protokol stdout.
  8. Prostudujte protokol chyb.

Po dokončení řešení potíží zakažte protokolování stdout:

  1. Upravte soubor web.config.
  2. Nastavte stdoutLogEnabled na false.
  3. Soubor uložte.

Další informace najdete v tématu Modul ASP.NET Core (ANCM) pro službu IIS.

Upozorňující

Selhání zakázání protokolu stdout může vést k selhání aplikace nebo serveru. Velikost souboru protokolu ani počet vytvořených souborů protokolu není nijak omezený.

Pro rutinní protokolování v aplikaci ASP.NET Core použijte knihovnu protokolování, která omezuje velikost souboru protokolu a obměňuje protokoly. Další informace najdete v tématu Zprostředkovatelé protokolování třetích stran.

Povolení stránky výjimek pro vývojáře

Proměnnou ASPNETCORE_ENVIRONMENTprostředí je možné přidat do souboru web.config , aby se aplikace spustila ve vývojovém prostředí. Pokud se prostředí nepřepíše při spuštění aplikace v UseEnvironment tvůrci hostitelů, nastavení proměnné prostředí umožňuje , aby se při spuštění aplikace zobrazila stránka výjimky vývojáře.

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

Nastavení proměnné ASPNETCORE_ENVIRONMENT prostředí se doporučuje jenom pro pracovní a testovací servery, které nejsou vystavené internetu. Po řešení potíží odeberte proměnnou prostředí ze souboru web.config . Informace o nastavení proměnných prostředí ve web.config naleznete v tématu environmentVariables podřízený prvek aspNetCore.

Získání dat z aplikace

Pokud aplikace dokáže reagovat na požadavky, získat požadavek, připojení a další data z aplikace pomocí vloženého middlewaru terminálu. Další informace a vzorový kód najdete v tématu Řešení potíží a ladění ASP.NET základních projektů.

Pomalé nebo zablokování aplikace (IIS)

Výpis stavu systému je snímek paměti systému a může pomoct určit příčinu chybového ukončení aplikace, selhání spuštění nebo pomalé aplikace.

Aplikace se chybově ukončí nebo dojde k výjimce

Získání a analýza výpisu paměti z Zasílání zpráv o chybách systému Windows (WER):

  1. Vytvořte složku pro ukládání souborů s výpisem stavu systému na adrese c:\dumps. Fond aplikací musí mít ke složce přístup pro zápis.

  2. Spusťte skript PowerShellu EnableDumps:

    • Pokud aplikace používá model hostování v procesu, spusťte skript pro w3wp.exe:

      .\EnableDumps w3wp.exe c:\dumps
      
    • Pokud aplikace používá model hostování mimo proces, spusťte skript pro dotnet.exe:

      .\EnableDumps dotnet.exe c:\dumps
      
  3. Spusťte aplikaci za podmínek, které způsobují chybové ukončení.

  4. Po chybě spusťte skript DisableDumps PowerShellu:

    • Pokud aplikace používá model hostování v procesu, spusťte skript pro w3wp.exe:

      .\DisableDumps w3wp.exe
      
    • Pokud aplikace používá model hostování mimo proces, spusťte skript pro dotnet.exe:

      .\DisableDumps dotnet.exe
      

Po chybovém ukončení aplikace a dokončení shromažďování výpisů paměti se aplikace může normálně ukončit. Skript PowerShellu konfiguruje WER tak, aby shromáždil až pět výpisů paměti na aplikaci.

Upozorňující

Výpisy stavu systému můžou zabírat velké množství místa na disku (až několik gigabajtů).

Aplikace přestane reagovat, selže při spuštění nebo se normálně spustí

Když aplikace přestane reagovat (přestane reagovat, ale neuspěje), selže při spuštění nebo se spustí normálně, přečtěte si téma Soubory výpisu stavu stavu systému v uživatelském režimu: Volba nejvhodnějšího nástroje pro výběr vhodného nástroje pro vytvoření výpisu paměti.

Analýza výpisu paměti

Výpis paměti je možné analyzovat pomocí několika přístupů. Další informace naleznete v tématu Analýza souboru výpisu stavu systému v uživatelském režimu.

Vymazání mezipamětí balíčků

Funkční aplikace může selhat okamžitě po upgradu sady .NET Core SDK na vývojovém počítači nebo změně verzí balíčků v aplikaci. V některých případech můžou inkoherentní balíčky přerušit aplikaci při provádění hlavních upgradů. Většinu těchto problémů je možné vyřešit pomocí těchto pokynů:

  1. Odstraňte přihrádku a složky obj.

  2. Vymažte mezipaměti balíčků spuštěním dotnet nuget locals all --clear z příkazového prostředí.

    Vymazání mezipaměti balíčků lze také provést pomocí nástroje nuget.exe a spuštění příkazu nuget locals all -clear. nuget.exe není sbalené instalace s desktopovým operačním systémem Windows a musí být získána odděleně od webu NuGet.

  3. Obnovte a znovu sestavte projekt.

  4. Před opětovným nasazením aplikace odstraňte všechny soubory ve složce nasazení na serveru.

Další prostředky

Dokumentace Azure

Dokumentace sady Visual Studio

Dokumentace k editoru Visual Studio Code