Rozwiązywanie problemów z typowymi błędami platformy ASP.NET Core w usłudze Azure App Service i usługach IIS

Autor: Justin Kotalik

Ten artykuł zawiera informacje na temat typowych błędów uruchamiania aplikacji i instrukcji dotyczących diagnozowania błędów podczas wdrażania aplikacji w usłudze aplikacja systemu Azure lub usługach IIS:

Błędy uruchamiania aplikacji
Objaśnia typowe scenariusze kodu stanu HTTP uruchamiania.

Rozwiązywanie problemów z usługą aplikacja systemu Azure
Zawiera porady dotyczące rozwiązywania problemów z aplikacjami wdrożonym w usłudze aplikacja systemu Azure Service.

Rozwiązywanie problemów w usługach IIS
Zawiera porady dotyczące rozwiązywania problemów dla aplikacji wdrożonych w usługach IIS lub uruchomionych lokalnie w usługach IIS Express. Wskazówki dotyczą wdrożeń systemów Windows Server i Windows Desktop.

Wyczyść pamięci podręczne pakietów
Wyjaśnia, co należy zrobić, gdy niespójne pakiety przerywają działanie aplikacji podczas przeprowadzania głównych uaktualnień lub zmiany wersji pakietów.

Dodatkowe zasoby
Zawiera listę dodatkowych tematów dotyczących rozwiązywania problemów.

Błędy uruchamiania aplikacji

W programie Visual Studio domyślny serwer projektu ASP.NET Core to Kestrel. Program Visual Studio można skonfigurować do korzystania z usług IIS Express. 502.5 — Niepowodzenie procesu lub 500.30 — niepowodzenie uruchamiania występujące podczas lokalnego debugowania za pomocą programu IIS Express można zdiagnozować, korzystając z porad w tym temacie.

403.14 Zabronione

Nie można uruchomić aplikacji. Rejestrowany jest następujący błąd:

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

Błąd jest zwykle spowodowany uszkodzonym wdrożeniem w systemie hostingu, który obejmuje dowolny z następujących scenariuszy:

• Aplikacja jest wdrażana w niewłaściwym folderze w systemie hostingu.
• Proces wdrażania nie może przenieść wszystkich plików i folderów aplikacji do folderu wdrożenia w systemie hostingu.
• Brak pliku web.config we wdrożeniu lub zawartość pliku web.config jest źle sformułowana.

Wykonaj następujące kroki:

1. Usuń wszystkie pliki i foldery z folderu wdrożenia w systemie hostingu.
2. Ponownie wdróż zawartość folderu publikowania aplikacji w systemie hostingu przy użyciu normalnej metody wdrażania, takiej jak program Visual Studio, program PowerShell lub wdrożenie ręczne:
   • Upewnij się, że plik web.config znajduje się we wdrożeniu i że jego zawartość jest poprawna.
   • Podczas hostowania w usłudze aplikacja systemu Azure upewnij się, że aplikacja została wdrożona w folderzeD:\home\site\wwwroot.
   • Gdy aplikacja jest hostowana przez usługi IIS, upewnij się, że aplikacja została wdrożona w ścieżce fizycznej usług IIS pokazanej w Ustawienia Podstawowa Ustawienia Menedżera usług IIS.
3. Upewnij się, że wszystkie pliki i foldery aplikacji są wdrażane, porównując wdrożenie w systemie hostingowym z zawartością folderu publikowania projektu.

Aby uzyskać więcej informacji na temat układu opublikowanej aplikacji ASP.NET Core, zobacz ASP.NET Core directory structure (Struktura katalogów ASP.NET Core). Aby uzyskać więcej informacji na temat pliku web.config , zobacz ASP.NET Core Module (ANCM) dla usług IIS.

500 Wewnętrzny błąd serwera

Aplikacja jest uruchamiana, ale błąd uniemożliwia serwerowi spełnienie żądania.

Ten błąd występuje w kodzie aplikacji podczas uruchamiania lub podczas tworzenia odpowiedzi. Odpowiedź może nie zawierać zawartości lub odpowiedź może pojawić się jako błąd wewnętrzny serwera 500 w przeglądarce. Dziennik zdarzeń aplikacji zwykle wskazuje, że aplikacja została uruchomiona normalnie. Z perspektywy serwera jest to poprawne. Aplikacja została uruchomiona, ale nie może wygenerować prawidłowej odpowiedzi. Uruchom aplikację w wierszu polecenia na serwerze lub włącz dziennik stdout modułu podstawowego ASP.NET, aby rozwiązać ten problem.

Ten błąd może również wystąpić, gdy pakiet hostingu platformy .NET Core nie jest zainstalowany lub jest uszkodzony. Zainstalowanie lub naprawienie instalacji pakietu hostingowego .NET Core (dla usług IIS) lub Visual Studio (dla usług IIS Express) może rozwiązać ten problem.

500.0 Niepowodzenie ładowania programu obsługi procesów

Proces roboczy kończy się niepowodzeniem. Aplikacja nie jest uruchamiana.

Wystąpił nieznany błąd podczas ładowania składników modułu podstawowego ASP.NET. Wykonaj jedno z następujących działań:

• Skontaktuj się z pomoc techniczna firmy Microsoft (wybierz pozycję Narzędzia deweloperskie, a następnie ASP.NET Core).
• Zadaj pytanie w witrynie Stack Overflow.
• Zgłoś problem w naszym repozytorium GitHub.

