Устранение неполадок ASP.NET Core в Службе приложений Azure и IIS

Автор Джастин Коталик (Justin Kotalik)

В этой статье содержатся сведения об общих ошибках запуска приложений и инструкции по диагностике ошибок при развертывании приложения в Службе приложений Azure или службах IIS:

Ошибки при запуске приложения
Описание распространенных сценариев кода состояния HTTP для запуска.

Устранение неполадок в Службе приложений Azure
Рекомендации по устранению неполадок для приложений, развернутых в Службе приложений Azure.

Устранение неполадок в IIS
Рекомендации по устранению неполадок для приложений, развернутых в службах IIS или запущенных на IIS Express локально. Руководство относится к развертываниям Windows Server и Windows Desktop.

Очистка кэшей пакетов
Рекомендации о том, что делать, когда несогласованные пакеты нарушают работу приложения при установке основных обновлений или изменении версий пакета.

Дополнительные ресурсы
Дополнительные статьи по устранению неполадок.

Ошибки при запуске приложения

В Visual Studio сервер проекта по умолчанию ASP.NET Core — это Kestrel. Visual Studio можно настроить для использования IIS Express. Рекомендации в этой статье позволяют диагностировать неполадки, проявляющиеся как коды состояния 502.5 — Process Failure (502.5 — ошибка процесса) или 500.30 — Start Failure (500.30 — ошибка запуска) при локальной отладке с помощью IIS Express.

403.14 (Запрещено)

Приложение не запускается. В журнал записывается следующая ошибка:

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

Эта ошибка обычно вызвана неработающим развертыванием в системе размещения в следующих сценариях:

• Приложение развертывается в неверной папке в системе размещения.
• Процессу развертывания не удалось переместить все файлы и папки приложения в папку развертывания в системе размещения.
• Файл web.config отсутствует в развертывании, или содержимое файла web.config имеет неправильную структуру.

Выполните следующие шаги:

1. Удалите все файлы и папки из папки развертывания в системе размещения.
2. Повторно разверните содержимое папки публикации приложения в системе размещения с помощью обычного метода развертывания, например Visual Studio, PowerShell или ручного развертывания:
   • Убедитесь, что файл web.config находится в развертывании и имеет правильное содержимое.
   • При размещении в Службе приложений Azure убедитесь, что приложение развернуто в папке D:\home\site\wwwroot.
   • Если приложение размещено в IIS, убедитесь, что оно развернуто по физическому пути служб IIS, указанному в базовых параметрах в диспетчере IIS.
3. Убедитесь, что все файлы и папки приложения развернуты путем сравнения развертывания в системе размещения с содержимым папки проекта publish.

Дополнительные сведения о макете опубликованного приложения ASP.NET Core см. в статье Структура каталогов ASP.NET Core. Дополнительные сведения о файле web.config см. в разделе Модуль ASP.NET Core для IIS.

500 Internal Server Error (внутренняя ошибка сервера).

Приложение запускается, но ошибка не позволяет серверу выполнить запрос.

Эта ошибка возникает в коде приложения при запуске или при создании ответа. Ответ может не иметь содержимого или ответ в браузере может выглядеть как 500 — внутренняя ошибка сервера. Как правило, в журнале событий приложения указывается, что приложение запускается в обычном режиме. Сервер действует правильно. Приложение запустилось, но оно не может генерировать действительный ответ. Чтобы устранить проблему, запустите приложение в командной строке на сервере или включите журнал вывода stdout для модуля ASP.NET Core.

Эта ошибка также может возникать, если пакет размещения .NET Core не установлен или поврежден. Эту проблему можно решить, выполнив установку или исправив установку пакета размещения .NET Core (для служб IIS) или Visual Studio (для IIS Express).

500.0 In-Process Handler Load Failure (ошибка загрузки внутрипроцессного обработчика)

Рабочий процесс завершается ошибкой. Приложение не запускается.

При загрузке компонентов модуля ASP.NET Core произошла неизвестная ошибка. Выполните одно из следующих действий:

• Обратитесь в службу поддержки Майкрософт (выберите Средства разработчика, а затем — ASP.NET Core).
• Задайте вопрос на сайте Stack Overflow.
• Сообщите о проблеме в нашем репозитории GitHub.

500.30 In-Process Startup Failure (ошибка внутрипроцессного запуска)

