Řešení potíží s ASP.NET Core v Azure App Service a ve službě 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 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.
   • Pokud je aplikace hostovaná službou IIS, ověřte, že je aplikace nasazená na fyzickou cestu IIS zobrazenou v základním nastavení Správce služby IIS.
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 .

502.5 – Selhání procesu

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í (.dll soubory), které jsou nainstalovány na 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

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.
3. Vyberte systém souborů pro protokolování webového serveru. Volitelně můžete povolit protokolování aplikace.
4. V levém podokně přejděte do streamu protokolu monitorování>a pak vyberte Protokoly aplikací nebo Protokoly webového serveru.

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

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:

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

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Pokud se jedná o 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 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, 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 se jedná o 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 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, v němž se zobrazují všechny chyby, je předán 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 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. Uložte soubor.

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

Pomalá nebo nereagující aplikace (služba Aplikace Azure)

Pokud aplikace reaguje pomalu nebo nereaguje 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.

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 identity , že váš fond 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. Uložte soubor.

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

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 fond identity 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_ENVIRONMENT prostř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 nereagovaná 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.

Aplikace nereaguje, během spouštění selže nebo běží normálně

Když aplikace přestane reagovat, ale nespustí se při spuštění nebo se spustí normálně, přečtěte si téma Soubory výpisu stavu systému v uživatelském režimu: Volba nejvhodnějšího nástroje k výběru 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í součástí 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ší materiály

• Ladění zdrojového kódu .NET a ASP.NET Core pomocí sady Visual Studio
• Řešení potíží s projekty ASP.NET Core a jejich ladění
• Řešení běžných chyb v Azure App Service a ve službě IIS souvisejících s ASP.NET Core
• Zpracování chyb v ASP.NET Core
• Modul ASP.NET Core (ANCM) pro službu IIS

Dokumentace Azure

• Application Insights pro ASP.NET Core
• Část Vzdálené ladění webových aplikací v části Řešení potíží s webovou aplikací ve službě Aplikace Azure Pomocí sady Visual Studio
• Přehled diagnostiky Azure App Service
• Postup: Monitorování aplikací ve službě Azure App Service
• Řešení potíží s webovou aplikací ve službě Aplikace Azure Service pomocí sady 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í pro Web Apps v Azure
• Sandbox webové aplikace Azure (omezení spouštění modulu runtime služby App Service)

Dokumentace sady Visual Studio

• Vzdálené ladění ASP.NET Core ve službě IIS v Azure v sadě Visual Studio 2017
• Vzdálené ladění ASP.NET Core na vzdáleném počítači se službou IIS v sadě Visual Studio 2017
• Další informace k ladění pomocí sady Visual Studio

Dokumentace k editoru Visual Studio Code

• Ladění pomocí 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.
   • Pokud je aplikace hostovaná službou IIS, ověřte, že je aplikace nasazená na fyzickou cestu IIS zobrazenou v základním nastavení Správce služby IIS.
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:

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

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.

502.5 – Selhání procesu

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í (.dll soubory), které jsou nainstalovány na 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

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:

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

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Pokud se jedná o 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 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, 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 se jedná o 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 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, v němž se zobrazují všechny chyby, je předán 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.

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. Uložte soubor.

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

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

Pokud aplikace reaguje pomalu nebo nereaguje 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
• Použití rozšíření diagnostiky webu diagnostiky chyb k zachycení výpisu paměti pro občasné problémy s výjimkami nebo problémy s výkonem ve webové aplikaci Azure

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.

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 identity , že váš fond 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. Uložte soubor.

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

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 fond identity 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_ENVIRONMENT prostř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 nereaguje 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.

Aplikace nereaguje, během spouštění selže nebo běží normálně

Když aplikace přestane reagovat, ale nespustí se při spuštění nebo se spustí normálně, přečtěte si téma Soubory výpisu stavu systému v uživatelském režimu: Volba nejvhodnějšího nástroje k výběru 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í součástí 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ší materiály

• Řešení potíží s projekty ASP.NET Core a jejich ladění
• Řešení běžných chyb v Azure App Service a ve službě IIS souvisejících s ASP.NET Core
• Zpracování chyb v ASP.NET Core
• Modul ASP.NET Core (ANCM) pro službu IIS

Dokumentace Azure

• Application Insights pro ASP.NET Core
• Část Vzdálené ladění webových aplikací v části Řešení potíží s webovou aplikací ve službě Aplikace Azure Pomocí sady Visual Studio
• Přehled diagnostiky Azure App Service
• Postup: Monitorování aplikací ve službě Azure App Service
• Řešení potíží s webovou aplikací ve službě Aplikace Azure Service pomocí sady 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í pro Web Apps v Azure
• Sandbox webové aplikace Azure (omezení spouštění modulu runtime služby App Service)

Dokumentace sady Visual Studio

• Vzdálené ladění ASP.NET Core ve službě IIS v Azure v sadě Visual Studio 2017
• Vzdálené ladění ASP.NET Core na vzdáleném počítači se službou IIS v sadě Visual Studio 2017
• Další informace k ladění pomocí sady Visual Studio