Błąd uruchamiania procesu 500.30

Proces roboczy kończy się niepowodzeniem. Aplikacja nie jest uruchamiana.

Moduł ASP.NET Core próbuje uruchomić proces środowiska .NET Core CLR, ale nie można go uruchomić. Przyczyną niepowodzenia uruchamiania procesu zwykle można określić wpisy w dzienniku zdarzeń aplikacji i dziennik stdout modułu podstawowego ASP.NET.

Typowe warunki niepowodzenia:

• Aplikacja jest nieprawidłowo skonfigurowana z powodu określania wersji platformy udostępnionej ASP.NET Core, która nie jest obecna. Sprawdź, które wersje platformy udostępnionej ASP.NET Core są zainstalowane na maszynie docelowej.
• Korzystanie z usługi Azure Key Vault, brak uprawnień do usługi Key Vault. Sprawdź zasady dostępu w docelowej usłudze Key Vault, aby upewnić się, że udzielono odpowiednich uprawnień.

500.31 NIE można odnaleźć zależności natywnych

Proces roboczy kończy się niepowodzeniem. Aplikacja nie jest uruchamiana.

Moduł ASP.NET Core próbuje uruchomić środowisko uruchomieniowe platformy .NET Core w procesie, ale nie można go uruchomić. Najczęstszą przyczyną tego niepowodzenia uruchamiania jest to, że środowisko Microsoft.NETCore.App uruchomieniowe lub Microsoft.AspNetCore.App nie jest zainstalowane. Jeśli aplikacja jest wdrożona w docelowej wersji ASP.NET Core 3.0 i ta wersja nie istnieje na maszynie, ten błąd występuje. Przykładowy komunikat o błędzie jest następujący:

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]

Komunikat o błędzie zawiera listę wszystkich zainstalowanych wersji platformy .NET Core i wersji żądanej przez aplikację. Aby naprawić ten błąd, wykonaj następujące czynności:

• Zainstaluj odpowiednią wersję platformy .NET Core na maszynie.
• Zmień aplikację na docelową wersję platformy .NET Core, która jest obecna na maszynie.
• Opublikuj aplikację jako samodzielne wdrożenie.

Podczas uruchamiania w środowisku deweloperskim (zmienna ASPNETCORE_ENVIRONMENT środowiskowa jest ustawiona na Development), określony błąd jest zapisywany w odpowiedzi HTTP. Przyczyną niepowodzenia uruchamiania procesu jest również dziennik zdarzeń aplikacji.

Nie można załadować biblioteki DLL 500.32 ANCM

Proces roboczy kończy się niepowodzeniem. Aplikacja nie jest uruchamiana.

Najczęstszą przyczyną tego błędu jest to, że aplikacja jest opublikowana dla niezgodnej architektury procesora. Jeśli proces roboczy jest uruchomiony jako aplikacja 32-bitowa, a aplikacja została opublikowana w wersji docelowej 64-bitowej, ten błąd występuje.

Aby naprawić ten błąd, wykonaj następujące czynności:

• Ponownie opublikuj aplikację dla tej samej architektury procesora co proces roboczy.
• Opublikuj aplikację jako wdrożenie zależne od platformy.

Błąd ładowania programu obsługi żądań 500.33 ANCM

Proces roboczy kończy się niepowodzeniem. Aplikacja nie jest uruchamiana.

Aplikacja nie odwołuje się do platformy Microsoft.AspNetCore.App . Tylko aplikacje przeznaczone dla Microsoft.AspNetCore.App platformy mogą być hostowane przez moduł ASP.NET Core.

Aby naprawić ten błąd, upewnij się, że aplikacja jest przeznaczona dla platformy Microsoft.AspNetCore.App . Sprawdź, .runtimeconfig.json czy struktura jest przeznaczona dla aplikacji.

500.34 Modele hostingu mieszanego ANCM nie są obsługiwane

Proces roboczy nie może uruchomić zarówno aplikacji w procesie, jak i aplikacji poza procesem w tym samym procesie.

Aby naprawić ten błąd, uruchom aplikacje w oddzielnych pulach aplikacji usług IIS.

500.35 Wiele aplikacji w procesie ANCM w tym samym procesie

Proces roboczy nie może uruchamiać wielu aplikacji w procesie w tym samym procesie.

Aby naprawić ten błąd, uruchom aplikacje w oddzielnych pulach aplikacji usług IIS.

500.36 Niepowodzenie braku obsługi programu obsługi anCM

Procedura obsługi żądań poza procesem, aspnetcorev2_outofprocess.dll, nie znajduje się obok pliku aspnetcorev2.dll . Oznacza to uszkodzoną instalację modułu podstawowego ASP.NET.

Aby naprawić ten błąd, napraw instalację pakietu hostingu .NET Core (dla usług IIS) lub Visual Studio (dla usług IIS Express).

Nie można uruchomić programu ANCM 500.37 w ramach limitu czasu uruchamiania

Nie można uruchomić narzędzia ANCM w ramach podanego limitu czasu uruchamiania. Domyślnie limit czasu wynosi 120 sekund.

Ten błąd może wystąpić podczas uruchamiania dużej liczby aplikacji na tej samej maszynie. Sprawdź skoki użycia procesora CPU/pamięci na serwerze podczas uruchamiania. Może być konieczne rozłożenie procesu uruchamiania wielu aplikacji.