Рабочий процесс завершается ошибкой. Приложение не запускается.

Модуль ASP.NET Core пытается запустить среду CLR .NET Core внутри процесса, но она не запускается. Обычно причину сбоя при запуске процесса можно определить по записям в журнале событий приложения и журнале вывода stdout модуля ASP.NET Core.

Распространенные причины сбоя:

• В приложении указана отсутствующая версия общей платформы ASP.NET Core. Проверьте, какие версии общей платформы ASP.NET Core установлены на целевом компьютере.
• При использовании Azure Key Vault не хватает разрешений на Key Vault. Проверьте политики доступа в целевое хранилище Key Vault, чтобы убедиться, что предоставлены правильные разрешения.

500.31 ANCM Failed to Find Native Dependencies (ANCM не удалось найти собственные зависимости)

Рабочий процесс завершается ошибкой. Приложение не запускается.

Модуль ASP.NET Core пытается запустить среду выполнения .NET Core внутри процесса, но она не запускается. Наиболее распространенная причина этой ошибки в том, что среда выполнения Microsoft.NETCore.App или Microsoft.AspNetCore.App не установлена. Если целевой платформой развернутого приложения является ASP.NET Core 3.0, но эта версия отсутствует на компьютере, происходит данная ошибка. Пример сообщения об ошибке:

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]

В сообщении об ошибке перечислены все установленные версии .NET Core и указывается версия, которая требуется приложению. Чтобы устранить эту ошибку, выполните одно из указанных ниже действий.

• Установите соответствующую версию .NET Core на компьютере.
• Измените целевую версию .NET Core приложения на версию, имеющуюся на компьютере.
• Опубликуйте приложение как автономное развертывание.

При запуске в среде разработки (переменная среды ASPNETCORE_ENVIRONMENT имеет значение Development) ошибка записывается в ответ HTTP. Причину сбоя при запуске процесса можно также узнать в журнале событий приложения.

500.32 ANCM Failed to Load dll (ANCM не удалось загрузить библиотеку DLL)

Рабочий процесс завершается ошибкой. Приложение не запускается.

Наиболее распространенная причина этой ошибки в том, что приложение опубликовано для несовместимой архитектуры процессора. Если рабочий процесс выполняется как 32-разрядное приложение, но приложение было опубликовано для 64-разрядной архитектуры, происходит эта ошибка.

Чтобы устранить эту ошибку, выполните одно из указанных ниже действий.

• Повторно опубликуйте приложение для той же архитектуры процессора, для которой предназначен рабочий процесс.
• Опубликуйте приложение как зависящее от платформы развертывание.

500.33 ANCM Request Handler Load Failure (Ошибка загрузки обработчика запросов ANCM)

Рабочий процесс завершается ошибкой. Приложение не запускается.

Приложение не ссылается на платформу Microsoft.AspNetCore.App. В модуле ASP.NET Core могут размещаться только приложения, предназначенные для платформы Microsoft.AspNetCore.App.

Для устранения этой ошибки убедитесь в том, что приложение предназначено для платформы Microsoft.AspNetCore.App. В файле .runtimeconfig.json проверьте, является ли эта платформа целевой для приложения.

500.34 ANCM Mixed Hosting Models Not Supported (Смешанные модели размещения ANCM не поддерживаются)

В одном рабочем процессе не могут выполняться одновременно внутрипроцессное приложение и внепроцессное приложение.

Для устранения этой ошибки запускайте приложения в отдельных пулах приложений IIS.

500.35 ANCM Multiple In-Process Applications in same Process (Несколько внутрипроцессных приложений ANCM в одном процессе)

Рабочий процесс не может запускать несколько внутрипроцессных приложений в одном процессе.

Для устранения этой ошибки запускайте приложения в отдельных пулах приложений IIS.

500.36 ANCM Out-Of-Process Handler Load Failure (Ошибка загрузки внепроцессного обработчика ANCM)

Рядом с файлом aspnetcorev2.dll нет внепроцессного обработчика запросов aspnetcorev2_outofprocess.dll. Это свидетельствует о поврежденной установке модуля ASP.NET Core.

Для устранения этой ошибки восстановите установку пакета размещения .NET Core (для служб IIS) или Visual Studio (для IIS Express).

500.37 ANCM Failed to Start Within Startup Time Limit (Модуль ANCM не запустился в течение предельного времени запуска)

