Řešení ASP.NET Core potíží s Azure App Service a službou IIS

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 Azure App Service iis:

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

Řešení potíží na Azure App Service
Poskytuje rady pro řešení potíží pro aplikace nasazené Azure App Service.

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

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

Další materiály
Uvádí další témata týkající se řešení potíží.

Chyby při spuštění aplikace

V Visual Studio výchozím nastavení ASP.NET Core hostování projektu IIS Express ladění. Chyba 502.5 – Selhání procesu nebo chyba 500.30 – Selhání spuštění, ke kterému dochází při místním ladění, je možné diagnostikovat pomocí rad v tomto tématu.

403.14 Zakázáno

Aplikaci se nedaří spustit. Zaprotokoluje se následující chyba:

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

Příčinou této chyby je obvykle přerušené nasazení hostitelského 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.
• Procesu nasazení se nepodařilo přesunout všechny soubory a složky aplikace do složky nasazení v hostitelském systému.
• V web.config chybí soubor souboru nebo je web.config poškozený.

Proveďte tyto 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 pro publikování aplikace do hostitelského systému pomocí normální metody nasazení, jako je Visual Studio, PowerShell nebo ruční nasazení:
   • Ověřte, žeweb.config je v nasazení a že jeho obsah je správný.
   • Při hostování Azure App Service ověřte, že je aplikace nasazená do D:\home\site\wwwroot složky .
   • Pokud je aplikace hostovaná službou IIS, ověřte, že je aplikace nasazená do fyzické cesty IIS zobrazené ve Správci služby IIS v části Základní Nastavení.
3. Ověřte, že jsou všechny soubory a složky aplikace nasazené, porovnáním 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 struktura ASP.NET Core directory . Další informace o souboru web.config najdete v tématu Modul ASP.NET Core .

500 – Vnitřní chyba serveru

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

K této chybě dochází v kódu aplikace během spouš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 se aplikace skládala normálně. Z pohledu serveru je to správně. Aplikace se sstartuje, ale nemůže vygenerovat platnou odpověď. Spusťte aplikaci na příkazovém řádku na serveru nebo povolte protokol stdout modulu ASP.NET Core, abyste problém vyřešili.

Chyba načítání obslužné rutiny In-Process 500.0

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

Při načítání komponent modulu ASP.NET Core neznámá chyba. Proveďte jednu z následujících akcí:

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

500.30 – In-Process spuštění

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

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

Běžné stavy selhání:

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

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

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

Modul ASP.NET Core se pokusí spustit modul runtime .NET Core v procesu, ale nespustí se. Nejčastější příčinou tohoto selhání při spuštění je, že modul Microsoft.NETCore.App runtime nebo Microsoft.AspNetCore.App není nainstalovaný. Pokud je aplikace nasazená pro cílovou verzi ASP.NET Core 3.0 a tato verze na počítači neexistuje, dojde k této chybě. Následuje 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 uvádí všechny nainstalované verze .NET Core a verzi požadovanou aplikací. Pokud chcete tuto chybu vyřešit, buď:

• Nainstalujte na počítač příslušnou verzi .NET Core.
• Změňte aplikaci tak, aby cílil na verzi .NET Core, která je na počítači.
• Publikujte aplikaci jako samostatné nasazení.

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

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 vyřešit, buď:

• 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 na rozhraní nená Microsoft.AspNetCore.App odkazovat. Pouze aplikace, které Microsoft.AspNetCore.App cílí na rozhraní, může hostovat ASP.NET Core Module.

Pokud chcete tuto chybu vyřešit, ověřte, že aplikace cílí na Microsoft.AspNetCore.App rozhraní. Zkontrolujte a .runtimeconfig.json ověřte rozhraní, na které aplikace cílí.

Smíšené modely hostování ANCM 500.34 se nepodporují

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

Pokud chcete tuto chybu vyřešit, spusťte aplikace v samostatných fondech aplikací služby IIS.

500.35 ANCM multiple In-Process applications in same process

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

Pokud chcete tuto chybu vyřešit, spusťte aplikace v samostatných fondech aplikací služby IIS.

500.36 – Selhání načítání obslužné rutiny mimo proces ANCM

Obslužná rutina požadavku mimo proces,aspnetcorev2_outofprocess.dll, není vedle souboruaspnetcorev2.dll souboru. To značí poškozenou instalaci modulu ASP.NET Core Module.

Pokud chcete tuto chybu vyřešit, opravte instalaci sady .NET Core Hosting Bundle (pro IIS) nebo Visual Studio (například IIS Express).

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

AnCM se nepodařilo spustit v rámci poskytnuté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 rozsečíst proces spuštění více aplikací.

Knihovna DLL aplikace ANCM 500.38 se nenašla

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 správce ANCM načítal aplikaci .NET Core do stávajícího procesu služby IIS. Model nasazení s jedním souborem tento scénář nepodporuje. 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 false .
2. Přepněte na model hostování mimo proces nastavením vlastnosti AspNetCoreHostingModel MSBuild na OutOfProcess .

502.5 – Selhání procesu

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

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

Běžným chybým stavem je nesprávná konfigurace aplikace kvůli cílení na verzi ASP.NET Core rozhraní, které není k dispozici. Zkontrolujte, které verze ASP.NET Core sdílené architektury jsou nainstalované na cílovém počítači. Sdílená rozhraní je sada sestavení (.dllsouborů), které jsou nainstalovány v počítači a odkazovány metabalíček, jako je Microsoft.AspNetCore.App například . Odkaz na metabalíčky může zadat minimální požadovanou verzi. Další informace najdete v tématu Sdílená rozhraní.

Chybová stránka Chyba procesu 502.5 se vrátí, když chybná konfigurace hostování nebo aplikace způsobí selhání pracovního procesu:

Nepodařilo se spustit aplikaci (ErrorCode '0x800700c1')

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 bitové přenosnosti mezi publikovanou aplikací a procesem w3wp/iisexpress.

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

1. Ve Správci služby IIS vyberte fond aplikací.
2. Na panelu Akce Nastavení Upravit fond aplikací možnost Upřesnit.
3. Nastavte Povolit 32bitové aplikace:
   • Pokud nasazujete 32bitovou aplikaci (x86), nastavte hodnotu na True .
   • Pokud nasazujete 64bitovou aplikaci (x64), nastavte hodnotu na False .

Potvrďte, že mezi vlastností MSBuild v souboru projektu a publikovanou <Platform> bitostí aplikace není konflikt.

Resetování připojení

Pokud po odeslání hlaviček dojde k chybě, je příliš pozdě, aby server odeslal chybu 500 Internal Server, když dojde k chybě. K tomu často dochází v případě, že dojde k chybě během serializace komplexní objekty pro odpověď. Tento typ chyby se zobrazí jako chyba resetování připojení na klientovi. S odstraňováním těchto typů chyb vám může pomoct protokolování aplikace.

Výchozí limity spouštění

Pro ASP.NET Core Module je nakonfigurovaná výchozí hodnota startupTimeLimit 120 sekund. Pokud je aplikace ponechána na výchozí hodnotě, může trvat až dvě minuty, než modul zahlásí selhání procesu. Informace o konfiguraci modulu najdete v tématu Atributy elementu aspNetCore.