500.38 Nie znaleziono biblioteki DLL aplikacji ANCM

Program ANCM nie może zlokalizować biblioteki DLL aplikacji, która powinna znajdować się obok pliku wykonywalnego.

Ten błąd występuje podczas hostowania aplikacji spakowanej jako plik wykonywalny z jednym plikiem przy użyciu modelu hostingu w procesie. Model procesu wymaga, aby narzędzie ANCM załadowało aplikację .NET Core do istniejącego procesu usług IIS. Ten scenariusz nie jest obsługiwany przez model wdrażania z jednym plikiem. Aby naprawić ten błąd, użyj jednego z następujących metod w pliku projektu aplikacji:

1. Wyłącz publikowanie pojedynczego pliku, ustawiając PublishSingleFile właściwość MSBuild na false.
2. Przejdź do modelu hostingu poza procesem, ustawiając AspNetCoreHostingModel właściwość MSBuild na OutOfProcess.

Niepowodzenie procesu 502.5

Proces roboczy kończy się niepowodzeniem. Aplikacja nie jest uruchamiana.

Moduł ASP.NET Core próbuje uruchomić proces roboczy, ale nie można go uruchomić. Przyczyną niepowodzenia uruchamiania procesu zwykle można określić wpisy w dzienniku zdarzeń aplikacji i dziennik stdout modułu podstawowego ASP.NET.

Typowym warunkiem niepowodzenia jest to, że aplikacja jest nieprawidłowo skonfigurowana z powodu określania wersji platformy udostępnionej ASP.NET Core, która nie jest obecna. Sprawdź, które wersje platformy udostępnionej ASP.NET Core są zainstalowane na maszynie docelowej. Platforma udostępniona to zestaw zestawów (plików dll), które są instalowane na maszynie i przywoływane przez metapakiet, taki jak Microsoft.AspNetCore.App. Odwołanie do metapakietowego może określać minimalną wymaganą wersję. Aby uzyskać więcej informacji, zobacz Struktura udostępniona.

Strona błędu błędu procesu 502.5 jest zwracana, gdy błędna konfiguracja hostingu lub aplikacji powoduje niepowodzenie procesu roboczego:

Nie można uruchomić aplikacji (ErrorCode "0x800700c1")

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

Nie można uruchomić aplikacji, ponieważ nie można załadować zestawu aplikacji (dll).

Ten błąd występuje, gdy występuje niezgodność bitów między opublikowaną aplikacją a procesem w3wp/iisexpress.

Upewnij się, że ustawienie 32-bitowej puli aplikacji jest poprawne:

1. Wybierz pulę aplikacji w pulach aplikacji menedżera usług IIS.
2. Wybierz pozycję Zaawansowane Ustawienia w obszarze Edytuj pulę aplikacji w panelu Akcje.
3. Ustaw opcję Włącz aplikacje 32-bitowe:
   • W przypadku wdrażania aplikacji 32-bitowej (x86) ustaw wartość na True.
   • W przypadku wdrażania aplikacji 64-bitowej (x64) ustaw wartość na False.

Upewnij się, że w pliku projektu nie występuje konflikt między właściwością <Platform> MSBuild a opublikowaną bitowością aplikacji.

Nie można uruchomić aplikacji (ErrorCode '0x800701b1')

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

Nie można uruchomić aplikacji, ponieważ nie można załadować usługi systemu Windows.

Jedną z typowych usług, które należy włączyć, jest usługa "null". Następujące polecenie włącza usługę systemu null Windows:

sc.exe start null

resetowanie Połączenie

Jeśli po wysłaniu nagłówków wystąpi błąd, jest za późno, aby serwer wysyłał błąd wewnętrzny serwera 500 w przypadku wystąpienia błędu. Dzieje się tak często w przypadku wystąpienia błędu podczas serializacji złożonych obiektów dla odpowiedzi. Ten typ błędu jest wyświetlany jako błąd resetowania połączenia na kliencie. Rejestrowanie aplikacji może pomóc w rozwiązywaniu problemów z tego typu błędami.

Domyślne limity uruchamiania

Moduł ASP.NET Core jest skonfigurowany z domyślnym startupTimeLimit 120 sekund. Po lewej stronie wartości domyślnej uruchomienie aplikacji może potrwać do dwóch minut, zanim moduł zarejestruje błąd procesu. Aby uzyskać informacje na temat konfigurowania modułu, zobacz Atrybuty elementu aspNetCore.

Rozwiązywanie problemów z usługą aplikacja systemu Azure

Ważne

ASP.NET Core w wersji zapoznawczej za pomocą usługi aplikacja systemu Azure Service

ASP.NET Core w wersji zapoznawczej nie są domyślnie wdrażane w usłudze aplikacja systemu Azure Service. Aby hostować aplikację korzystającą z wersji zapoznawczej ASP.NET Core, zobacz Deploy ASP.NET Core preview release to aplikacja systemu Azure Service (Wdrażanie wersji zapoznawczej ASP.NET Core w usłudze aplikacja systemu Azure Service).

Strumień dziennika usług aplikacja systemu Azure Services

Dziennik usług aplikacja systemu Azure przesyła strumienie dzienników w miarę ich wystąpienia. Aby wyświetlić dzienniki przesyłania strumieniowego:

1. W witrynie Azure Portal otwórz aplikację w usłudze App Services.
2. W okienku po lewej stronie przejdź do pozycji Monitorowanie>dzienników usługi App Service.
3. Wybierz pozycję System plików na potrzeby rejestrowania serwera sieci Web. Opcjonalnie włącz rejestrowanie aplikacji.
4. W okienku po lewej stronie przejdź do pozycji Monitorowanie>strumienia dziennika, a następnie wybierz pozycję Dzienniki aplikacji lub Dzienniki serwera sieci Web.

Na poniższych obrazach przedstawiono dane wyjściowe dzienników aplikacji:

Dzienniki przesyłania strumieniowego mają pewne opóźnienie i mogą nie być wyświetlane natychmiast.

Dziennik zdarzeń aplikacji (usługa aplikacja systemu Azure)

Aby uzyskać dostęp do dziennika zdarzeń aplikacji, użyj bloku Diagnozowanie i rozwiązywanie problemów w witrynie Azure Portal:

1. W witrynie Azure Portal otwórz aplikację w usłudze App Services.
2. Wybierz pozycję Diagnozuj i rozwiąż problemy.
3. Wybierz nagłówek Narzędzia diagnostyczne.
4. W obszarze Narzędzia pomocy technicznej wybierz przycisk Zdarzenia aplikacji.
5. Sprawdź najnowszy błąd dostarczony przez moduł IIS AspNetCoreModule lub iis AspNetCoreModule V2 w kolumnie Źródło .

Alternatywą dla bloku Diagnozowanie i rozwiązywanie problemów jest sprawdzenie pliku dziennika zdarzeń aplikacji bezpośrednio przy użyciu narzędzia Kudu:

1. Otwórz pozycję Narzędzia zaawansowane w obszarze Narzędzia programistyczne. Wybierz przycisk Przejdź→. Konsola Kudu zostanie otwarta na nowej karcie lub w nowym oknie przeglądarki.
2. Korzystając z paska nawigacyjnego w górnej części strony, otwórz konsolę debugowania i wybierz pozycję CMD.
3. Otwórz folder LogFiles.
4. Wybierz ikonę ołówka obok eventlog.xml pliku.
5. Sprawdź dziennik. Przewiń w dół dziennika, aby wyświetlić najnowsze zdarzenia.

Uruchamianie aplikacji w konsoli Kudu

Wiele błędów uruchamiania nie generuje przydatnych informacji w dzienniku zdarzeń aplikacji. Aplikację można uruchomić w konsoli zdalnego wykonywania Kudu , aby wykryć błąd:

1. Otwórz pozycję Narzędzia zaawansowane w obszarze Narzędzia programistyczne. Wybierz przycisk Przejdź→. Konsola Kudu zostanie otwarta na nowej karcie lub w nowym oknie przeglądarki.
2. Korzystając z paska nawigacyjnego w górnej części strony, otwórz konsolę debugowania i wybierz pozycję CMD.

Testowanie aplikacji 32-bitowej (x86)

Bieżąca wersja

1. cd d:\home\site\wwwroot
2. Uruchom aplikację:

   • Jeśli aplikacja jest wdrożeniem zależnym od platformy:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Jeśli aplikacja jest wdrożeniem samodzielnym:

     {ASSEMBLY NAME}.exe
     

Dane wyjściowe konsoli z aplikacji, pokazujące błędy, są przesyłane potokami do konsoli Kudu.

Wdrożenie zależne od struktury uruchomione w wersji zapoznawczej

Wymaga zainstalowania rozszerzenia lokacji środowiska uruchomieniowego ASP.NET Core {VERSION} (x86).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} to wersja środowiska uruchomieniowego)
2. Uruchom aplikację: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Dane wyjściowe konsoli z aplikacji, pokazujące błędy, są przesyłane potokami do konsoli Kudu.

Testowanie aplikacji 64-bitowej (x64)

Bieżąca wersja

• Jeśli aplikacja jest wdrożeniem zależnym od platformy 64-bitowej (x64):
  1. cd D:\Program Files\dotnet
  2. Uruchom aplikację: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Jeśli aplikacja jest wdrożeniem samodzielnym:
  1. cd D:\home\site\wwwroot
  2. Uruchom aplikację: {ASSEMBLY NAME}.exe

Dane wyjściowe konsoli z aplikacji, pokazujące błędy, są przesyłane potokami do konsoli Kudu.

Wdrożenie zależne od struktury uruchomione w wersji zapoznawczej

Wymaga zainstalowania rozszerzenia lokacji środowiska uruchomieniowego ASP.NET Core {VERSION} (x64).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} to wersja środowiska uruchomieniowego)
2. Uruchom aplikację: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

Dane wyjściowe konsoli z aplikacji, pokazujące błędy, są przesyłane potokami do konsoli Kudu.

dziennik stdout modułu podstawowego ASP.NET (usługa aplikacja systemu Azure)

Ostrzeżenie

Niepowodzenie wyłączenia dziennika stdout może prowadzić do błędu aplikacji lub serwera. Nie ma limitu rozmiaru pliku dziennika ani liczby utworzonych plików dziennika. Użyj rejestrowania stdout tylko do rozwiązywania problemów z uruchamianiem aplikacji.

W przypadku ogólnego rejestrowania w aplikacji ASP.NET Core po uruchomieniu użyj biblioteki rejestrowania, która ogranicza rozmiar pliku dziennika i obraca dzienniki. Aby uzyskać więcej informacji, zobacz dostawcy rejestrowania innych firm.