Модуль ANCM не запустился в течение заданного предельного времени запуска. По умолчанию время ожидания составляет 120 секунд.

Эта ошибка может произойти, если на одном компьютере запускается много приложений. Обратите внимание на пики использования ЦП и памяти на сервере во время запуска. Возможно, потребуется регулировать процесс запуска нескольких приложений.

500.38 ANCM Application DLL Not Found

ANCM не удалось найти библиотеку DLL приложения, которая должна находиться рядом с исполняемым файлом.

Эта ошибка возникает при размещении приложения, упакованного в виде исполняемого файла с одним файлом с помощью модели внутрипроцессного размещения. В модели внутрипроцессного процесса требуется, чтобы ANCM загружал приложение .NET Core в существующий процесс IIS. Этот сценарий не поддерживается моделью развертывания с одним файлом. Чтобы устранить эту ошибку, используйте один из следующих подходов в файле проекта приложения.

1. Отключите публикацию с одним файлом, задав для свойства PublishSingleFile MSBuild значение false.
2. Переключитесь на модель вне процесса размещения, задав для свойства AspNetCoreHostingModel MSBuild значение OutOfProcess.

502.5 — ошибка процесса

Рабочий процесс завершается ошибкой. Приложение не запускается.

Модуль ASP.NET Core пытается запустить рабочий процесс, но он не запускается. Обычно причину сбоя при запуске процесса можно определить по записям в журнале событий приложения и журнале вывода stdout модуля ASP.NET Core.

Распространенной причиной сбоя является неправильная настройка приложения с выбором отсутствующей версии общей платформы ASP.NET Core. Проверьте, какие версии общей платформы ASP.NET Core установлены на целевом компьютере. Общая платформа — это набор сборок (DLLl-файлы), которые установлены на компьютере и на которые ссылается метапакет, например Microsoft.AspNetCore.App. В ссылках метапакета может быть указана минимальная требуемая версия. Дополнительную информацию см. в этой публикации об общей платформе.

Когда ошибки в конфигурации размещения или приложения приводят к сбою рабочего процесса, возвращается страница ошибки 502.5 — ошибка процесса.

Не удалось запустить приложение (код ошибки "0x800700c1")

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

Не удалось запустить приложение, так как не удалось загрузить сборку приложения (.dll).

Эта ошибка возникает, если существует несоответствие разрядности опубликованного приложения и процесса w3wp/iisexpress.

Убедитесь, что параметр 32-разрядности пула приложений указан правильно:

1. Выберите пул приложений в диспетчере служб IIS в разделе Пулы приложений.
2. Выберите Дополнительные параметры в разделе Изменение пула приложений панели Действия.
3. Задайте для включения 32-разрядных приложений:
   • При развертывании 32-разрядного (x86) приложения задайте значение True.
   • При развертывании 64-разрядного (x64) приложения задайте значение False.

Убедитесь в отсутствии конфликта между свойством <Platform> MSBuild в файле проекта и опубликованной разрядностью приложения.

Не удалось запустить приложение (ErrorCode "0x800701b1")

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

Не удалось запустить приложение, так как не удалось загрузить службу Windows.

Одна из общих служб, которая должна быть включена, — это служба NULL. Следующая команда включает null службу Windows:

sc.exe start null

Сброс подключения

Если ошибка возникает после отправки заголовков, сервер уже не может отправить страницу 500 — внутренняя ошибка сервера. Это часто происходит, когда ошибка возникает во время сериализации составных объектов ответа. Этот тип ошибки отображается на стороне клиента как ошибка Сброс подключения. Ведение журналов для приложений может помочь устранить эти ошибки.

Ограничения по умолчанию при запуске

Для параметра startupTimeLimitмодуля ASP.NET Core установлено значение по умолчанию 120 секунд. Если оставить значение по умолчанию, то прежде чем журнал модуля зарегистрирует ошибку запуска приложения, может пройти до двух минут. Сведения о настройке модуля см. в разделе Атрибуты элемента aspNetCore.

Устранение неполадок в Службе приложений Azure

Важно!

Предварительные версии ASP.NET Core в службе приложений Azure

Предварительные версии ASP.NET Core не развертываются в службе приложений Azure по умолчанию. Чтобы разместить приложение, которое использует предварительную версию ASP.NET Core, см. раздел Развертывание предварительной версии ASP.NET Core в службе приложений Azure.