Řešení potíží na Azure App Service

Protokol událostí aplikace (Azure App Service)

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

1. V Azure Portal otevřete aplikaci v App Services.
2. Vyberte Diagnostikovat a řešit problémy.
3. Vyberte záhlaví 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 přímé prozkoumání souboru protokolu událostí aplikace pomocí Kudu:

1. V oblasti Vývojové nástroje otevřete Rozšířené 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 vedle eventlog.xml 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í nevytváří v protokolu událostí aplikace užitečné informace. Chybu můžete zjistit spuštěním aplikace v konzole pro vzdálené spuštění Kudu:

1. V oblasti Vývojové nástroje otevřete Rozšířené 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. Spuštění aplikace:

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

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Pokud je aplikace samostatná, nasazování:

     {ASSEMBLY NAME}.exe
     

Výstup konzoly z aplikace, v němž se zobrazují všechny chyby, je předán do konzoly Kudu.

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

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

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

Výstup konzoly z aplikace, v němž se zobrazují všechny chyby, je předán 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 je aplikace samostatná, nasazování:
  1. cd D:\home\site\wwwroot
  2. Spusťte aplikaci: {ASSEMBLY NAME}.exe

Výstup konzoly z aplikace, v němž se zobrazují všechny chyby, je předán do konzoly Kudu.

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

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

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

Výstup konzoly z aplikace, v němž se zobrazují všechny chyby, je předán do konzoly Kudu.

ASP.NET Core Protokol stdout modulu (Azure App Service)

Protokol stdout modulu ASP.NET Core č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 na webovou aplikaci.
2. V okně App Service do vyhledávacího pole zadejte Kudu .
3. Vyberte Rozšířené nástroje > Přejít.
4. Vyberte ladit konzolu > cmd.
5. Přejít na Web/wwwroot
6. Vyberte ikonu tužky a upravte soubor web.config .
7. V <aspNetCore /> elementu nastavte stdoutLogEnabled="true" a vyberte Uložit.

Zakažte protokolování stdout, když se dokončí odstraňování potíží nastavením stdoutLogEnabled="false" .

Další informace naleznete v tématu Modul ASP.NET Core.

ASP.NET Core Protokol ladění modulu (Azure App Service)

protokol ladění ASP.NET Core modulu poskytuje další, hlubší protokolování z modulu ASP.NET Core. Postup povolení a zobrazení protokolů stdout:

1. Pro povolení rozšířeného diagnostického protokolu proveďte jednu z následujících akcí:
   • Postupujte podle pokynů v rozšířených diagnostických protokolech a nakonfigurujte aplikaci pro rozšířené diagnostické protokolování. Znovu nasaďte aplikaci.
   • Přidejte <handlerSettings> zobrazené v rozšířených diagnostických protokolech do souboru web.config živé aplikace pomocí konzoly 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 v novém okně nebo záložce 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 cestě lokality > wwwroot. Upravte soubor web.config tak, že vyberete tlačítko tužky. Přidejte <handlerSettings> 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 v novém okně nebo záložce 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 cestě lokality > wwwroot. Pokud jste nezadali cestu k souboru aspnetcore-Debug. log , soubor se zobrazí v seznamu. Pokud jste zadali cestu, přejděte do umístění souboru protokolu.
5. Otevřete soubor protokolu s tlačítkem tužky vedle názvu souboru.

Zakázat protokolování ladění, pokud je dokončeno odstraňování potíží:

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

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

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

Pomalá nebo zavěšená aplikace (Azure App Service)

V případě, že aplikace reaguje pomalu nebo přestane reagovat na žádost, přečtěte si téma řešení potíží s výkonem pomalých webových aplikací v Azure App Service.

Okna monitorování

Okna monitorování poskytují alternativní možnosti řešení potíží pro metody popsané dříve v tématu. Pomocí těchto oken můžete diagnostikovat chyby 500-Series.

potvrďte, že jsou nainstalovaná rozšíření ASP.NET Core. Pokud nejsou rozšíření nainstalována, nainstalujte je ručně:

1. V části okno vývojové nástroje vyberte okno rozšíření .
2. v seznamu by se měla zobrazit rozšíření ASP.NET Core .
3. Pokud nejsou rozšíření nainstalovaná, vyberte tlačítko Přidat .
4. ze seznamu vyberte rozšíření ASP.NET Core .
5. Kliknutím na 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, že se rozšíření úspěšně nainstalovala.

Pokud není povoleno protokolování stdout, postupujte následovně:

1. V Azure Portal v oblasti vývojové nástroje vyberte okno Pokročilé nástroje . Vyberte tlačítko Přejít → . Konzola Kudu se otevře v novém okně nebo záložce 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 pro cestu > wwwroot a posuňte se dolů, aby se soubor web.config v dolní části seznamu.
4. Klikněte na ikonu tužky vedle web.config souboru.
5. Nastavte stdoutLogEnabled na true a změňte cestu stdoutLogFile na: \\?\%home%\LogFiles\stdout .
6. Výběrem Uložit Uložte aktualizovaný soubor web.config .

Pokračovat k aktivaci protokolování diagnostiky:

1. V Azure Portal vyberte okno diagnostické protokoly .
2. Vyberte přepínač zapnuto pro protokolování aplikace (systém souborů) a podrobné chybové zprávy. V horní části okna vyberte tlačítko Uložit .
3. Chcete-li zahrnout trasování chybných požadavků, označované také jako protokolování událostí neúspěšných požadavků na FREB, vyberte přepínač zapnuto pro trasování chybných požadavků.
4. Vyberte okno log Stream , které je uvedeno hned pod oknem diagnostické protokoly na portálu.
5. Vytvořte žádost do aplikace.
6. V datech streamu protokolu se označuje příčina chyby.

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

Zobrazení protokolů pro trasování chybných požadavků (protokoly FREB):

1. Přejděte do okna diagnostikovat a řešit problémy v Azure Portal.
2. V oblasti nástroje podpory v postranním panelu vyberte protokoly pro trasování chybných požadavků .

V části Povolení protokolování diagnostiky pro webové aplikace v Azure App Service tématu a Nejčastější dotazy týkající se výkonu aplikace pro Web Apps v Azure: návody zapnout trasování chybných požadavků? Další informace.

Další informace najdete v tématu Povolení protokolování diagnostiky pro webové aplikace v Azure App Service.

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 Windows .
3. Výběrem aplikace otevřete protokol událostí aplikace.
4. Vyhledá chyby spojené s chybnou aplikací. chyby mají ve zdrojovém sloupci hodnotu modulu IIS AspNetCore nebo modul IIS Express AspNetCore .

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

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

Nasazení závislé na rozhraní

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

1. Na příkazovém řádku přejděte do složky pro nasazení a spusťte aplikaci spuštěním sestavení aplikace pomocí dotnet.exe. V následujícím příkazu nahraďte název sestavení aplikace pro <assembly_name> : dotnet .\<assembly_name>.dll .
2. Výstup konzoly z aplikace, který zobrazuje všechny chyby, je zapsán do okna konzoly.
3. Pokud dojde k chybám při podání žádosti do aplikace, vytvořte žádost na hostitele a port, kde Kestrel naslouchá. Pomocí výchozího hostitele a příkazu post vytvořte požadavek na http://localhost:5000/ . Pokud aplikace normálně reaguje na adresu koncového bodu, problém pravděpodobně souvisí s konfigurací hostování a s menší pravděpodobností Kestrel v rámci aplikace.