Dziennik stdout modułu podstawowego ASP.NET często rejestruje przydatne komunikaty o błędach nie odnalezione w dzienniku zdarzeń aplikacji. Aby włączyć i wyświetlić dzienniki stdout:

1. W witrynie Azure Portal przejdź do aplikacji internetowej.
2. W bloku App Service wprowadź ciąg kudu w polu wyszukiwania.
3. Wybierz pozycję Narzędzia>zaawansowane.
4. Wybierz pozycję CmD konsoli > debugowania.
5. Przejdź do witryny/wwwroot
6. Wybierz ikonę ołówka, aby edytować plik web.config .
7. W elemecie <aspNetCore /> ustaw stdoutLogEnabled="true" i wybierz pozycję Zapisz.

Wyłącz rejestrowanie stdout po zakończeniu rozwiązywania problemów przez ustawienie .stdoutLogEnabled="false"

Aby uzyskać więcej informacji, zobacz Moduł ASP.NET Core Module (ANCM) dla usług IIS.

dziennik debugowania modułu ASP.NET Core (usługa aplikacja systemu Azure)

Dziennik debugowania modułu ASP.NET Core zapewnia dodatkowe, bardziej szczegółowe rejestrowanie z modułu ASP.NET Core. Aby włączyć i wyświetlić dzienniki stdout:

1. Aby włączyć rozszerzony dziennik diagnostyczny, wykonaj jedną z następujących czynności:
   • Postępuj zgodnie z instrukcjami w sekcji Rozszerzone dzienniki diagnostyczne, aby skonfigurować aplikację na potrzeby rozszerzonego rejestrowania diagnostycznego. Ponownie wdróż aplikację
   • Dodaj plik <handlerSettings> web.config aplikacji na żywo wyświetlany w obszarze Rozszerzone dzienniki diagnostyczne przy użyciu konsoli Kudu:
     1. Otwórz pozycję Narzędzia zaawansowane w obszarze Narzędzia programistyczne. Wybierz przycisk Przejdź→. Konsola Kudu zostanie otwarta na nowej karcie lub w nowym oknie przeglądarki.
     2. Korzystając z paska nawigacyjnego w górnej części strony, otwórz konsolę debugowania i wybierz pozycję CMD.
     3. Otwórz foldery w witrynie>ścieżki wwwroot. Edytuj plik web.config, wybierając przycisk ołówka. Dodaj sekcję <handlerSettings> , jak pokazano w rozszerzonych dziennikach diagnostycznych. Wybierz przycisk zapisywania.
2. Otwórz pozycję Narzędzia zaawansowane w obszarze Narzędzia programistyczne. Wybierz przycisk Przejdź→. Konsola Kudu zostanie otwarta na nowej karcie lub w nowym oknie przeglądarki.
3. Korzystając z paska nawigacyjnego w górnej części strony, otwórz konsolę debugowania i wybierz pozycję CMD.
4. Otwórz foldery w witrynie>ścieżki wwwroot. Jeśli nie podasz ścieżki dla pliku aspnetcore-debug.log , plik zostanie wyświetlony na liście. Jeśli podano ścieżkę, przejdź do lokalizacji pliku dziennika.
5. Otwórz plik dziennika za pomocą przycisku ołówka obok nazwy pliku.

Wyłącz rejestrowanie debugowania po zakończeniu rozwiązywania problemów:

Aby wyłączyć rozszerzony dziennik debugowania, wykonaj jedną z następujących czynności:

• Usuń plik <handlerSettings> z pliku web.config lokalnie i ponownie wdróż aplikację.
• Użyj konsoli Kudu, aby edytować plik web.config i usunąć sekcję <handlerSettings> . Zapisz plik.

Aby uzyskać więcej informacji, zobacz Tworzenie i przekierowywanie dzienników za pomocą modułu ASP.NET Core.

Ostrzeżenie

Niepowodzenie wyłączenia dziennika debugowania może prowadzić do błędu aplikacji lub serwera. Nie ma limitu rozmiaru pliku dziennika. Aby rozwiązać problemy z uruchamianiem aplikacji, użyj rejestrowania debugowania.

W przypadku ogólnego rejestrowania w aplikacji ASP.NET Core po uruchomieniu użyj biblioteki rejestrowania, która ogranicza rozmiar pliku dziennika i obraca dzienniki. Aby uzyskać więcej informacji, zobacz dostawcy rejestrowania innych firm.

Powolne lub zawieszające się aplikacje (aplikacja systemu Azure Service)

Gdy aplikacja reaguje powoli lub zawiesza się na żądanie, zobacz Rozwiązywanie problemów z niską wydajnością aplikacji internetowej w usłudze aplikacja systemu Azure Service.

Bloki monitorowania

Bloki monitorowania zapewniają alternatywne środowisko rozwiązywania problemów z metodami opisanymi wcześniej w temacie. Te bloki mogą służyć do diagnozowania błędów serii 500.

Upewnij się, że zainstalowano rozszerzenia ASP.NET Core. Jeśli rozszerzenia nie są zainstalowane, zainstaluj je ręcznie:

1. W sekcji Narzędzia programistyczne wybierz blok Rozszerzenia.
2. Na liście powinny zostać wyświetlone ASP.NET Core Extensions .
3. Jeśli rozszerzenia nie są zainstalowane, wybierz przycisk Dodaj .
4. Wybierz z listy ASP.NET Core Extensions .
5. Wybierz przycisk OK, aby zaakceptować postanowienia prawne.
6. Wybierz przycisk OK w bloku Dodaj rozszerzenie .
7. Komunikat podręczny informacyjny wskazuje, kiedy rozszerzenia zostały pomyślnie zainstalowane.

Jeśli rejestrowanie stdout nie jest włączone, wykonaj następujące kroki:

1. W witrynie Azure Portal wybierz blok Narzędzia zaawansowane w obszarze NARZĘDZIA PROGRAMISTYCZNE. Wybierz przycisk Przejdź→. Konsola Kudu zostanie otwarta na nowej karcie lub w nowym oknie przeglądarki.
2. Korzystając z paska nawigacyjnego w górnej części strony, otwórz konsolę debugowania i wybierz pozycję CMD.
3. Otwórz foldery w witrynie>ścieżki wwwroot i przewiń w dół, aby wyświetlić plik web.config w dolnej części listy.
4. Kliknij ikonę ołówka obok pliku web.config .
5. Ustaw właściwość stdoutLogEnabled na true i zmień ścieżkę stdoutLogFile na: \\?\%home%\LogFiles\stdout.
6. Wybierz pozycję Zapisz , aby zapisać zaktualizowany plik web.config .

Przejdź do aktywowania rejestrowania diagnostycznego:

1. W witrynie Azure Portal wybierz blok Dzienniki diagnostyczne.
2. Wybierz przełącznik Włączony dla funkcji Rejestrowanie aplikacji (system plików) i Szczegółowe komunikaty o błędach. Wybierz przycisk Zapisz w górnej części bloku.
3. Aby uwzględnić śledzenie żądań, które nie powiodło się, nazywane również rejestrowaniem buforowania zdarzeń żądań niepomyślnych (FREB), wybierz przełącznik Włączony dla śledzenia żądań, które zakończyło się niepowodzeniem.
4. Wybierz blok Strumień dziennika, który znajduje się natychmiast w bloku Dzienniki diagnostyczne w portalu.
5. Prześlij żądanie do aplikacji.
6. W danych strumienia dziennika wskazana jest przyczyna błędu.

Pamiętaj, aby wyłączyć rejestrowanie stdout po zakończeniu rozwiązywania problemów.

Aby wyświetlić dzienniki śledzenia żądań niepomyślnych (dzienniki FREB):

1. Przejdź do bloku Diagnozowanie i rozwiązywanie problemów w witrynie Azure Portal.
2. Wybierz pozycję Dzienniki śledzenia żądań niepomyślnych z obszaru NARZĘDZIA POMOCY TECHNICZNEJ paska bocznego.

Aby uzyskać więcej informacji, zobacz sekcję Ślady żądań nieudanych w temacie Włączanie rejestrowania diagnostycznego dla aplikacji internetowych w usłudze aplikacja systemu Azure Service oraz Często zadawane pytania dotyczące wydajności aplikacji internetowych na platformie Azure: Jak mogę włączyć śledzenie żądań, które zakończyło się niepowodzeniem?

Aby uzyskać więcej informacji, zobacz Włączanie rejestrowania diagnostycznego dla aplikacji internetowych w usłudze aplikacja systemu Azure Service.

Ostrzeżenie

Niepowodzenie wyłączenia dziennika stdout może prowadzić do błędu aplikacji lub serwera. Nie ma limitu rozmiaru pliku dziennika ani liczby utworzonych plików dziennika.

W przypadku rutynowego rejestrowania w aplikacji ASP.NET Core użyj biblioteki rejestrowania, która ogranicza rozmiar pliku dziennika i obraca dzienniki. Aby uzyskać więcej informacji, zobacz dostawcy rejestrowania innych firm.

Rozwiązywanie problemów w usługach IIS

Dziennik zdarzeń aplikacji (IIS)

Uzyskaj dostęp do dziennika zdarzeń aplikacji:

1. Otwórz menu Start, wyszukaj Podgląd zdarzeń i wybierz aplikację Podgląd zdarzeń.
2. W Podgląd zdarzeń otwórz węzeł Dzienniki systemu Windows.
3. Wybierz pozycję Aplikacja , aby otworzyć dziennik zdarzeń aplikacji.
4. Wyszukaj błędy skojarzone z aplikacją, która kończy się niepowodzeniem. Błędy mają wartość modułu ASPNetCore usług IIS lub modułu IIS Express AspNetCore w kolumnie Źródło.

Uruchamianie aplikacji w wierszu polecenia

Wiele błędów uruchamiania nie generuje przydatnych informacji w dzienniku zdarzeń aplikacji. Przyczyną niektórych błędów jest uruchomienie aplikacji w wierszu polecenia w systemie hostingu.

Wdrożenie zależne od struktury

Jeśli aplikacja jest wdrożeniem zależnym od platformy:

1. W wierszu polecenia przejdź do folderu wdrożenia i uruchom aplikację, wykonując zestaw aplikacji za pomocą pliku dotnet.exe. W poniższym poleceniu zastąp nazwę zestawu aplikacji assembly_name<>: dotnet .\<assembly_name>.dll.
2. Dane wyjściowe konsoli z aplikacji, pokazujące błędy, są zapisywane w oknie konsoli.
3. Jeśli podczas składania żądania do aplikacji wystąpią błędy, prześlij żądanie do hosta i portu, na którym Kestrel nasłuchuje. Używając domyślnego hosta i wpisu, prześlij żądanie do http://localhost:5000/. Jeśli aplikacja odpowiada normalnie na adres punktu końcowego Kestrel , problem jest bardziej prawdopodobny związany z konfiguracją hostingu i mniej prawdopodobnym rozwiązaniem w aplikacji.