Поток журнала Служб приложений Azure

Журнал Служб приложений Azure выполняет потоковую передачу информации журнала по мере ее появления. Чтобы просмотреть журналы потоковой передачи, выполните следующие действия:

1. На портале Azure откройте приложение в колонке Службы приложений.
2. В области слева перейдите к разделу Мониторинг>Журналы Службы приложений.
3. Выберите Файловую систему для Ведения журнала веб-сервера. При необходимости включите Ведение журнала приложений.
4. В области слева перейдите к разделу Мониторинг>Потоковая передача журналов, а затем выберите Журналы приложений или Журналы веб-сервера.

На следующих изображениях показаны выходные данные журналов приложений:

Журналы потоковой передачи имеют некоторую задержку и могут не отображаться немедленно.

Журнал событий приложений (Служба приложений Azure)

Чтобы получить доступ к журналу событий приложения, используйте колонку Диагностика и решение проблем на портале Azure.

1. На портале Azure откройте приложение в колонке Службы приложений.
2. Выберите Диагностика и решение проблем.
3. Щелкните заголовок Средства диагностики.
4. В разделе Средства поддержки нажмите кнопку События приложений.
5. Изучите последние ошибки из журнала IIS AspNetCoreModule или IIS AspNetCoreModule V2 в столбце Источник.

Вместо использования колонки Диагностика и решение проблем можно изучить файл журнала событий приложения непосредственно с помощью консоли Kudu.

1. В области Средства разработки откройте колонку Дополнительные инструменты. Нажмите кнопку Перейти→. Консоль Kudu открывается в новой вкладке или в окне браузера.
2. С помощью панели навигации в верхней части страницы откройте Консоль отладки и выберите CMD.
3. Откройте папку LogFiles .
4. Щелкните значок с изображением карандаша рядом с файлом eventlog.xml.
5. Изучите журнал. Прокрутите список до нижней части журнала, чтобы просмотреть последние события.

Запуск приложения в консоли Kudu

Многие ошибки запуска не создают полезные сведения в журнале событий приложения. Чтобы обнаружить ошибку, можно запустить приложение в удаленной консоли выполнения Kudu.

1. В области Средства разработки откройте колонку Дополнительные инструменты. Нажмите кнопку Перейти→. Консоль Kudu открывается в новой вкладке или в окне браузера.
2. С помощью панели навигации в верхней части страницы откройте Консоль отладки и выберите CMD.

Тестирование 32-разрядного (x86) приложения

Текущий выпуск

1. cd d:\home\site\wwwroot
2. Запустите приложение .

   • Если развертываемое приложение зависит от платформы, сделайте следующее:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Если приложение развертывается автономно, сделайте следующее:

     {ASSEMBLY NAME}.exe
     

Выходные данные консоли из приложения, представляющие сведения об ошибках, будут переданы на консоль Kudu.

Зависимое от платформы развертывание, выполняющееся в предварительном выпуске

Требует установки расширения сайта для среды выполнения ASP.NET Core {VERSION} (x86).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} — это версия среды выполнения).
2. Запустите приложение dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll.

Выходные данные консоли из приложения, представляющие сведения об ошибках, будут переданы на консоль Kudu.

Тестирование 64-разрядного (x64) приложения

Текущий выпуск

• Если приложение является 64-разрядным (x64) зависимым от платформы развертыванием:
  1. cd D:\Program Files\dotnet
  2. Запустите приложение dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll.
• Если приложение является автономным развертыванием:
  1. cd D:\home\site\wwwroot
  2. Запустите приложение {ASSEMBLY NAME}.exe.

Выходные данные консоли из приложения, представляющие сведения об ошибках, будут переданы на консоль Kudu.

Зависимое от платформы развертывание, выполняющееся в предварительном выпуске

Требует установки расширения сайта для среды выполнения ASP.NET Core {VERSION} (x64).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} — это версия среды выполнения).
2. Запустите приложение dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll.

Выходные данные консоли из приложения, представляющие сведения об ошибках, будут переданы на консоль Kudu.

Журнал вывода stdout модуля ASP.NET Core (Служба приложений Azure)

Предупреждение

Ошибка при отключении журнала stdout может привести к сбоям приложения или сервера. Ни размер файла журнала, ни количество создаваемых файлов журналов ничем не ограничены. Для устранения неполадок при запуске приложения используйте только журнал stdout.