Dokumentace k editoru Visual Studio Code

• Ladění pomocí 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.
   • Pokud je aplikace hostovaná službou IIS, ověřte, že je aplikace nasazená na fyzickou cestu IIS zobrazenou v základním nastavení Správce služby IIS.
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).

502.5 – Selhání procesu

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í (.dll soubory), které jsou nainstalovány na 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

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:

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

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Pokud se jedná o 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 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, 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 se jedná o 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 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, v němž se zobrazují všechny chyby, je předán 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.

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

Pokud aplikace reaguje pomalu nebo nereaguje 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
• Použití rozšíření diagnostiky webu diagnostiky chyb k zachycení výpisu paměti pro občasné problémy s výjimkami nebo problémy s výkonem ve webové aplikaci Azure

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.

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 identity , že váš fond 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. Uložte soubor.

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

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

Proměnnou ASPNETCORE_ENVIRONMENT prostř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 nereaguje 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.

Aplikace nereaguje, během spouštění selže nebo běží normálně

Když aplikace přestane reagovat, ale nespustí se při spuštění nebo se spustí normálně, přečtěte si téma Soubory výpisu stavu systému v uživatelském režimu: Volba nejvhodnějšího nástroje k výběru 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í součástí 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ší materiály

• Řešení potíží s projekty ASP.NET Core a jejich ladění
• Řešení běžných chyb v Azure App Service a ve službě IIS souvisejících s ASP.NET Core
• Zpracování chyb v ASP.NET Core
• Modul ASP.NET Core (ANCM) pro službu IIS

Dokumentace Azure

• Application Insights pro ASP.NET Core
• Část Vzdálené ladění webových aplikací v části Řešení potíží s webovou aplikací ve službě Aplikace Azure Pomocí sady Visual Studio
• Přehled diagnostiky Azure App Service
• Postup: Monitorování aplikací ve službě Azure App Service
• Řešení potíží s webovou aplikací ve službě Aplikace Azure Service pomocí sady 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í pro Web Apps v Azure
• Sandbox webové aplikace Azure (omezení spouštění modulu runtime služby App Service)

Dokumentace sady Visual Studio

• Vzdálené ladění ASP.NET Core ve službě IIS v Azure v sadě Visual Studio 2017
• Vzdálené ladění ASP.NET Core na vzdáleném počítači se službou IIS v sadě Visual Studio 2017
• Další informace k ladění pomocí sady Visual Studio

Dokumentace k editoru Visual Studio Code

• Ladění pomocí 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 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.
   • Pokud je aplikace hostovaná službou IIS, ověřte, že je aplikace nasazená na fyzickou cestu IIS zobrazenou v základním nastavení Správce služby IIS.
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 .

502.5 – Selhání procesu

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í (.dll soubory), které jsou nainstalovány na 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

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.
3. Vyberte systém souborů pro protokolování webového serveru. Volitelně můžete povolit protokolování aplikace.
4. V levém podokně přejděte do streamu protokolu monitorování>a pak vyberte Protokoly aplikací nebo Protokoly webového serveru.

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

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:

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

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Pokud se jedná o 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 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, 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 se jedná o 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 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, v němž se zobrazují všechny chyby, je předán 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 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. Uložte soubor.

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

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

Pokud aplikace reaguje pomalu nebo nereaguje 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.

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 identity , že váš fond 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. Uložte soubor.

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

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 fond identity 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_ENVIRONMENT prostř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 nereaguje 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.

Aplikace nereaguje, během spouštění selže nebo běží normálně

Když aplikace přestane reagovat, ale nespustí se při spuštění nebo se spustí normálně, přečtěte si téma Soubory výpisu stavu systému v uživatelském režimu: Volba nejvhodnějšího nástroje k výběru 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í součástí 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ší materiály

• Ladění zdrojového kódu .NET a ASP.NET Core pomocí sady Visual Studio
• Řešení potíží s projekty ASP.NET Core a jejich ladění
• Řešení běžných chyb v Azure App Service a ve službě IIS souvisejících s ASP.NET Core
• Zpracování chyb v ASP.NET Core
• Modul ASP.NET Core (ANCM) pro službu IIS

Dokumentace Azure

• Application Insights pro ASP.NET Core
• Část Vzdálené ladění webových aplikací v části Řešení potíží s webovou aplikací ve službě Aplikace Azure Pomocí sady Visual Studio
• Přehled diagnostiky Azure App Service
• Postup: Monitorování aplikací ve službě Azure App Service
• Řešení potíží s webovou aplikací ve službě Aplikace Azure Service pomocí sady 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í pro Web Apps v Azure
• Sandbox webové aplikace Azure (omezení spouštění modulu runtime služby App Service)

Dokumentace sady Visual Studio

• Vzdálené ladění ASP.NET Core ve službě IIS v Azure v sadě Visual Studio 2017
• Vzdálené ladění ASP.NET Core na vzdáleném počítači se službou IIS v sadě Visual Studio 2017
• Další informace k ladění pomocí sady Visual Studio

Dokumentace k editoru Visual Studio Code

• Ladění pomocí editoru Visual Studio Code