Wdrożenie samodzielne

Jeśli aplikacja jest wdrożeniem samodzielnym:

1. W wierszu polecenia przejdź do folderu wdrożenia i uruchom plik wykonywalny aplikacji. W poniższym poleceniu zastąp nazwę zestawu aplikacji assembly_name<>: <assembly_name>.exe.
2. Dane wyjściowe konsoli z aplikacji, pokazujące błędy, są zapisywane w oknie konsoli.
3. Jeśli podczas składania żądania do aplikacji wystąpią błędy, prześlij żądanie do hosta i portu, na którym Kestrel nasłuchuje. Używając domyślnego hosta i wpisu, prześlij żądanie do http://localhost:5000/. Jeśli aplikacja odpowiada normalnie na adres punktu końcowego Kestrel , problem jest bardziej prawdopodobny związany z konfiguracją hostingu i mniej prawdopodobnym rozwiązaniem w aplikacji.

dziennik stdout modułu podstawowego ASP.NET (IIS)

Aby włączyć i wyświetlić dzienniki stdout:

1. Przejdź do folderu wdrożenia lokacji w systemie hostingu.
2. Jeśli folder logs nie jest obecny, utwórz folder. Aby uzyskać instrukcje dotyczące automatycznego tworzenia folderu dzienników w ramach wdrożenia przez program MSBuild, zobacz temat Struktura katalogu.
3. Edytuj plik web.config. Ustaw właściwość stdoutLogEnabled na true i zmień ścieżkę stdoutLogFile , aby wskazywała folder logs (na przykład .\logs\stdout). stdout w ścieżce jest prefiks nazwy pliku dziennika. Znacznik czasu, identyfikator procesu i rozszerzenie pliku są dodawane automatycznie po utworzeniu dziennika. Jako stdout prefiks nazwy pliku typowy plik dziennika nosi nazwę stdout_20180205184032_5412.log.
4. Upewnij się, że tożsamość puli aplikacji ma uprawnienia do zapisu w folderze logs .
5. Zapisz zaktualizowany plik web.config .
6. Prześlij żądanie do aplikacji.
7. Przejdź do folderu logs . Znajdź i otwórz najnowszy dziennik stdout.
8. Zapoznaj się z dziennikami pod kątem błędów.

Wyłącz rejestrowanie stdout po zakończeniu rozwiązywania problemów:

1. Edytuj plik web.config.
2. Ustaw wartość stdoutLogEnabled na false.
3. Zapisz plik.

Aby uzyskać więcej informacji, zobacz Moduł ASP.NET Core Module (ANCM) dla usług IIS.

Ostrzeżenie

Niepowodzenie wyłączenia dziennika stdout może prowadzić do błędu aplikacji lub serwera. Nie ma limitu rozmiaru pliku dziennika ani liczby utworzonych plików dziennika.

W przypadku rutynowego rejestrowania w aplikacji ASP.NET Core użyj biblioteki rejestrowania, która ogranicza rozmiar pliku dziennika i obraca dzienniki. Aby uzyskać więcej informacji, zobacz dostawcy rejestrowania innych firm.

dziennik debugowania modułu podstawowego ASP.NET (IIS)

Dodaj następujące ustawienia procedury obsługi do pliku web.config aplikacji, aby włączyć dziennik debugowania modułu podstawowego ASP.NET:

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

Upewnij się, że ścieżka określona dla dziennika istnieje i że tożsamość puli aplikacji ma uprawnienia do zapisu w lokalizacji.

Aby uzyskać więcej informacji, zobacz Tworzenie i przekierowywanie dzienników za pomocą modułu ASP.NET Core.

Włączanie strony wyjątku dewelopera

Zmienną ASPNETCORE_ENVIRONMENTśrodowiskową można dodać do pliku web.config , aby uruchomić aplikację w środowisku programistycznym. Jeśli środowisko nie jest zastępowane podczas uruchamiania aplikacji przez UseEnvironment konstruktora hosta, ustawienie zmiennej środowiskowej umożliwia wyświetlenie strony wyjątku dewelopera po uruchomieniu aplikacji.

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

Ustawienie zmiennej środowiskowej dla ASPNETCORE_ENVIRONMENT programu jest zalecane tylko do użycia na serwerach przejściowych i testowych, które nie są uwidocznione w Internecie. Usuń zmienną środowiskową z pliku web.config po rozwiązaniu problemów. Aby uzyskać informacje na temat ustawiania zmiennych środowiskowych w pliku web.config, zobacz environmentVariables element podrzędny aspNetCore.

Uzyskiwanie danych z aplikacji

Jeśli aplikacja może odpowiadać na żądania, uzyskaj żądanie, połączenie i dodatkowe dane z aplikacji przy użyciu wbudowanego oprogramowania pośredniczącego terminalu. Aby uzyskać więcej informacji i przykładowy kod, zobacz Rozwiązywanie problemów i debugowanie projektów ASP.NET Core.