После запуска в приложении ASP.NET Core для ведения общего журнала используйте библиотеку ведения журналов, которая ограничивает размер файла журнала и выполняет циклический сдвиг журналов. Дополнительные сведения см. в разделе Сторонние поставщики ведения журналов.

В журнале stdout модуля ASP.NET Core часто записываются полезные сообщения, которые не удается найти в журнале событий приложения. Чтобы включить и просмотреть журналы stdout выполните следующие действия.

1. На портале Azure перейдите к веб-приложению.
2. В колонке Служба приложений в поле поиска введите Kudu.
3. Выберите Дополнительные инструменты>Перейти.
4. Выберите Консоль отладки > CMD.
5. Перейдите по адресу site/wwwroot.
6. Щелкните значок карандаша, чтобы изменить файл web.config.
7. В элементе <aspNetCore /> задайте stdoutLogEnabled="true" и выберите команду Сохранить.

Завершив устранение неполадок, отключите ведение журнала stdout, задав stdoutLogEnabled="false".

Дополнительные сведения см. в разделе Модуль ASP.NET Core для IIS.

Журнал отладки модуля ASP.NET Core (Служба приложений Azure)

В журнал отладки модуля ASP.NET записываются дополнительные и более подробные сообщения, относящиеся к модулю ASP.NET Core. Чтобы включить и просмотреть журналы stdout выполните следующие действия.

1. Чтобы включить расширенный журнал диагностики, выполните одно из следующих действий:
   • Следуйте инструкциям по настройке приложения для ведения расширенных журналов диагностики, приведенным в разделе Расширенные журналы диагностики. Повторно разверните приложение.
   • Добавьте приведенные <handlerSettings> в расширенных журналах диагностики в файл веб-конфигурации приложения live.config с помощью консоли Kudu:
     1. В области Средства разработки откройте колонку Дополнительные инструменты. Нажмите кнопку Перейти→. Консоль Kudu открывается в новой вкладке или в окне браузера.
     2. С помощью панели навигации в верхней части страницы откройте Консоль отладки и выберите CMD.
     3. Откройте папки на пути веб-сайт>wwwroot. Нажмите кнопку с изображением карандаша и внесите изменения в файл web.config. Добавьте раздел <handlerSettings>, как описано в разделе Расширенные журналы диагностики. Выберите кнопку Сохранить.
2. В области Средства разработки откройте колонку Дополнительные инструменты. Нажмите кнопку Перейти→. Консоль Kudu открывается в новой вкладке или в окне браузера.
3. С помощью панели навигации в верхней части страницы откройте Консоль отладки и выберите CMD.
4. Откройте папки на пути веб-сайт>wwwroot. Если вы не указали путь к файлу aspnetcore-debug.log, файл появится в списке. Если путь указан, перейдите к расположению файла журнала.
5. Откройте файл журнала, нажав кнопку с изображением карандаша рядом с именем файла.

Завершив устранение неполадок, отключите ведение журнала отладки.

Чтобы отключить ведение расширенных журналов отладки, выполните одно из следующих действий:

• Удалите раздел <handlerSettings> из файла web.config локально и повторно разверните приложение.
• С помощью консоли Kudu внесите изменения в файл web.config и удалите раздел <handlerSettings>. Сохраните файл.

Дополнительные сведения см. в статье Создание и перенаправление журнала с помощью модуля ASP.NET Core.

Предупреждение

Ошибка при отключении журнала отладки может привести к сбоям приложения или сервера. Ограничения на размер файла журнала отсутствуют. Для устранения неполадок при запуске приложения используйте только журнал отладки.

После запуска в приложении ASP.NET Core для ведения общего журнала используйте библиотеку ведения журналов, которая ограничивает размер файла журнала и выполняет циклический сдвиг журналов. Дополнительные сведения см. в разделе Сторонние поставщики ведения журналов.

Медленное или зависающее приложение (Служба приложений Azure)

Дополнительную информацию для случаев, когда приложение медленно реагирует или зависает при запросе, см. в разделе Устранение проблем с медленными веб-приложениями в службе приложений Azure.

Мониторинг колонок

Мониторинг колонок обеспечивает альтернативный поиск неисправностей методам, описанным ранее в этом разделе. Эти колонки можно использовать для диагностики ошибок 500-й серии.