Samostatné nasazení

Pokud je aplikace samostatná, nasazování:

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ázvem sestavení aplikace <assembly_name> : <assembly_name>.exe .
2. Výstup konzoly z aplikace se zobrazenými chybami se zapisují do okna konzoly.
3. Pokud při vytváření požadavku na aplikaci dojde k chybám, požádejte hostitele a port, kde Kestrel naslouchá. Pomocí výchozího hostitele a příkazu post vytvořte požadavek na http://localhost:5000/ . Pokud aplikace normálně reaguje na adresu koncového bodu, problém pravděpodobně souvisí s konfigurací hostování a s menší pravděpodobností Kestrel v rámci aplikace.

ASP.NET Core Protokol stdout modulu (IIS)

Povolení a zobrazení protokolů stdout:

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

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

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

Další informace naleznete v tématu Modul ASP.NET Core.

ASP.NET Core Protokol ladění modulu (IIS)

Přidejte následující nastavení obslužné rutiny do souboru web.config, abyste umožnili ASP.NET Core modulu:

<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 naleznete v tématu vytvoření a přesměrování protokolu pomocí modulu ASP.NET Core.

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

Proměnnou ASPNETCORE_ENVIRONMENT prostředí je možné přidat do web.config pro spuštění aplikace ve vývojovém prostředí. Pokud se prostředí ve tvůrci hostitelů při spuštění aplikace v tvůrci hostitelů přepíše, umožní nastavení proměnné prostředí zobrazení stránky výjimky vývojáře při UseEnvironment spuštění aplikace.

<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é prostředí pro se doporučuje jenom pro použití na pracovních a testovacích serverech, které ASPNETCORE_ENVIRONMENT nejsou vystavené na internetu. Po řešení potíží odeberte proměnnou prostředíweb.config souboru. Informace o nastavení proměnných prostředí vweb.config najdete v tématu environmentVariables podřízeného prvku aspNetCore.

Získání dat z aplikace

Pokud je aplikace schopná reagovat na požadavky, získat žádost, připojení a další data z aplikace pomocí v řádku middlewaru terminálu. Další informace a vzorový kód najdete v tématu řešení potíží a ladění ASP.NET Corech projektů .

Pomalá nebo zamykaná aplikace (IIS)

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

Aplikace dojde k chybě nebo dojde k výjimce

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

1. Vytvořte složku pro umístě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 powershellový skript 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ůsobí selhání.

4. Po chybě spusťte powershellový skript DisableDumps:

   • 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 chybě aplikace a dokončení shromažďování výpisů paměti se aplikace může normálně ukončit. Skript PowerShellu nakonfiguruje WER tak, aby na jednu aplikaci shromažďoval až pět výpisů paměti.

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

Když aplikace přestane reagovat (přestane reagovat, ale nehavaruje), při spuštění selže nebo se spustí normálně, podívejte se na článek Soubory s výpisem stavu systému v uživatelském režimu: Výběr nejlepšího nástroje pro výběr vhodného nástroje pro vytvoření výpisu stavu systému.

Analýza výpisu paměti

Výpis paměti lze analyzovat pomocí několika přístupů. Další informace najdete v tématu Analýza User-Mode výpisu stavu systému.

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

Funkční aplikace může selhat okamžitě po upgradu .NET Core SDK na vývojovém počítači nebo změně verzí balíčků v rámci aplikace. V některých případech může při provádění významných upgradů dojít k přerušení aplikace v neschválených balíčcích. Většinu těchto problémů můžete vyřešit pomocí těchto pokynů:

1. Odstraňte složky bin a obj.

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

   Vymazání mezipamětí balíčků lze provést také pomocí nástrojenuget.exe a spuštění příkazu nuget locals all -clear . nuget.exe není součástí instalace s desktopovou Windows a je nutné ji získat odděleně od NuGet webu.

3. Obnovte a znovu sestavte projekt.

4. Před znovunasazování aplikace odstraňte všechny soubory ve složce nasazení na serveru.

Další zdroje informací

• řešení potíží a ladění ASP.NET Corech projektů
• Referenční informace k běžným chybám Azure App Service a IIS s ASP.NET Core
• Zpracování chyb v ASP.NET Core
• Modul ASP.NET Core

Dokumentace k Azure

• Application Insights pro ASP.NET Core
• Část Vzdálené ladění webových aplikací tématu Řešení potíží s webovou aplikací Azure App Service pomocí Visual Studio
• Azure App Service diagnostiky
• Postup: Monitorování aplikací ve službě Azure App Service
• Řešení potíží s webovou aplikací Azure App Service pomocí Visual Studio
• Řešení chyb HTTP chyb 502 – Chybná brána a Nedostupná služba 503 ve webových aplikacích Azure
• Řešení potíží s výkonem pomalých webových aplikací ve službě Azure App Service
• Nejčastější dotazy k výkonu aplikací Web Apps v Azure
• Sandbox webové aplikace Azure (App Service spuštění modulu runtime)

Dokumentace sady Visual Studio

• Vzdálené ladění ASP.NET Core službě IIS v Azure v Visual Studio 2017
• Vzdálené ladění ASP.NET Core vzdáleném počítači se službou IIS v Visual Studio 2017
• Informace o ladění pomocí sady Visual Studio

Visual Studio Code dokumentace

• Ladění s 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 Azure App Service iis:

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

Řešení potíží na Azure App Service
Poskytuje rady pro řešení potíží pro aplikace nasazené Azure App Service.

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

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

Další materiály
Uvádí další témata týkající se řešení potíží.

Chyby při spuštění aplikace

V Visual Studio výchozím nastavení ASP.NET Core hostování projektu IIS Express ladění. Chyba 502.5 – Selhání procesu nebo chyba 500.30 – Selhání spuštění, ke kterému dochází při místním ladění, je možné diagnostikovat pomocí rad v tomto tématu.

403.14 Zakázáno

Aplikaci se nedaří spustit. Zaprotokoluje se následující chyba:

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

Příčinou této chyby je obvykle přerušené nasazení hostitelského 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.
• Procesu nasazení se nepodařilo přesunout všechny soubory a složky aplikace do složky nasazení v hostitelském systému.
• Soubor web.config v nasazení chybí nebo je web.config poškozený obsah souboru.

Proveďte tyto 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 pro publikování aplikace do hostitelského systému pomocí normální metody nasazení, jako je Visual Studio, PowerShell nebo ruční nasazení:
   • Ověřte, žeweb.config je v nasazení a že jeho obsah je správný.
   • Při hostování Azure App Service ověřte, že je aplikace nasazená do D:\home\site\wwwroot složky .
   • Pokud je aplikace hostovaná službou IIS, ověřte, že je aplikace nasazená do fyzické cesty IIS zobrazené ve Správci služby IIS v části Základní Nastavení.
3. Ověřte, že jsou všechny soubory a složky aplikace nasazené, porovnáním nasazení v hostitelském systému s obsahem složky publish projektu.