Powolna lub zawieszana aplikacja (IIS)

Zrzut awaryjny to migawka pamięci systemu i może pomóc w ustaleniu przyczyny awarii aplikacji, awarii uruchamiania lub powolnej aplikacji.

Aplikacja ulega awarii lub napotyka wyjątek

Uzyskiwanie i analizowanie zrzutu z Raportowanie błędów systemu Windows (WER):

1. Utwórz folder do przechowywania plików zrzutu awaryjnego pod adresem c:\dumps. Pula aplikacji musi mieć dostęp do zapisu do folderu.

2. Uruchom skrypt EnableDumps programu PowerShell:

   • Jeśli aplikacja używa modelu hostingu w procesie, uruchom skrypt dla pliku w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • Jeśli aplikacja używa modelu hostingu poza procesem, uruchom skrypt dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Uruchom aplikację w warunkach, które powodują wystąpienie awarii.

4. Po wystąpieniu awarii uruchom skrypt DisableDumps programu PowerShell:

   • Jeśli aplikacja używa modelu hostingu w procesie, uruchom skrypt dla pliku w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • Jeśli aplikacja używa modelu hostingu poza procesem, uruchom skrypt dotnet.exe:

     .\DisableDumps dotnet.exe
     

Po awarii aplikacji i zakończeniu zbierania zrzutów aplikacja może zakończyć działanie normalnie. Skrypt programu PowerShell konfiguruje usługę WER do zbierania maksymalnie pięciu zrzutów na aplikację.

Ostrzeżenie

Zrzuty awaryjne mogą zająć dużą ilość miejsca na dysku (do kilku gigabajtów każdy).

Aplikacja zawiesza się, kończy się niepowodzeniem podczas uruchamiania lub działa normalnie

Gdy aplikacja zawiesza się (przestaje odpowiadać, ale nie ulega awarii), kończy się niepowodzeniem podczas uruchamiania lub działa normalnie, zobacz Pliki zrzutu w trybie użytkownika: Wybieranie najlepszego narzędzia , aby wybrać odpowiednie narzędzie do utworzenia zrzutu.

Analizowanie zrzutu

Zrzut można analizować przy użyciu kilku metod. Aby uzyskać więcej informacji, zobacz Analizowanie pliku zrzutu trybu użytkownika.

Wyczyść pamięci podręczne pakietów

Działająca aplikacja może zakończyć się niepowodzeniem natychmiast po uaktualnieniu zestawu .NET Core SDK na komputerze deweloperskim lub zmianie wersji pakietów w aplikacji. W niektórych przypadkach niespójne pakiety mogą spowodować przerwanie aplikacji podczas przeprowadzania głównych uaktualnień. Większość z tych problemów można rozwiązać, wykonując następujące instrukcje:

1. Usuń pojemnik i foldery obj.

2. Wyczyść pamięć podręczną pakietu, wykonując polecenie dotnet nuget locals all --clear z powłoki poleceń.

   Wyczyszczenie pamięci podręcznych pakietów można również wykonać za pomocą narzędzia nuget.exe i wykonać polecenie nuget locals all -clear. Nuget.exe nie jest instalacją pakietową z systemem operacyjnym Windows desktop i należy uzyskać ją oddzielnie od witryny internetowej NuGet.

3. Przywracanie i ponowne kompilowanie projektu.

4. Usuń wszystkie pliki w folderze wdrażania na serwerze przed ponownym wdrożeniem aplikacji.

Dodatkowe zasoby

• Debugowanie platformy .NET i ASP.NET Core kodu źródłowego za pomocą programu Visual Studio
• Rozwiązywanie problemów i debugowanie projektów ASP.NET Core
• Rozwiązywanie problemów z typowymi błędami platformy ASP.NET Core w usłudze Azure App Service i usługach IIS
• Obsługa błędów w środowisku ASP.NET Core
• Moduł ASP.NET Core (ANCM) dla usług IIS

Dokumentacja platformy Azure

• Szczegółowe informacje aplikacji dla platformy ASP.NET Core
• Sekcja Zdalne debugowanie aplikacji internetowych w temacie Rozwiązywanie problemów z aplikacją internetową w usłudze aplikacja systemu Azure przy użyciu programu Visual Studio
• Omówienie diagnostyki usługi Azure App Service
• Jak monitorować aplikacje w usłudze Azure App Service
• Rozwiązywanie problemów z aplikacją internetową w usłudze aplikacja systemu Azure przy użyciu programu Visual Studio
• Rozwiązywanie problemów z błędami HTTP "Zła brama 502" i "Usługa 503 niedostępna" w aplikacjach internetowych platformy Azure
• Rozwiązywanie problemów związanych z niską wydajnością aplikacji internetowych w usłudze Azure App Service
• Często zadawane pytania dotyczące wydajności aplikacji internetowych na platformie Azure
• Piaskownica aplikacji internetowej platformy Azure (ograniczenia wykonywania środowiska uruchomieniowego usługi App Service)

Dokumentacja programu Visual Studio

• Zdalne debugowanie ASP.NET Core w usługach IIS na platformie Azure w programie Visual Studio 2017
• Zdalne debugowanie ASP.NET Core na zdalnym komputerze usług IIS w programie Visual Studio 2017
• Naucz się debugować przy użyciu programu Visual Studio

Dokumentacja programu Visual Studio Code

• Debugowanie za pomocą programu Visual Studio Code