Убедитесь, что установлены расширения ASP.NET Core. Если расширения не установлены, установите их вручную, выполнив следующие действия.

1. В колонке Средства разработки выберите колонку Расширения.
2. В списке должны появиться Расширения ASP.NET Core.
3. Если расширения не установлены, нажмите кнопку Добавить.
4. Выберите из списка Расширения ASP.NET Core.
5. Для принятия условий нажмите кнопку ОК.
6. Нажмите кнопку ОК в колонке Добавить расширение.
7. Информационное всплывающее сообщение указывает, когда расширения успешно установятся.

Если ведение журнала stdout не включено, выполните следующие действия.

1. На портале Azure выберите колонку Дополнительные инструменты в области Средства разработки. Нажмите кнопку Перейти→. Консоль Kudu открывается в новой вкладке или в окне браузера.
2. С помощью панели навигации в верхней части страницы откройте Консоль отладки и выберите CMD.
3. Откройте папки на пути веб-сайт>wwwroot и прокрутите список вниз, пока в нижней части не покажется файл web.config.
4. Щелкните значок карандаша рядом с файлом web.config.
5. Установите для параметра stdoutLogEnabled значение true и измените путь stdoutLogFile на \\?\%home%\LogFiles\stdout.
6. Выберите Сохранить для сохранения обновленного файла web.config.

Перейдите к активации ведения журнала диагностики, выполнив следующие действия.

1. На портале Azure выберите колонку Журналы диагностики.
2. Выберите положение переключателя Вкл. для Вход в приложения (файловая система) и Подробные сообщения об ошибках. В верхней части колонки нажмите кнопку Сохранить.
3. Чтобы включить трассировку неудачно завершенных запросов, также известную как ведение журнала буферизации событий неудачных запросов (FREB), установите положение переключателя Вкл. для Трассировки неудачно завершенных запросов.
4. На портале выберите колонку Поток журнала, которая в списке отображается сразу под колонкой Журналы диагностики.
5. Сделайте запрос к приложению.
6. В пределах данных потока журнала указывается причина ошибки.

После завершения устранения неполадок обязательно отключите ведение журнала stdout.

Чтобы просмотреть журналы трассировки неудачно завершенных запросов (журналы FREB), выполните следующие действия.

1. Перейдите к колонке Диагностика и решение проблем на портале Azure.
2. Выберите Журналы трассировки неудачно завершенных запросов из области боковой панели Средства поддержки.

Для получения дополнительной информации см. Раздел "Трассировка неудачно завершенных запросов" раздела "Включение ведения журналов диагностики для веб-приложений в службе приложений Azure" и Вопросы и ответы о производительности приложений для веб-приложений в Azure: как включить трассировку неудачно завершенных запросов?.

Дополнительные сведения см. в разделе Включение функции ведения журналов диагностики для веб-приложений в службе приложений Azure.

Предупреждение

Ошибка при отключении журнала stdout может привести к сбоям приложения или сервера. Ни размер файла журнала, ни количество создаваемых файлов журналов ничем не ограничены.

Для обычного входа в приложение ASP.NET Core используйте библиотеку ведения журналов, которая ограничивает размер файла журнала и выполняет циклический сдвиг журналов. Дополнительные сведения см. в разделе Сторонние поставщики ведения журналов.

Устранение неполадок в IIS

Журнал событий приложений (IIS)

Доступ к журналу событий приложений

1. Откройте меню "Пуск", выполните поиск по фразе Просмотр событий и выберите приложение Просмотр событий.
2. В средстве просмотра событий откройте узел Журналы Windows.
3. Выберите Приложение, чтобы открыть журнал событий приложения.
4. Проверьте здесь наличие ошибок, связанных с проблемным приложением. Нам нужны ошибки со значениями Модуль IIS AspNetCore или Модуль IIS Express AspNetCore в столбце Источник.

Запуск приложения в командной строке

Многие ошибки запуска не создают полезные сведения в журнале событий приложения. Для некоторых ошибок можно найти причину, запустив приложение в командной строке на компьютере размещения.

Развертывание, зависящее от платформы

Если развертываемое приложение зависит от платформы, сделайте следующее:

1. В командной строке перейдите в папку развертывания и запустите приложение, выполнив команду dotnet.exe для сборки приложения. В следующей команде укажите нужное имя сборки приложения вместо заполнителя <assembly_name>: dotnet .\<assembly_name>.dll.
2. Выходные данные приложения, в том числе любые ошибки, будут выведены в окно консоли.
3. Если ошибки возникают при выполнении запроса к приложению, выполните запрос к узлу и порту, где Kestrel ожидает передачи данных. Создайте запрос к http://localhost:5000/, используя узел и порт по умолчанию. Если приложение отвечает на запросы по адресу конечной точки Kestrel как обычно, проблема, скорее всего, связана с конфигурацией размещения, а не с самим приложением.

Автономное развертывание

Если приложение развертывается автономно, сделайте следующее:

1. В командной строке перейдите в папку развертывания и запустите исполняемый файл приложения. В следующей команде укажите нужное имя сборки приложения вместо заполнителя <assembly_name>: <assembly_name>.exe.
2. Выходные данные приложения, в том числе любые ошибки, будут выведены в окно консоли.
3. Если ошибки возникают при выполнении запроса к приложению, выполните запрос к узлу и порту, где Kestrel ожидает передачи данных. Создайте запрос к http://localhost:5000/, используя узел и порт по умолчанию. Если приложение отвечает на запросы по адресу конечной точки Kestrel как обычно, проблема, скорее всего, связана с конфигурацией размещения, а не с самим приложением.

Журнал вывода stdout модуля ASP.NET Core (IIS)

Чтобы включить и просмотреть журналы stdout выполните следующие действия.

1. Перейдите в папку развертывания сайта на компьютере размещения.
2. Если здесь нет папки logs, создайте ее. Сведения о том, как настроить в MSBuild автоматическое создание папки logs в развертывании, см. в статье о структуре каталогов.
3. Измените файл web.config. Задайте для параметра stdoutLogEnabled значение true и измените путь stdoutLogFile так, чтобы он указывал на папку logs (например, .\logs\stdout). В этом пути stdout обозначает префикс имени для файла журнала. При создании файла журнала автоматически добавляются метка времени, идентификатор процесса и расширение файла. Если указан префикс файла stdout, стандартный файл журнала будет иметь примерно такое имя: stdout_20180205184032_5412.log.
4. Убедитесь, что удостоверение пула приложений имеет разрешения на запись в папку logs.
5. Сохраните обновленный файл web.config.
6. Сделайте запрос к приложению.
7. Перейдите в папку logs. Найдите и откройте последний журнал вывода stdout.
8. Проверьте, нет ли в нем ошибок.

Завершив устранение неполадок, отключите ведение журнала stdout.

1. Измените файл web.config.
2. Задайте параметру stdoutLogEnabled значение false.
3. Сохраните файл.

Дополнительные сведения см. в разделе Модуль ASP.NET Core для IIS.

Предупреждение

Ошибка при отключении журнала stdout может привести к сбоям приложения или сервера. Ни размер файла журнала, ни количество создаваемых файлов журналов ничем не ограничены.

Для обычного входа в приложение ASP.NET Core используйте библиотеку ведения журналов, которая ограничивает размер файла журнала и выполняет циклический сдвиг журналов. Дополнительные сведения см. в разделе Сторонние поставщики ведения журналов.

Журнал отладки модуля ASP.NET Core (IIS)

Добавьте следующие параметры обработчика в файл web.config приложения, чтобы включить журнал отладки модулей ASP.NET Core:

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

Убедитесь, что указанный для журнала путь существует и удостоверение пула приложений имеет разрешения на запись в это расположение.

Дополнительные сведения см. в статье Создание и перенаправление журнала с помощью модуля ASP.NET Core.

Включение страницы исключений для разработчика

Можно добавить переменную среды ASPNETCORE_ENVIRONMENTв файл web.config, чтобы запустить приложение в среде разработки. Если среда не переопределяется при запуске приложения использованием UseEnvironment в конструкторе узла, эта переменная среды позволяет отображать страницу исключения для разработчика при запуске приложения.

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

Настройка переменной среды ASPNETCORE_ENVIRONMENT рекомендуется только на промежуточных и тестовых серверах, доступ к которым из Интернета закрыт. Завершив устранение неполадок, удалите эту переменную среды из файла web.config. Сведения о настройке переменных среды в файле web.config см. в статье о дочернем элементе environmentVariables в aspNetCore.

Получение данных из приложения