Další informace o rozložení publikované aplikace ASP.NET Core najdete v tématu struktura ASP.NET Core directory . Další informace o souboru web.config najdete v tématu Modul ASP.NET Core .

500 – Vnitřní chyba serveru

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

K této chybě dochází v kódu aplikace během spouš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 se aplikace skládala normálně. Z pohledu serveru je to správně. Aplikace se sstartuje, ale nemůže vygenerovat platnou odpověď. Spusťte aplikaci na příkazovém řádku na serveru nebo povolte protokol stdout modulu ASP.NET Core, abyste problém vyřešili.

Chyba načítání obslužné rutiny In-Process 500.0

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

Modulu ASP.NET Core se nepodařilo najít modul CLR .NET Core a najít obslužnou rutinu požadavku v procesu (aspnetcorev2_inprocess.dll). Zkontrolujte, že:

• Aplikace cílí na balíček Microsoft.AspNetCore.Server.IIS NuGet nebo na Microsoft.AspNetCore.App metapackage.
• Verze sdílené architektury ASP.NET Core, na kterou cílí aplikace, je nainstalovaná na cílovém počítači.

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

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

Modulu ASP.NET Core se nepodařilo najít obslužnou rutinu požadavku hostování mimo proces. Ujistěte se,aspnetcorev2_outofprocess.dll je v podsložce vedle aspnetcorev2.dll.

502.5 – Selhání procesu

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

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

Běžnou chybovou podmínkou je, že aplikace je chybně nakonfigurovaná kvůli cílení na verzi ASP.NET Core sdílené architektury, která není k dispozici. Zkontrolujte, které verze ASP.NET Core sdílené architektury jsou nainstalované na cílovém počítači. Sdílená rozhraní je sada sestavení (.dllsouborů), které jsou nainstalovány v počítači a odkazovány metabalíček, jako je Microsoft.AspNetCore.App například . Odkaz na metabalíčky může zadat minimální požadovanou verzi. Další informace najdete v tématu Sdílená rozhraní.

Chybová stránka Chyba procesu 502.5 se vrátí, když chybná konfigurace hostování nebo aplikace způsobí selhání pracovního procesu:

Nepodařilo se spustit aplikaci (ErrorCode '0x800700c1')

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 bitové přenosnosti mezi publikovanou aplikací a procesem w3wp/iisexpress.

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

1. Ve Správci služby IIS vyberte fond aplikací.
2. Na panelu Akce Nastavení Upravit fond aplikací možnost Upřesnit.
3. Nastavte Povolit 32bitové aplikace:
   • Pokud nasazujete 32bitovou aplikaci (x86), nastavte hodnotu na True .
   • Pokud nasazujete 64bitovou aplikaci (x64), nastavte hodnotu na False .

Potvrďte, že mezi vlastností MSBuild v souboru projektu a publikovanou <Platform> bitostí aplikace není konflikt.

Resetování připojení

Pokud po odeslání hlaviček dojde k chybě, je příliš pozdě, aby server odeslal chybu 500 Internal Server, když dojde k chybě. K tomu často dochází v případě, že dojde k chybě během serializace komplexní objekty pro odpověď. Tento typ chyby se zobrazí jako chyba resetování připojení na klientovi. S odstraňováním těchto typů chyb vám může pomoct protokolování aplikace.

Výchozí limity spouštění

Pro ASP.NET Core Module je nakonfigurovaná výchozí hodnota startupTimeLimit 120 sekund. Pokud je aplikace ponechána na výchozí hodnotě, může trvat až dvě minuty, než modul zahlásí selhání procesu. Informace o konfiguraci modulu najdete v tématu Atributy elementu aspNetCore.

Řešení potíží na Azure App Service

Protokol událostí aplikace (Azure App Service)

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

1. V Azure Portal otevřete aplikaci v App Services.
2. Vyberte Diagnostikovat a řešit problémy.
3. Vyberte záhlaví 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 přímé prozkoumání souboru protokolu událostí aplikace pomocí Kudu:

1. V oblasti Vývojové nástroje otevřete Rozšířené 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 vedle eventlog.xml 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í nevytváří v protokolu událostí aplikace užitečné informace. Chybu můžete zjistit spuštěním aplikace v konzole pro vzdálené spuštění Kudu:

1. V oblasti Vývojové nástroje otevřete Rozšířené 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. Spuštění aplikace:

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

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Pokud je aplikace samostatná, nasazování:

     {ASSEMBLY NAME}.exe
     

Výstup konzoly z aplikace, v němž se zobrazují všechny chyby, je předán do konzoly Kudu.

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

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

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

Výstup konzoly z aplikace, v němž se zobrazují všechny chyby, je předán 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 je aplikace samostatná, nasazování:
  1. cd D:\home\site\wwwroot
  2. Spusťte aplikaci: {ASSEMBLY NAME}.exe

Výstup konzoly z aplikace, v němž se zobrazují všechny chyby, je předán do konzoly Kudu.

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

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

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

Výstup konzoly z aplikace, v němž se zobrazují všechny chyby, je předán do konzoly Kudu.

ASP.NET Core Protokol stdout modulu (Azure App Service)

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

1. Přejděte do okna Diagnostika a řešení problémů v Azure Portal.
2. V části SELECT PROBLEM CATEGORY (VYBRAT KATEGORII PROBLÉMU) vyberte tlačítko Web App Down (Webová aplikace je dole).
3. V části Suggested Solutions Enable Stdout Log Redirection (Povolit přesměrování protokolu stdout) vyberte tlačítko Open Kudu Console (Otevřít > konzolu Kudu) a upravte Web.Config.
4. V konzole pro diagnostiku Kudu otevřete složky s cestou na webu > wwwroot. Posuňte se dolů aweb.config soubor v dolní části seznamu.
5. Klikněte na ikonu tužky vedle web.config souboru.
6. Nastavte stdoutLogEnabled na true a změňte cestu stdoutLogFile na: \\?\%home%\LogFiles\stdout .
7. Vyberte Uložit a uložte aktualizovaný web.config souboru.
8. Vytvořte požadavek na 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í změny.
13. Po otevření souboru protokolu se zobrazí chyba.

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

1. V konzole pro diagnostiku Kudu se vraťte na web cesty > wwwroot, abyste odhalili web.config souboru. Výběrem ikony tužky web.configznovu otevřete soubor s ikonou tužky.
2. Nastavte stdoutLogEnabled na false .
3. Vyberte Uložit a soubor uložte.

Další informace naleznete v tématu Modul ASP.NET Core.

ASP.NET Core Protokol ladění modulu (Azure App Service)

Protokol ladění modulu ASP.NET Core poskytuje další hlubší protokolování z modulu ASP.NET Core Module. Povolení a zobrazení protokolů stdout:

1. Pokud chcete povolit rozšířený diagnostický protokol, proveďte jednu z následujících akcí:
   • Postupujte podle pokynů v tématu Rozšířené diagnostické protokoly a nakonfigurujte aplikaci pro rozšířené protokolování diagnostiky. Znovu nasaďte aplikaci.
   • Přidejte z rozšířených diagnostických protokolů do souboruweb.configživé aplikace <handlerSettings> pomocí konzoly Kudu:
     1. V oblasti Vývojové nástroje otevřete Rozšířené 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 s cestou > wwwroot. Upravte soubor web.config výběrem tlačítka tužky. Přidejte <handlerSettings> část , jak je znázorněno v rozšířených diagnostických protokolech. Vyberte tlačítko Uložit.
2. V oblasti Vývojové nástroje otevřete Rozšířené 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 s cestou > wwwroot. Pokud jste nezadáte cestu k souboru aspnetcore-debug.log, soubor se zobrazí v seznamu. Pokud jste dodali 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í:

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

• Odeberte <handlerSettings> soubor z 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 naleznete v tématu vytvoření a přesměrování protokolu pomocí modulu ASP.NET Core.

Pomalá nebo zamykaná aplikace (Azure App Service)

Když aplikace reaguje pomalu nebo přestane na žádost reagovat, projděte si následující články:

• Řešení potíží s výkonem pomalých webových aplikací ve službě Azure App Service
• Použití rozšíření webu Pro diagnostiku selhání k zachycení výpisu stavu systému pro občasné problémy s výjimkami nebo problémy s výkonem webové aplikace Azure

Okna monitorování

Okna monitorování poskytují alternativní prostředí pro řešení potíží s metodami popsanými výše v tomto tématu. Tato okna je možné použít k diagnostice chyb řady 500.

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

1. V části okna VÝVOJOVÉ NÁSTROJE vyberte okno Rozšíření.
2. V ASP.NET Core by se měla zobrazit pole Rozšíření.
3. Pokud nejsou rozšíření nainstalovaná, vyberte tlačítko Přidat .
4. ze seznamu vyberte rozšíření ASP.NET Core .
5. Kliknutím na 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, že se rozšíření úspěšně nainstalovala.

Pokud není povoleno protokolování stdout, postupujte následovně:

1. V Azure Portal v oblasti vývojové nástroje vyberte okno Pokročilé nástroje . Vyberte tlačítko Přejít → . Konzola Kudu se otevře v novém okně nebo záložce 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 pro cestu > wwwroot a posuňte se dolů, aby se soubor web.config v dolní části seznamu.
4. Klikněte na ikonu tužky vedle web.config souboru.
5. Nastavte stdoutLogEnabled na true a změňte cestu stdoutLogFile na: \\?\%home%\LogFiles\stdout .
6. Výběrem Uložit Uložte aktualizovaný soubor web.config .

Pokračovat k aktivaci protokolování diagnostiky:

1. V Azure Portal vyberte okno diagnostické protokoly .
2. Vyberte přepínač zapnuto pro protokolování aplikace (systém souborů) a podrobné chybové zprávy. V horní části okna vyberte tlačítko Uložit .
3. Chcete-li zahrnout trasování chybných požadavků, označované také jako protokolování událostí neúspěšných požadavků na FREB, vyberte přepínač zapnuto pro trasování chybných požadavků.
4. Vyberte okno log Stream , které je uvedeno hned pod oknem diagnostické protokoly na portálu.
5. Vytvořte žádost do aplikace.
6. V datech streamu protokolu se označuje příčina chyby.

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

Zobrazení protokolů pro trasování chybných požadavků (protokoly FREB):

1. Přejděte do okna diagnostikovat a řešit problémy v Azure Portal.
2. V oblasti nástroje podpory v postranním panelu vyberte protokoly pro trasování chybných požadavků .

V části Povolení protokolování diagnostiky pro webové aplikace v Azure App Service tématu a Nejčastější dotazy týkající se výkonu aplikace pro Web Apps v Azure: návody zapnout trasování chybných požadavků? Další informace.

Další informace najdete v tématu Povolení protokolování diagnostiky pro webové aplikace v Azure App Service.

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 Windows .
3. Výběrem aplikace otevřete protokol událostí aplikace.
4. Vyhledá chyby spojené s chybnou aplikací. chyby mají ve zdrojovém sloupci hodnotu modulu IIS AspNetCore nebo modul IIS Express AspNetCore .

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

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

Nasazení závislé na rozhraní

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

1. Na příkazovém řádku přejděte do složky pro nasazení a spusťte aplikaci spuštěním sestavení aplikace pomocí dotnet.exe. V následujícím příkazu nahraďte název sestavení aplikace pro <assembly_name> : dotnet .\<assembly_name>.dll .
2. Výstup konzoly z aplikace, který zobrazuje všechny chyby, je zapsán do okna konzoly.
3. Pokud dojde k chybám při podání žádosti do aplikace, vytvořte žádost na hostitele a port, kde Kestrel naslouchá. Pomocí výchozího hostitele a příspěvku vytvořte žádost http://localhost:5000/ . Pokud aplikace normálně reaguje na Kestrel adrese koncového bodu, problém je pravděpodobnější v souvislosti s konfigurací hostování a méně pravděpodobným v rámci aplikace.

Samostatně zahrnuté nasazení

Pokud je aplikace samostatná, nasazení:

1. Na příkazovém řádku přejděte do složky pro nasazení a spusťte spustitelný soubor aplikace. V následujícím příkazu nahraďte název sestavení aplikace pro <assembly_name> : <assembly_name>.exe .
2. Výstup konzoly z aplikace, který zobrazuje všechny chyby, je zapsán do okna konzoly.
3. Pokud dojde k chybám při podání žádosti do aplikace, vytvořte žádost na hostitele a port, kde Kestrel naslouchá. Pomocí výchozího hostitele a příspěvku vytvořte žádost http://localhost:5000/ . Pokud aplikace normálně reaguje na Kestrel adrese koncového bodu, problém je pravděpodobnější v souvislosti s konfigurací hostování a méně pravděpodobným v rámci aplikace.

ASP.NET Core Modul protokolu stdout (IIS)

Postup povolení a zobrazení protokolů stdout:

1. Přejděte do složky pro nasazení webu v hostitelském systému.
2. Pokud složka logs není k dispozici, vytvořte složku. pokyny, jak povolit MSBuild vytvoření složky protokolů v nasazení automaticky, najdete v tématu struktura adresáře .
3. Upravte soubor web.config . Nastavte stdoutLogEnabled na true a změňte cestu stdoutLogFile tak, aby odkazovala na složku logs (například .\logs\stdout ). stdout v cestě je předpona názvu souboru protokolu. Časové razítko, ID procesu a Přípona souboru se automaticky přidají při vytvoření protokolu. stdoutJako předpona názvu souboru se používá typický soubor protokolu s názvem stdout_20180205184032_5412. log.
4. Zajistěte, aby identita fondu aplikací měla oprávnění k zápisu do složky logs .
5. Uložte aktualizovaný soubor web.config .
6. Vytvořte žádost do aplikace.
7. Přejděte do složky logs . Vyhledejte a otevřete nejnovější protokol STDOUT.
8. Prostudujte si protokol o chybách.

Zakázat protokolování stdout při odstraňování potíží:

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

Další informace naleznete v tématu Modul ASP.NET Core.

ASP.NET Core Protokol ladění modulu (IIS)

do souboru web.config aplikace přidejte následující nastavení obslužných rutin, aby se povolil protokol ladění ASP.NET Core modulu:

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