Если приложение способно отвечать на запросы, получите данные о запросе, подключении и дополнительные данные из приложений с помощью встроенного терминала ПО промежуточного слоя. Дополнительные сведения и примеры кода см. в статье Устранение неполадок и отладка проектов ASP.NET Core.

Медленное или зависающее приложение (IIS)

Аварийный дамп — это моментальный снимок системной памяти, который может помочь определить причину аварийного завершения, сбоя запуска или медленной работы приложения.

Аварийное завершение работы приложения или исключение

Получите и проанализируйте дамп из отчетов об ошибках Windows (WER):

1. Создайте папку для хранения файлов аварийного дампа в c:\dumps. Пул приложений должен иметь доступ на запись к папке.

2. Запустите скрипт PowerShell EnableDumps:

   • Если приложение использует модель размещения в процессе, выполните скрипт для w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • Если приложение использует модель размещения вне процесса, выполните скрипт для dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Запустите приложение в условиях, вызывающих аварийное завершение.

4. После аварийного завершения запустите скрипт PowerShell DisableDumps:

   • Если приложение использует модель размещения в процессе, выполните скрипт для w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • Если приложение использует модель размещения вне процесса, выполните скрипт для dotnet.exe:

     .\DisableDumps dotnet.exe
     

Когда приложение аварийно завершит работу и сбор дампов будет выполнен, приложение сможет завершить работу обычным образом. Скрипт PowerShell настраивает отчеты об ошибках Windows для сбора до пяти дампов для приложения.

Предупреждение

Аварийные дампы могут занимать много места на диске (до нескольких гигабайтов каждый).

Приложение перестает отвечать на запросы, не запускается или работает в обычном режиме

Когда приложение зависает (перестает отвечать на запросы, но не завершает работу), завершается сбоем во время запуска или выполняется нормально, см . статью "Файлы дампа в режиме пользователя": выбор оптимального инструмента для выбора соответствующего инструмента для создания дампа.

Анализ дампа

Дамп можно проанализировать несколькими способами. Дополнительные сведения см. в разделе Анализ файла дампа пользовательского режима.

Очистка кэшей пакетов

Приложения-функции могут перестать работать сразу после обновления пакета SDK для .NET Core на компьютере разработки или обновления версии пакетов в самом приложении. В некоторых случаях в результате важного обновления несогласованные версии пакетов могут привести к нарушению работы приложения. Большинство этих проблем можно исправить следующим образом:

1. Удалите папки bin и obj.

2. Очистите кэши пакетов, выполнив команду dotnet nuget locals all --clear из командной оболочки.

   Очистку кэшей пакетов также можно выполнить с помощью средства nuget.exe или команды nuget locals all -clear. NuGet.exe не входит в пакет установки операционной системы Windows для настольных компьютеров и его нужно получить отдельно на веб-сайте NuGet.

3. Восстановите и перестройте проект.

4. Удалите все файлы из папки развертывания на сервере, прежде чем повторно развернуть приложение.

Дополнительные ресурсы

• Отладка исходного кода .NET и ASP.NET Core с помощью Visual Studio
• Устранение неполадок и отладка проектов ASP.NET Core
• Устранение распространенных неполадок в Службе приложений Azure и службах IIS с помощью ASP.NET Core
• Обработка ошибок в ASP.NET Core
• модуль ASP.NET Core (ANCM) для IIS

Документация по Azure

• Application Insights для ASP.NET Core
• Раздел "Веб-приложения удаленной отладки" статьи "Устранение неполадок веб-приложения в Службе приложений Azure с помощью Visual Studio"
• Общие сведения о диагностике в службе приложений Azure
• Мониторинг приложений в службе приложений Azure
• Устранение неполадок веб-приложения в службе приложений Azure с помощью Visual Studio
• Устранение ошибок HTTP "502 — недопустимый шлюз" и "503 — служба недоступна" в веб-приложениях Azure
• Устранение проблем с производительностью медленных веб приложений в службе приложений Azure
• Вопросы и ответы о производительности приложений для веб-приложений в Azure
• "Песочница" веб-приложений Azure (ограничения работы среды выполнения службы приложений)

Документация по Visual Studio

• Удаленная отладка ASP.NET Core в IIS в Azure в Visual Studio 2017
• Удаленная отладка ASP.NET Core на удаленном компьютере IIS в Visual Studio 2017
• Сведения об отладке с помощью Visual Studio

Документация по Visual Studio Code

• Отладка с помощью Visual Studio Code