Potvrďte, že zadaná cesta k protokolu existuje a že má identita fondu aplikací oprávnění k zápisu do tohoto umístění.

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

Povolit stránku výjimky pro vývojáře

ASPNETCORE_ENVIRONMENT Proměnnou prostředí lze přidat do web.config ke spuštění aplikace ve vývojovém prostředí. Pokud se prostředí nepřepisuje při spuštění aplikace v UseEnvironment tvůrci hostitele, nastavení proměnné prostředí umožní, aby se při spuštění aplikace zobrazila Stránka s výjimkou vývojářů .

<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é prostředí pro ASPNETCORE_ENVIRONMENT se doporučuje jenom pro použití na pracovních a testovacích serverech, které nejsou přístupné pro Internet. Po vyřešení potíží odeberte proměnnou prostředí ze souboru web.config . Informace o nastavení proměnných prostředí v web.config naleznete v tématu environmentVariables Child element of aspNetCore.

Získání dat z aplikace

Pokud aplikace dokáže reagovat na žádosti, získat požadavek, připojení a další data z aplikace pomocí vloženého middlewaru terminálu. Další informace a ukázka kódu naleznete v tématu řešení potíží a ladění ASP.NET Corech projektů .

Pomalá nebo zavěšená aplikace (IIS)

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

Aplikace selže nebo dojde k výjimce.

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

1. Vytvořte složku pro umístě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 powershellový skript 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ůsobí selhání.

4. Po chybě spusťte powershellový skript DisableDumps:

   • 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 chybě aplikace a dokončení shromažďování výpisů paměti se aplikace může normálně ukončit. Skript PowerShellu nakonfiguruje WER tak, aby na jednu aplikaci shromažďoval až pět výpisů paměti.

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

Když aplikace přestane reagovat (přestane reagovat, ale nehavaruje), při spuštění selže nebo se spustí normálně, podívejte se na článek Soubory s výpisem stavu systému v uživatelském režimu: Výběr nejlepšího nástroje pro výběr vhodného nástroje pro vytvoření výpisu stavu systému.

Analýza výpisu paměti

Výpis paměti lze analyzovat pomocí několika přístupů. Další informace najdete v tématu Analýza User-Mode výpisu stavu systému.

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

Funkční aplikace může selhat okamžitě po upgradu .NET Core SDK na vývojovém počítači nebo změně verzí balíčků v rámci aplikace. V některých případech může při provádění významných upgradů dojít k přerušení aplikace v neschválených balíčcích. Většinu těchto problémů můžete vyřešit pomocí těchto pokynů:

1. Odstraňte složky bin a obj.

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

   Vymazání mezipamětí balíčků lze provést také pomocí nástrojenuget.exe a spuštěním příkazu nuget locals all -clear . nuget.exe není součástí instalace s desktopovou Windows a je nutné ji získat odděleně od NuGet webu.

3. Obnovte a znovu sestavte projekt.

4. Před znovunasazování aplikace odstraňte všechny soubory ve složce nasazení na serveru.

Další zdroje informací

• řešení potíží a ladění ASP.NET Corech projektů
• Referenční informace k běžným chybám Azure App Service a IIS s ASP.NET Core
• Zpracování chyb v ASP.NET Core
• Modul ASP.NET Core

Dokumentace k Azure

• Application Insights pro ASP.NET Core
• Část Vzdálené ladění webových aplikací tématu Řešení potíží s webovou aplikací Azure App Service pomocí Visual Studio
• Azure App Service diagnostiky
• Postup: Monitorování aplikací ve službě Azure App Service
• Řešení potíží s webovou aplikací Azure App Service pomocí Visual Studio
• Řešení chyb HTTP chyb 502 – Chybná brána a Nedostupná služba 503 ve webových aplikacích Azure
• Řešení potíží s výkonem pomalých webových aplikací ve službě Azure App Service
• Nejčastější dotazy k výkonu aplikací Web Apps v Azure
• Sandbox webové aplikace Azure (App Service spuštění modulu runtime)

Dokumentace sady Visual Studio

• Vzdálené ladění ASP.NET Core iis v Azure v Visual Studio 2017
• Vzdálené ladění ASP.NET Core vzdáleném počítači se službou IIS v Visual Studio 2017
• Informace o ladění pomocí sady Visual Studio

Visual Studio Code dokumentace

• Ladění s 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 Azure App Service iis:

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

Řešení potíží na Azure App Service
Poskytuje rady pro řešení potíží pro aplikace nasazené Azure App Service.

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

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

Další materiály
Uvádí další témata týkající se řešení potíží.

Chyby při spuštění aplikace

V Visual Studio výchozím nastavení ASP.NET Core hostování projektu IIS Express ladění. Selhání procesu 502.5, ke kterému dochází při místním ladění, je možné diagnostikovat pomocí rad v tomto tématu.

403.14 Zakázáno

Aplikaci se nedaří spustit. Zaprotokoluje se následující chyba:

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

Příčinou této chyby je obvykle přerušené nasazení hostitelského 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.
• Procesu nasazení se nepodařilo přesunout všechny soubory a složky aplikace do složky nasazení v hostitelském systému.
• V web.config chybí soubor souboru nebo je web.config poškozený.

Proveďte tyto 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 pro publikování aplikace do hostitelského systému pomocí normální metody nasazení, jako je Visual Studio, PowerShell nebo ruční nasazení:
   • Ověřte, žeweb.config je v nasazení a že jeho obsah je správný.
   • Při hostování Azure App Service ověřte, že je aplikace nasazená do D:\home\site\wwwroot složky .
   • Pokud je aplikace hostovaná službou IIS, ověřte, že je aplikace nasazená do fyzické cesty IIS zobrazené ve Správci služby IIS v části Základní Nastavení.
3. Ověřte, že jsou všechny soubory a složky aplikace nasazené, porovnáním nasazení v hostitelském systému s obsahem složky publish projektu.

Další informace o rozložení publikované aplikace ASP.NET Core najdete v tématu struktura ASP.NET Core directory . Další informace o souboru web.config najdete v tématu Modul ASP.NET Core .

500 – Vnitřní chyba serveru

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

K této chybě dochází v kódu aplikace během spouš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 se aplikace skládala normálně. Z pohledu serveru je to správně. Aplikace se sstartuje, ale nemůže vygenerovat platnou odpověď. Spusťte aplikaci na příkazovém řádku na serveru nebo povolte protokol stdout modulu ASP.NET Core, abyste problém vyřešili.

502.5 – Selhání procesu

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

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

Běžným chybým stavem je nesprávná konfigurace aplikace kvůli cílení na verzi ASP.NET Core rozhraní, které není k dispozici. Zkontrolujte, které verze ASP.NET Core sdílené architektury jsou nainstalované na cílovém počítači. Sdílená rozhraní je sada sestavení (.dllsouborů), které jsou nainstalovány v počítači a odkazovány metabalíček, jako je Microsoft.AspNetCore.App například . Odkaz na metabalíčky může zadat minimální požadovanou verzi. Další informace najdete v tématu Sdílená rozhraní.

Chybová stránka Chyba procesu 502.5 se vrátí, když chybná konfigurace hostování nebo aplikace způsobí selhání pracovního procesu:

Nepodařilo se spustit aplikaci (ErrorCode '0x800700c1')

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 bitové přenosnosti mezi publikovanou aplikací a procesem w3wp/iisexpress.

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

1. Ve Správci služby IIS vyberte fond aplikací.
2. v části upravit fond aplikací na panelu akce vyberte upřesnit Nastavení .
3. Nastavte možnost povolit 32 – bitové aplikace:
   • Pokud nasazujete 32 (x86) aplikaci, nastavte hodnotu na True .
   • Pokud nasazujete 64 aplikaci (x64), nastavte hodnotu na False .

ověřte, že mezi <Platform> vlastností MSBuild v souboru projektu a publikovaným bitová verzeem aplikace nedochází ke konfliktu.

Resetování připojení

Pokud dojde k chybě po odeslání hlaviček, je příliš pozdě pro server, který odešle 500 interní chybu serveru , když dojde k chybě. K tomu často dochází, když dojde k chybě během serializace složitých objektů pro odpověď. Tento typ chyby se zobrazí jako chyba resetování připojení na klientovi. Protokolování aplikace může pomoct řešit tyto typy chyb.

Výchozí omezení spouštění

ASP.NET Core modul je nakonfigurovaný s výchozí startupTimeLimitou 120 sekund. Pokud necháte výchozí hodnotu, aplikace může trvat až dvě minuty, než se modul zaznamená selhání procesu. Informace o konfiguraci modulu naleznete v tématu atributy elementu aspNetCore.

Řešení potíží na Azure App Service

Protokol událostí aplikace (Azure App Service)

Chcete-li získat přístup k protokolu událostí aplikace, použijte okno Diagnostika a řešení problémů v Azure Portal:

1. V Azure Portal otevřete aplikaci v App Services.
2. Vyberte Diagnostikovat a řešit problémy.
3. Vyberte diagnostické nástroje záhlaví.
4. V nabídce nástroje podpory vyberte tlačítko události aplikace .
5. Projděte si nejnovější chybu, kterou poskytla položka IIS AspNetCoreModule nebo IIS AspNetCoreModule v2 ve zdrojovém sloupci.

Alternativou k použití okna diagnostikovat a řešit problémy je kontrola 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 v novém okně nebo záložce 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 soubory protokolů .
4. Vyberte ikonu tužky vedle eventlog.xml souboru.
5. Projděte si protokol. Posuňte se do dolní části protokolu, abyste viděli nejaktuálnější události.

Spuštění aplikace v konzole Kudu

Mnoho chyb při spuštění nevytváří užitečné informace v protokolu událostí aplikace. Tuto chybu můžete zjistit spuštěním aplikace v konzole vzdáleného spuštění 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 v novém okně nebo záložce prohlížeče.
2. Pomocí navigačního panelu v horní části stránky otevřete konzolu ladění a vyberte cmd.

Testování 32 (x86) aplikace

Aktuální verze

1. cd d:\home\site\wwwroot
2. Spuštění aplikace:

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

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Pokud je aplikace samostatná, nasazení:

     {ASSEMBLY NAME}.exe
     

Výstup konzoly z aplikace, v němž se zobrazují všechny chyby, je předán do konzoly Kudu.

Nasazení závislé na architektuře spuštěné ve verzi Preview

vyžaduje instalaci rozšíření webu ASP.NET Core {VERSION} (x86) Runtime.

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, v němž se zobrazují všechny chyby, je předán do konzoly Kudu.

Testování 64 aplikace (x64)

Aktuální verze

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

Výstup konzoly z aplikace, v němž se zobrazují všechny chyby, je předán do konzoly Kudu.

Nasazení závislé na architektuře spuštěné ve verzi Preview

vyžaduje instalaci rozšíření webu ASP.NET Core {VERSION} (x64) Runtime.

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, v němž se zobrazují všechny chyby, je předán do konzoly Kudu.

ASP.NET Core Modul protokolu stdout (Azure App Service)

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

1. Přejděte do okna diagnostikovat a řešit problémy v Azure Portal.
2. V části Vybrat kategorii problému vyberte tlačítko pro webovou aplikaci .
3. V části navrhovaná řešení > povolte přesměrování protokolu stdout a výběrem tlačítka otevřete konzolu Kudu a upravte Web.Config.
4. V konzole pro diagnostiku Kudu otevřete složky v lokalitě s cestou > wwwroot. Posuňte se dolů, aby se soubor web.config v dolní části seznamu.
5. Klikněte na ikonu tužky vedle web.config souboru.
6. Nastavte stdoutLogEnabled na true a změňte cestu stdoutLogFile na: \\?\%home%\LogFiles\stdout .
7. Výběrem Uložit Uložte aktualizovaný soubor web.config .
8. Vytvořte žádost do aplikace.
9. Vraťte se na Azure Portal. V oblasti vývojové nástroje vyberte okno Pokročilé nástroje . Vyberte tlačítko Přejít → . Konzola Kudu se otevře v novém okně nebo záložce 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 soubory protokolů .
12. Zkontrolujte upravený sloupec a vyberte ikonu tužky a upravte protokol stdout s nejnovějším datem úpravy.
13. Po otevření souboru protokolu se zobrazí chyba.

Zakázat protokolování stdout při odstraňování potíží:

1. V diagnostické konzole Kudu se vraťte do umístění > wwwroot lokality a odhalte tak soubor web.config . Znovu otevřete soubor web.config tím, že vyberete ikonu tužky.
2. Nastavte stdoutLogEnabled na false .
3. Vyberte Uložit a soubor uložte.

Další informace naleznete v tématu Modul ASP.NET Core.

Pomalá nebo zavěšená aplikace (Azure App Service)

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

• Řešení potíží s výkonem pomalých webových aplikací ve službě Azure App Service
• K zachycení výpisu problémů s přerušovanou výjimkou nebo problémy s výkonem ve webové aplikaci Azure použijte rozšíření pro diagnostiku zhroucení serveru.

Okna monitorování

Okna monitorování poskytují alternativní možnosti řešení potíží pro metody popsané dříve v tématu. Pomocí těchto oken můžete diagnostikovat chyby 500-Series.

potvrďte, že jsou nainstalovaná rozšíření ASP.NET Core. Pokud rozšíření nejsou nainstalovaná, nainstalujte je ručně:

1. V části okna VÝVOJOVÉ NÁSTROJE vyberte okno Rozšíření.
2. V ASP.NET Core by se měla zobrazit pole Rozšíření.
3. Pokud rozšíření nejsou nainstalovaná, vyberte tlačítko Přidat.
4. V seznamu ASP.NET Core vyberte Rozšíření.
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 oznamuje, kdy se rozšíření úspěšně nainstalovala.

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

1. V 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.
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 s cestou wwwroot a posuňte se dolů, aby se > web.config v dolní části seznamu.
4. Klikněte na ikonu tužky vedle web.config souboru.
5. Nastavte stdoutLogEnabled na true a změňte cestu stdoutLogFile na: \\?\%home%\LogFiles\stdout .
6. Vyberte Uložit a uložte aktualizovaný web.config souboru.

Pokračujte aktivací protokolování diagnostiky:

1. V Azure Portal vyberte okno Diagnostické protokoly.
2. Vyberte přepínač Zapnout pro Application Logging (Systém souborů) a Podrobné chybové zprávy. V horní části okna vyberte tlačítko Uložit.
3. Pokud chcete zahrnout trasování neúspěšných požadavků, označované také jako protokolování FRB (Failed Request Buffering), vyberte přepínač On (On) pro Trasování neúspěšných požadavků.
4. Vyberte okno Stream protokolu, které je okamžitě uvedené v okně Diagnostické protokoly na portálu.
5. Vytvořte požadavek na aplikaci.
6. V datech streamu protokolu je uvedena příčina chyby.

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

Zobrazení protokolů trasování neúspěšných žádostí (protokoly FRB):

1. Přejděte do okna Diagnostika a řešení problémů v Azure Portal.
2. V oblasti SUPPORT TOOLS na bočním panelu vyberte Failed Request Tracing Logs (Protokoly trasování neúspěšných žádostí).

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

Další informace najdete v tématu Povolení protokolování diagnostiky pro webové aplikace v Azure App Service.

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 Windows Protokoly.
3. Výběrem možnosti Aplikace otevřete protokol událostí aplikace.
4. Vyhledejte chyby související s aplikací, která selhává. Chyby mají ve sloupci Zdroj hodnotu Modul AspNetCore služby IIS nebo IIS Express modulu AspNetCore.

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

Mnoho chyb při spuštění nevytváří v protokolu událostí aplikace užitečné informace. Příčinu některých chyb můžete zjistit spuštěním aplikace na příkazovém řádku hostitelského 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 pomocí dotnet.exe. V následujícím příkazu nahraďte názvem sestavení aplikace <assembly_name> : dotnet .\<assembly_name>.dll .
2. Výstup konzoly z aplikace se zobrazenými chybami se zapisují do okna konzoly.
3. Pokud při vytváření požadavku na aplikaci dojde k chybám, požádejte hostitele a port, kde Kestrel naslouchá. Pomocí výchozího hostitele a příkazu post vytvořte požadavek na http://localhost:5000/ . Pokud aplikace normálně reaguje na adresu koncového bodu, problém pravděpodobně souvisí s konfigurací hostování a s menší pravděpodobností Kestrel v rámci aplikace.

Samostatné nasazení

Pokud je aplikace samostatná, nasazování:

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ázvem sestavení aplikace <assembly_name> : <assembly_name>.exe .
2. Výstup konzoly z aplikace se zobrazenými chybami se zapisují do okna konzoly.
3. Pokud při vytváření požadavku na aplikaci dojde k chybám, požádejte hostitele a port, kde Kestrel naslouchá. Pomocí výchozího hostitele a příkazu post vytvořte požadavek na http://localhost:5000/ . Pokud aplikace normálně reaguje na adresu koncového bodu, problém pravděpodobně souvisí s konfigurací hostování a s menší pravděpodobností Kestrel v rámci aplikace.

ASP.NET Core Protokol stdout modulu (IIS)

Povolení a zobrazení protokolů stdout:

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

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

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

Další informace naleznete v tématu Modul ASP.NET Core.

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

Proměnnou ASPNETCORE_ENVIRONMENT prostředí je možné přidat do web.config pro spuštění aplikace ve vývojovém prostředí. Pokud se prostředí ve tvůrci hostitelů při spuštění aplikace v tvůrci hostitelů přepíše, umožní nastavení proměnné prostředí zobrazení stránky výjimky vývojáře při UseEnvironment spuštění aplikace.

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

Nastavení proměnné prostředí pro se doporučuje jenom pro použití na pracovních a testovacích serverech, které ASPNETCORE_ENVIRONMENT nejsou vystavené na internetu. Po řešení potíží odeberte proměnnou prostředíweb.config souboru. Informace o nastavení proměnných prostředí vweb.config najdete v tématu environmentVariables podřízeného prvku aspNetCore.

Získání dat z aplikace

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

Pomalá nebo zamykaná aplikace (IIS)

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

Aplikace dojde k chybě nebo dojde k výjimce

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

1. Vytvořte složku pro umístění souborů s výpisem stavu systému na adrese c:\dumps . Fond aplikací musí mít ke složce oprávnění k zápisu.

2. Spusťte powershellový skript 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ůsobí selhání.

4. Po chybě spusťte powershellový skript DisableDumps:

   • 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 chybě aplikace a dokončení shromažďování výpisů paměti se aplikace může normálně ukončit. Skript PowerShellu nakonfiguruje WER tak, aby na jednu aplikaci shromažďoval až pět výpisů paměti.

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

Když aplikace přestane reagovat (přestane reagovat, ale nehavaruje), při spuštění selže nebo se spustí normálně, podívejte se na článek Soubory s výpisem stavu systému v uživatelském režimu: Výběr nejlepšího nástroje pro výběr vhodného nástroje pro vytvoření výpisu stavu systému.

Analýza výpisu paměti

Výpis paměti lze analyzovat pomocí několika přístupů. Další informace najdete v tématu Analýza User-Mode výpisu stavu systému.

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

Funkční aplikace může selhat okamžitě po upgradu .NET Core SDK na vývojovém počítači nebo změně verzí balíčků v rámci aplikace. V některých případech může při provádění významných upgradů dojít k přerušení aplikace v neschválených balíčcích. Většinu těchto problémů můžete vyřešit pomocí těchto pokynů:

1. Odstraňte složky bin a obj.

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

   Vymazání mezipamětí balíčků lze provést také pomocí nástrojenuget.exe a spuštění příkazu nuget locals all -clear . nuget.exe není součástí instalace s desktopovou Windows a je nutné ji získat odděleně od NuGet webu.

3. Obnovte a znovu sestavte projekt.

4. Před znovunasazování aplikace odstraňte všechny soubory ve složce nasazení na serveru.

Další zdroje informací

• řešení potíží a ladění ASP.NET Corech projektů
• Referenční informace k běžným chybám Azure App Service a IIS s ASP.NET Core
• Zpracování chyb v ASP.NET Core
• Modul ASP.NET Core

Dokumentace k Azure

• Application Insights pro ASP.NET Core
• Část Vzdálené ladění webových aplikací tématu Řešení potíží s webovou aplikací Azure App Service pomocí Visual Studio
• Azure App Service diagnostiky
• Postup: Monitorování aplikací ve službě Azure App Service
• Řešení potíží s webovou aplikací Azure App Service pomocí Visual Studio
• Řešení chyb HTTP chyb 502 – Chybná brána a Nedostupná služba 503 ve webových aplikacích Azure
• Řešení potíží s výkonem pomalých webových aplikací ve službě Azure App Service
• Nejčastější dotazy k výkonu aplikací Web Apps v Azure
• Sandbox webové aplikace Azure (App Service spuštění modulu runtime)

Dokumentace sady Visual Studio

• Vzdálené ladění ASP.NET Core iis v Azure v Visual Studio 2017
• Vzdálené ladění ASP.NET Core vzdáleném počítači se službou IIS v Visual Studio 2017
• Informace o ladění pomocí sady Visual Studio

Visual Studio Code dokumentace

• Ladění s Visual Studio Code