Solucionar problemas do ASP.NET Core no Serviço de Aplicativo do Azure e no IIS

Este artigo fornece informações sobre erros comuns de inicialização do aplicativo e instruções sobre como diagnosticar erros quando um aplicativo é implantado para Serviço de Aplicativo do Azure ou IIS:

Erros de inicialização do aplicativo
Explica cenários comuns de código de status HTTP de inicialização.

Solucionar problemas no Serviço de Aplicativo do Azure
Fornece conselhos sobre solução de problemas para aplicativos implantados no Serviço de Aplicativo do Azure.

Solução de problemas no IIS
Fornece conselhos para solução de problemas para aplicativos implantados no IIS ou em execução no IIS Express localmente. As diretrizes se aplicam a implantações do Windows Server e da área de trabalho do Windows.

Limpar caches de pacote
Explica o que fazer quando pacotes incoerentes interrompem um aplicativo ao executar atualizações principais ou alterar as versões do pacote.

Recursos adicionais
Lista tópicos adicionais de solução de problemas.

Erros de inicialização do aplicativo

No Visual Studio, o servidor padrão do projeto do ASP.NET Core é Kestrel. O Visual Studio pode ser configurado para usar o IIS Express. Uma 502.5 – falha de processo ou uma 500.30 – falha de inicialização que ocorre ao depurar localmente com o IIS Express pode ser solucionada usando as recomendações presentes neste tópico.

403.14 Proibido

O aplicativo falha ao iniciar. O seguinte erro é registrado em log:

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

O erro geralmente é causado por uma implantação interrompida no sistema de hospedagem, que inclui qualquer um dos seguintes cenários:

• O aplicativo é implantado na pasta errada no sistema de hospedagem.
• O processo de implantação não conseguiu mover todos os arquivos e pastas do aplicativo para a pasta de implantação no sistema de hospedagem.
• O arquivo web.config está ausente da implantação ou o conteúdo do arquivo web.config está malformado.

Execute as seguintes etapas:

1. Exclua todos os arquivos e pastas da pasta de implantação no sistema de hospedagem.
2. Reimplante o conteúdo da pasta Publicar do aplicativo no sistema de hospedagem usando seu método normal de implantação, como Visual Studio, PowerShell ou implantação manual:
   • Confirme se o arquivo web.config está presente na implantação e se o conteúdo está correto.
   • Ao hospedar no Serviço de Aplicativo do Azure, confirme se o aplicativo está implantado na pasta D:\home\site\wwwroot.
   • Quando o aplicativo é hospedado pelo IIS, confirme se o aplicativo está implantado no Caminho físico do IIS mostrado nas Configurações Básicas do Gerenciador do IIS.
3. Confirme se todos os arquivos e pastas do aplicativo são implantados comparando a implantação no sistema de hospedagem com o conteúdo da pasta Publicar do projeto.

Para obter mais informações sobre o layout de um aplicativo publicado do ASP.NET Core, confira Estrutura de diretório do ASP.NET Core. Para obter mais informações sobre o arquivo web.config, confira Módulo do ASP.NET Core (ANCM) para o IIS.

Erro interno de servidor 500

O aplicativo é iniciado, mas um erro impede o servidor de atender à solicitação.

Esse erro ocorre no código do aplicativo durante a inicialização ou durante a criação de uma resposta. A resposta poderá não conter nenhum conteúdo, ou a resposta poderá ser exibida como um 500 – Erro Interno do Servidor no navegador. O Log de Eventos do Aplicativo geralmente indica que o aplicativo iniciou normalmente. Da perspectiva do servidor, isso está correto. O aplicativo foi iniciado, mas não é capaz de gerar uma resposta válida. Execute o aplicativo em um prompt de comando no servidor ou habilite o log de stdout do Módulo do ASP.NET Core para solucionar o problema.

Esse erro também pode ocorrer quando o Pacote de Hospedagem do .NET Core não está instalado ou está corrompido. A instalação ou o reparo da instalação do Pacote de Hospedagem do .NET Core (para IIS) ou do Visual Studio (para o IIS Express) pode corrigir o problema.

500.0 Falha de carregamento de manipulador em processo

O processo de trabalho falha. O aplicativo não foi iniciado.

Erro desconhecido ao carregar os componentes do Módulo do ASP.NET Core. Execute uma das seguintes ações:

• Entre em contato com o Suporte da Microsoft (selecione Ferramentas para Desenvolvedores e, em seguida, ASP.NET Core).
• Faça uma pergunta no Stack Overflow.
• Registre um problema no nosso Repositório do GitHub.

500.30 Falha de inicialização em processo

O processo de trabalho falha. O aplicativo não foi iniciado.

O Módulo do ASP.NET Core tenta iniciar o CLR do .NET Core em processo, mas falha ao iniciar. A causa de uma falha de inicialização do processo geralmente pode ser determinada com base em entradas no Log de Eventos do Aplicativo e no log de stdout do Módulo do ASP.NET Core.

Condições comuns de falha:

• O aplicativo é configurado incorretamente, direcionado a uma versão da estrutura compartilhada do ASP.NET Core que não está presente. Verifique quais versões da estrutura compartilhada do ASP.NET Core estão instaladas no computador de destino.
• Usando o Azure Key Vault, falta de permissões para o Key Vault. Verifique as políticas de acesso no Key Vault de destino para garantir que as permissões corretas sejam concedidas.

500.31 O ANCM não pôde encontrar dependências nativas

O processo de trabalho falha. O aplicativo não foi iniciado.

O Módulo do ASP.NET Core tenta iniciar o runtime do .NET Core em processo, mas não pode ser iniciado. A causa mais comum dessa falha de inicialização é quando o runtime Microsoft.NETCore.App ou Microsoft.AspNetCore.App não está instalado. Se o aplicativo for implantado no ASP.NET Core 3.0 de destino e essa versão não existir no computador, esse erro ocorrerá. Segue um exemplo de mensagem de erro:

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]

A mensagem de erro lista todas as versões instaladas do .NET Core e a versão solicitada pelo aplicativo. Para corrigir esse erro:

• Instale a versão adequada do .NET Core no computador.
• Altere o aplicativo para uma versão do .NET Core que está presente no computador de destino.
• Publique o aplicativo como uma implantação autossuficiente.

Durante a execução no desenvolvimento (quando a variável de ambiente ASPNETCORE_ENVIRONMENT está definida como Development), o erro específico é gravado na resposta HTTP. A causa de uma falha de inicialização do processo também é encontrada no Log de Eventos do Aplicativo.

500.32 O ANCM não pôde carregar o dll

O processo de trabalho falha. O aplicativo não foi iniciado.

A causa mais comum para esse erro é que o aplicativo foi publicado para uma arquitetura de processador incompatível. Esse erro ocorrerá se o processo de trabalho estiver em execução como um aplicativo de 32 bits e o aplicativo tiver sido publicado para o destino de 64 bits.

Para corrigir esse erro:

• Republique o aplicativo para a mesma arquitetura de processador que o processo de trabalho.
• Publique o aplicativo como uma implantação dependente da estrutura.

500.33 O ANCM não pôde carregar o manipulador de solicitação

O processo de trabalho falha. O aplicativo não foi iniciado.

O aplicativo não referenciou a estrutura Microsoft.AspNetCore.App. Somente os aplicativos destinados à estrutura Microsoft.AspNetCore.App podem ser hospedados pelo Módulo do ASP.NET Core.

Para corrigir esse erro, confirme se o aplicativo está direcionado para a estrutura Microsoft.AspNetCore.App. Confira o .runtimeconfig.json para verificar a estrutura de destino do aplicativo.

500.34 Não há suporte para modelos de hospedagem mistos do ANCM

O processo de trabalho não pode executar um aplicativo em processo e um aplicativo fora do processo no mesmo processo.

Para corrigir esse erro, execute aplicativos em pools de aplicativos do IIS separados.

500.35 Vários aplicativos do ANCM em processo no mesmo processo

O processo de trabalho não pode executar vários aplicativos em processo no mesmo processo.

Para corrigir esse erro, execute aplicativos em pools de aplicativos do IIS separados.

500.36 Falha ao carregar o manipulador de fora do processo do ANCM

O manipulador de solicitação de fora do processo aspnetcorev2_outofprocess.dll não está próximo do arquivo aspnetcorev2.dll. Isso indica uma instalação corrompida do Módulo do ASP.NET Core.

Para corrigir esse erro, repare a instalação do Pacote de Hospedagem do .NET Core (para IIS) ou do Visual Studio (para o IIS Express).

500.37 O ANCM não pôde ser iniciado dentro do limite de tempo de inicialização

O ANCM não pôde ser iniciado dentro do limite de tempo de inicialização fornecido. Por padrão, o tempo limite é de 120 segundos.

Esse erro pode ocorrer ao iniciar um grande número de aplicativos no mesmo computador. Verifique se há picos de uso de CPU/memória no servidor durante a inicialização. Talvez você precise balancear o processo de inicialização de vários aplicativos.

500.38 DLL de aplicativo ANCM não encontrada

Falha do ANCM ao localizar a DLL do aplicativo, que deve estar ao lado do arquivo executável.

Esse erro ocorre ao hospedar um aplicativo empacotado como um executável de arquivo único usando o modelo de hospedagem em processo. O modelo em processo requer que o ANCM carregue o aplicativo .NET Core no processo do IIS existente. Não há suporte para esse cenário no modelo de implantação de arquivo único. Use uma das seguintes abordagens no arquivo de projeto do aplicativo para corrigir esse erro:

1. Desabilite a publicação de arquivo único definindo a propriedade PublishSingleFile do MSBuild como false.
2. Alterne para o modelo de hospedagem fora do processo definindo a propriedade AspNetCoreHostingModel do MSBuild como OutOfProcess.

Falha de processo 502.5

O processo de trabalho falha. O aplicativo não foi iniciado.

O Módulo do ASP.NET Core tenta iniciar o processo de trabalho, mas falhar ao iniciar. A causa de uma falha de inicialização do processo geralmente pode ser determinada com base em entradas no Log de Eventos do Aplicativo e no log de stdout do Módulo do ASP.NET Core.

Uma condição de falha comum é o aplicativo configurado incorretamente, direcionado a uma versão da estrutura compartilhada do ASP.NET Core que não está presente. Verifique quais versões da estrutura compartilhada do ASP.NET Core estão instaladas no computador de destino. A estrutura compartilhada é o conjunto de assemblies (arquivos . dll) instalado no computador e referenciado por um metapacote como Microsoft.AspNetCore.App. A referência do metapacote pode especificar a versão mínima necessária. Saiba mais em A estrutura compartilhada.

A página do erro 502.5 – Falha no Processo é retornada quando um erro de configuração de hospedagem ou do aplicativo faz com que o processo de trabalho falhe:

Falha ao iniciar o aplicativo (ErrorCode '0x800700c1')

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

O aplicativo falhou ao ser iniciado porque o assembly do aplicativo (.dll) não pôde ser carregado.

Esse erro ocorre quando há uma incompatibilidade de número de bits entre o aplicativo publicado e o processo w3wp/iisexpress.

Confirme se a configuração de 32 bits do pool de aplicativos está correta:

1. Selecione o pool de aplicativos no Pools de Aplicativos do Gerenciador do IIS.
2. Selecione Configurações Avançadas em Editar Pool de Aplicativos no painel Ações.
3. Defina Habilitar Aplicativos de 32 bits:
   • Se estiver implantando um aplicativo de 32 bits (x86), defina o valor como True.
   • Se estiver implantando um aplicativo de 64 bits (x64), defina o valor como False.

Confirme se não há um conflito entre uma propriedade <Platform> do MSBuild no arquivo de projeto e o número de bit publicado do aplicativo.

Falha ao iniciar o aplicativo (ErrorCode '0x800701b1')

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

O aplicativo não pôde ser iniciado porque um serviço do Windows não pôde ser carregado.

Um serviço comum que precisa ser habilitado é o serviço "nulo". O comando a seguir habilita o null Serviço do Windows:

sc.exe start null

Redefinição de conexão

Se um erro ocorrer após os cabeçalhos serem enviados, será tarde demais para o servidor enviar um 500 – Erro Interno do Servidor no caso de um erro ocorrer. Isso geralmente acontece quando ocorre um erro durante a serialização de objetos complexos para uma resposta. Esse tipo de erro é exibida como um erro de redefinição de conexão no cliente. O Log de aplicativo pode ajudar a solucionar esses tipos de erros.

Limites de inicialização padrão

O Módulo do ASP.NET Core está configurado com um startupTimeLimit padrão de 120 segundos. Quando deixado no valor padrão, um aplicativo pode levar até dois minutos para iniciar antes que uma falha do processo seja registrada em log pelo módulo. Para obter informações sobre como configurar o módulo, veja Atributos do elemento aspNetCore.

Solucionar problemas no Serviço de Aplicativo do Azure

Importante

Versões prévias do ASP.NET Core com o Serviço de Aplicativo do Azure

Versões prévias do ASP.NET Core não são implantadas para o Serviço de Aplicativo do Azure por padrão. Para hospedar um aplicativo que usa uma versão prévia do ASP.NET Core, veja Implantar versão prévia do ASP.NET Core para o Serviço de Aplicativo do Azure.

Fluxo de log do Serviço de Aplicativo do Azure

O log do Serviço de Aplicativo do Azure transmite informações de log conforme elas ocorrem. Para exibir os logs de streaming:

1. No portal do Azure, abra o aplicativo nos Serviços de Aplicativos.
2. No painel esquerdo, navegue até Monitoramento>Logs do Serviço de Aplicativo.
3. Selecione Sistema de Arquivos para Registro em Log do Servidor Web. Opcionalmente, habilite o Registro em log do aplicativo.
4. No painel esquerdo, navegue até Monitoramento>Fluxo de log e, em seguida, selecione Logs do aplicativo ou Logs do Servidor Web.

As seguintes imagens mostram a saída dos logs do aplicativo:

Os logs de streaming têm alguma latência e podem não ser exibidos imediatamente.

Log de Eventos do Aplicativo (Serviço de Aplicativo do Azure)

Para acessar o Log de Eventos do Aplicativo, use a folha Diagnosticar e solucionar problemas no portal do Azure:

1. No portal do Azure, abra o aplicativo nos Serviços de Aplicativos.
2. Selecione Diagnosticar e solucionar problemas.
3. Selecione o título Ferramentas de Diagnóstico.
4. Em Ferramentas de Suporte, selecione o botão Eventos do Aplicativo.
5. Examine o erro mais recente fornecido pela entrada IIS AspNetCoreModule ou IIS AspNetCoreModule V2 na coluna Origem.

Uma alternativa ao uso da folha Diagnosticar e resolver problemas é examinar o arquivo de Log de Eventos do Aplicativo diretamente usando o Kudu:

1. Abra Ferramentas Avançadas na área Ferramentas de Desenvolvimento. Selecione o botão Go→. O console do Kudu é aberto em uma nova janela ou guia do navegador.
2. Usando a barra de navegação na parte superior da página, abra Console de depuração e selecione CMD.
3. Abra a pasta LogFiles .
4. Selecione o ícone de lápis ao lado do arquivo eventlog.xml.
5. Examine o log. Role até o final do log para ver os eventos mais recentes.

Execute o aplicativo no console do Kudu

Muitos erros de inicialização não produzem informações úteis no Log de Eventos do Aplicativo. Você pode executar o aplicativo no Console de Execução Remota do Kudu para descobrir o erro:

1. Abra Ferramentas Avançadas na área Ferramentas de Desenvolvimento. Selecione o botão Go→. O console do Kudu é aberto em uma nova janela ou guia do navegador.
2. Usando a barra de navegação na parte superior da página, abra Console de depuração e selecione CMD.

Testar um aplicativo de 32 bits (x86)

Versão atual

1. cd d:\home\site\wwwroot
2. Execute o aplicativo:

   • Se o aplicativo é uma implantação dependente de estrutura:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Se o aplicativo é uma implantação autossuficiente:

     {ASSEMBLY NAME}.exe
     

A saída do console do aplicativo, mostrando todos os erros, é canalizada para o console do Kudu.

Implantação dependente da estrutura em execução em uma versão de visualização

Requer a instalação da extensão de site de runtime do ASP.NET Core {VERSION} (x86).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} é a versão de runtime)
2. Execute o aplicativo: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

A saída do console do aplicativo, mostrando todos os erros, é canalizada para o console do Kudu.

Testar um aplicativo de 64 bits (x64)

Versão atual

• Se o aplicativo for uma implantação dependente de estrutura de 64 bits (x64):
  1. cd D:\Program Files\dotnet
  2. Execute o aplicativo: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Se o aplicativo é uma implantação autossuficiente:
  1. cd D:\home\site\wwwroot
  2. Execute o aplicativo: {ASSEMBLY NAME}.exe

A saída do console do aplicativo, mostrando todos os erros, é canalizada para o console do Kudu.

Implantação dependente da estrutura em execução em uma versão de visualização

Requer a instalação da extensão de site de runtime do ASP.NET Core {VERSION} (x64).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} é a versão de runtime)
2. Execute o aplicativo: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

A saída do console do aplicativo, mostrando todos os erros, é canalizada para o console do Kudu.

Log de stdout do Módulo do ASP.NET Core (Serviço de Aplicativo do Azure)

Aviso

Falha ao desabilitar o log de stdout pode levar a falhas de aplicativo ou de servidor. Não há limites para o tamanho do arquivo de log ou para o número de arquivos de log criados. Somente use o log de stdout para solucionar problemas de inicialização de aplicativo.

Para registro em log geral em um aplicativo ASP.NET Core após a inicialização, use uma biblioteca de registro em log que limita o tamanho do arquivo de log e realiza a rotação de logs. Para obter mais informações, veja provedores de log de terceiros.

O log de stdout do Módulo do ASP.NET Core geralmente registra mensagens de erro úteis não encontradas no Log de Eventos do Aplicativo. Para habilitar e exibir logs de stdout:

1. No portal do Azure, navegue até o aplicativo Web.
2. Na folha Serviço de Aplicativo, insira kudu na caixa de pesquisa.
3. Selecione Ferramentas Avançadas>Acessar.
4. Selecione Console de Depuração > CMD.
5. Acesse site/wwwroot
6. Selecione o ícone de lápis para editar o arquivo web.config.
7. No elemento <aspNetCore />, defina stdoutLogEnabled="true" e selecione Salvar.

Desabilite o registro em log de stdout quando a solução de problemas for concluída definindo stdoutLogEnabled="false".

Para obter mais informações, confira Módulo do ASP.NET Core (ANCM) para o IIS.

Log de depuração do Módulo do ASP.NET Core (Serviço de Aplicativo do Azure)

O log de depuração do Módulo do ASP.NET Core fornece registro em log adicional e mais profundo do Módulo do ASP.NET Core. Para habilitar e exibir logs de stdout:

1. Para habilitar o log de diagnóstico avançado, execute um destes procedimentos:
   • Siga as instruções em Logs de diagnóstico avançados para configurar o aplicativo para um log de diagnósticos avançado. Reimplante o aplicativo.
   • Adicione a <handlerSettings> mostrada em Logs de diagnóstico avançados para o arquivo web.config do aplicativo ao vivo usando o console do Kudu:
     1. Abra Ferramentas Avançadas na área Ferramentas de Desenvolvimento. Selecione o botão Go→. O console do Kudu é aberto em uma nova janela ou guia do navegador.
     2. Usando a barra de navegação na parte superior da página, abra Console de depuração e selecione CMD.
     3. Abra as pastas no caminho site>wwwroot. Edite o arquivo web.config selecionando o botão de lápis. Adicione a seção <handlerSettings> conforme mostrado em Logs de diagnóstico avançados. Selecione o botão Salvar.
2. Abra Ferramentas Avançadas na área Ferramentas de Desenvolvimento. Selecione o botão Go→. O console do Kudu é aberto em uma nova janela ou guia do navegador.
3. Usando a barra de navegação na parte superior da página, abra Console de depuração e selecione CMD.
4. Abra as pastas no caminho site>wwwroot. Se você não fornecer um caminho para o arquivo aspnetcore-debug.log, o arquivo aparecerá na lista. Se você tiver fornecido um caminho, navegue até o local do arquivo de log.
5. Abra o arquivo de log com o botão de lápis ao lado do nome do arquivo.

Desabilite o registro em log de depuração quando a solução de problemas for concluída:

Para desabilitar o log de depuração avançado, execute um destes procedimentos:

• Remova o <handlerSettings> do arquivo web.config localmente e reimplante o aplicativo.
• Use o console do Kudu para editar o arquivo web.config e remover a seção <handlerSettings>. Salve o arquivo.

Para obter mais informações, consulte Criação e redirecionamento de log com o módulo do ASP.NET Core.

Aviso

A falha ao desabilitar o log de depuração pode levar a falhas de aplicativo ou de servidor. Não há nenhum limite no tamanho do arquivo de log. Somente use o log de depuração para solucionar problemas de inicialização de aplicativo.

Para registro em log geral em um aplicativo ASP.NET Core após a inicialização, use uma biblioteca de registro em log que limita o tamanho do arquivo de log e realiza a rotação de logs. Para obter mais informações, veja provedores de log de terceiros.

Aplicativo lento ou sem resposta (Serviço de Aplicativo do Azure)

Quando um aplicativo responder lentamente ou não responder em uma solicitação, confira Solucionar problemas de desempenho de aplicativo Web lento no Serviço de Aplicativo do Azure.

Folhas de monitoramento

As folhas de monitoramento fornecem uma experiência alternativa de solução de problemas para os métodos descritos anteriormente no tópico. Essas folhas podem ser usadas para diagnosticar erros da série 500.

Verifique se as Extensões do ASP.NET Core estão instaladas. Se as extensões não estiverem instaladas, instale-as manualmente:

1. Na seção de folha FERRAMENTAS DE DESENVOLVIMENTO, selecione a folha Extensões.
2. As Extensões do ASP.NET Core devem aparecer na lista.
3. Se as extensões não estiverem instaladas, selecione o botão Adicionar.
4. Escolha as Extensões do ASP.NET Core da lista.
5. Selecione OK para aceitar os termos legais.
6. Selecione OK na folha Adicionar extensão.
7. Uma mensagem pop-up informativa indica quando as extensões são instaladas com êxito.

Se o registro em log de stdout não estiver habilitado, siga estas etapas:

1. No portal do Azure, selecione a folha Ferramentas Avançadas na área FERRAMENTAS DE DESENVOLVIMENTO. Selecione o botão Go→. O console do Kudu é aberto em uma nova janela ou guia do navegador.
2. Usando a barra de navegação na parte superior da página, abra Console de depuração e selecione CMD.
3. Abra as pastas no caminho site>wwwroot e role para baixo para revelar o arquivo web.config na parte inferior da lista.
4. Clique no ícone de lápis ao lado do arquivo web.config.
5. Defina stdoutLogEnabled para true e altere o caminho stdoutLogFile para \\?\%home%\LogFiles\stdout.
6. Selecione Salvar para salvar o arquivo web.config atualizado.

Prossiga para ativar o log de diagnóstico:

1. No portal do Azure, selecione a folha Logs de diagnóstico.
2. Selecione a opção Ligado para Log de Aplicativo (Sistema de arquivos) e Mensagens de erro detalhadas. Selecione o botão Salvar na parte superior da folha.
3. Para incluir o rastreamento de solicitação com falha, também conhecido como FREB (Buffer de Evento de Solicitação com Falha), selecione a opção Ligado para o Rastreamento de solicitação com falha.
4. Selecione a folha Fluxo de log, que é listada imediatamente sob a folha Logs de diagnóstico no portal.
5. Faça uma solicitação ao aplicativo.
6. Dentro dos dados de fluxo de log, a causa do erro é indicada.

Sempre desabilite o registro em log de stdout após concluir a solução de problemas.

Para exibir os logs de rastreamento de solicitação com falha (logs FREB):

1. Navegue até a folha Diagnosticar e resolver problemas no portal do Azure.
2. Selecione Logs de Rastreamento de Solicitação com Falha da área FERRAMENTAS DE SUPORTE da barra lateral.

Confira a seção de Rastreamentos de solicitação com falha no tópico Habilitar o log de diagnósticos para aplicativos Web no Serviço de Aplicativo do Azure e as Perguntas frequentes do desempenho do aplicativo para Aplicativos Web no Azure: como ativar o rastreamento de solicitação com falha? para obter mais informações.

Para obter mais informações, veja Habilitar log de diagnósticos para aplicativos Web no Serviço de Aplicativo do Azure.

Aviso

Falha ao desabilitar o log de stdout pode levar a falhas de aplicativo ou de servidor. Não há limites para o tamanho do arquivo de log ou para o número de arquivos de log criados.

Para registro em log de rotina em um aplicativo ASP.NET Core, use uma biblioteca de registro em log que limita o tamanho do arquivo de log e realiza a rotação de logs. Para obter mais informações, veja provedores de log de terceiros.

Solução de problemas no IIS

Log de Eventos do Aplicativo (IIS)

Acesse o Log de Eventos do Aplicativo:

1. Abra o menu Iniciar, procure Visualizador de Eventos e selecione o aplicativo Visualizador de Eventos.
2. No Visualizador de Eventos, abra o nó Logs do Windows.
3. Selecione Aplicativo para abrir o Log de Eventos do Aplicativo.
4. Procure erros associados ao aplicativo com falha. Os erros têm um valor Módulo AspNetCore do IIS ou Módulo AspNetCore do IIS Express na coluna Origem.

Execute o aplicativo em um prompt de comando

Muitos erros de inicialização não produzem informações úteis no Log de Eventos do Aplicativo. Você pode encontrar a causa de alguns erros ao executar o aplicativo em um prompt de comando no sistema de hospedagem.

Implantação dependente de estrutura

Se o aplicativo é uma implantação dependente de estrutura:

1. Em um prompt de comando, navegue até a pasta de implantação e execute o aplicativo, executando o assembly do aplicativo com dotnet.exe. No comando a seguir, substitua o nome do assembly do aplicativo por <assembly_name>: dotnet .\<assembly_name>.dll.
2. A saída do console do aplicativo, mostrando eventuais erros, é gravada na janela do console.
3. Se os erros ocorrerem ao fazer uma solicitação para o aplicativo, faça uma solicitação para o host e a porta em que o Kestrel escuta. Usando o host e a porta padrão, faça uma solicitação para http://localhost:5000/. Se o aplicativo responde normalmente no endereço do ponto de extremidade do Kestrel, a probabilidade de o problema estar relacionado à configuração de hospedagem é maior e, de estar relacionado ao aplicativo, menor.

Implantação autocontida

Se o aplicativo é uma implantação autossuficiente:

1. Em um prompt de comando, navegue até a pasta de implantação e execute o arquivo executável do aplicativo. No comando a seguir, substitua o nome do assembly do aplicativo por <assembly_name>: <assembly_name>.exe.
2. A saída do console do aplicativo, mostrando eventuais erros, é gravada na janela do console.
3. Se os erros ocorrerem ao fazer uma solicitação para o aplicativo, faça uma solicitação para o host e a porta em que o Kestrel escuta. Usando o host e a porta padrão, faça uma solicitação para http://localhost:5000/. Se o aplicativo responde normalmente no endereço do ponto de extremidade do Kestrel, a probabilidade de o problema estar relacionado à configuração de hospedagem é maior e, de estar relacionado ao aplicativo, menor.

Log de stdout do Módulo do ASP.NET Core (IIS)

Para habilitar e exibir logs de stdout:

1. Navegue até a pasta de implantação do site no sistema de hospedagem.
2. Se a pasta logs não estiver presente, crie-a. Para obter instruções sobre como habilitar o MSBuild para criar a pasta logs na implantação automaticamente, veja o tópico Estrutura de diretórios.
3. Edite o arquivo web.config. Defina stdoutLogEnabled para true e altere o caminho stdoutLogFile para apontar para a pasta logs (por exemplo, .\logs\stdout). stdout no caminho é o prefixo do nome do arquivo de log. Uma extensão de arquivo, uma ID do processo e um carimbo de data/hora são adicionados automaticamente quando o log é criado. Usando stdout como o prefixo do nome do arquivo, um arquivo de log típico é nomeado stdout_20180205184032_5412.log.
4. Verifique se a identity do pool de aplicativos tem permissões de gravação para a pasta logs.
5. Salve o arquivo web.config atualizado.
6. Faça uma solicitação ao aplicativo.
7. Navegue até a pasta logs. Localize e abra o log de stdout mais recente.
8. Estude o log em busca de erros.

Desabilite o registro em log de stdout quando a solução de problemas for concluída:

1. Edite o arquivo web.config.
2. Defina stdoutLogEnabled para false.
3. Salve o arquivo.

Para obter mais informações, confira Módulo do ASP.NET Core (ANCM) para o IIS.

Aviso

Falha ao desabilitar o log de stdout pode levar a falhas de aplicativo ou de servidor. Não há limites para o tamanho do arquivo de log ou para o número de arquivos de log criados.

Para registro em log de rotina em um aplicativo ASP.NET Core, use uma biblioteca de registro em log que limita o tamanho do arquivo de log e realiza a rotação de logs. Para obter mais informações, veja provedores de log de terceiros.

Log de depuração do Módulo do ASP.NET Core (IIS)

Adicione as seguintes configurações de manipulador ao arquivo web.config do aplicativo para habilitar o log de depuração do Módulo do ASP.NET Core:

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

Confirme se o caminho especificado para o log existe e se a identity do pool de aplicativos tem permissões de gravação no local.

Para obter mais informações, consulte Criação e redirecionamento de log com o módulo do ASP.NET Core.

Habilitar a página de exceção do desenvolvedor

A variável de ambiente ASPNETCORE_ENVIRONMENT pode ser adicionada ao web.config para executar o aplicativo no ambiente de desenvolvimento. Desde que o ambiente não seja substituído na inicialização do aplicativo por UseEnvironment no compilador do host, definir a variável de ambiente permite que a Página de Exceções do Desenvolvedor apareça quando o aplicativo é executado.

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

Configurar a variável de ambiente para ASPNETCORE_ENVIRONMENT só é recomendado para servidores de preparo e de teste que não estejam expostos à Internet. Remova a variável de ambiente do arquivo web.config após a solução de problemas. Para obter informações sobre como definir variáveis de ambiente no web.config, confira Elemento filho environmentVariables de aspNetCore.

Obter dados de um aplicativo

Se um aplicativo for capaz de responder às solicitações, obtenha as solicitações, conexão e dados adicionais do aplicativo que usar o middleware embutido de terminal. Para obter mais informações e código de exemplo, consulte Solucionar problemas e depurar projetos do ASP.NET Core.

Aplicativo lento ou sem resposta (IIS)

Um despejo de memória é um instantâneo da memória do sistema e pode ajudar a determinar a causa de uma falha de aplicativo, falha de inicialização ou lentidão de aplicativo.

O aplicativo falha ou encontra uma exceção

Obter e analisar um despejo de memória do WER (Relatório de Erros do Windows):

1. Crie uma pasta para armazenar os arquivos de despejo de memória em c:\dumps. O pool de aplicativos deve ter acesso para gravação à pasta.

2. Execute o script EnableDumps do PowerShell:

   • Se o aplicativo usa o modelo de hospedagem em processo, execute o script para w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • Se o aplicativo usa o modelo de hospedagem fora do processo, execute o script para dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Execute o aplicativo sob as condições que causam a falha.

4. Após a falha, execute o script DisableDumps do PowerShell:

   • Se o aplicativo usa o modelo de hospedagem em processo, execute o script para w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • Se o aplicativo usa o modelo de hospedagem fora do processo, execute o script para dotnet.exe:

     .\DisableDumps dotnet.exe
     

Depois que um aplicativo falhar e a coleta de despejo de memória for concluída, o aplicativo terá permissão para encerrar normalmente. O script do PowerShell configura o WER para coletar até cinco despejos de memória por aplicativo.

Aviso

Os despejos de memória podem usar uma grande quantidade de espaço em disco (até vários gigabytes cada).

O aplicativo não responde, falha durante a inicialização ou é executado normalmente

Quando um aplicativo parar de responder sem travar, falhar durante a inicialização ou executar normalmente, confira Arquivos de despejo do modo de usuário: escolha da melhor ferramenta para selecionar uma ferramenta adequada para produzir o despejo.

Analisar o despejo de memória

Um despejo de memória pode ser analisado usando várias abordagens. Para obter mais informações, confira Analisando um arquivo de despejo de memória do modo de usuário.

Limpar caches de pacote

Um aplicativo em funcionamento pode falhar imediatamente depois de atualizar o SDK do .NET Core no computador de desenvolvimento ou alterar as versões do pacote dentro do aplicativo. Em alguns casos, pacotes incoerentes podem interromper um aplicativo ao executar atualizações principais. A maioria desses problemas pode ser corrigida seguindo estas instruções:

1. Exclua as pastas bin e obj.

2. Limpe os caches de pacote executando dotnet nuget locals all --clear de um shell de comando.

   Também é possível limpar os caches de pacote com a ferramenta nuget.exe e executando o comando nuget locals all -clear. nuget.exe não é uma instalação fornecida com o sistema operacional Windows Desktop e devem ser obtidos separadamente do site do NuGet.

3. Restaure e recompile o projeto.

4. Exclua todos os arquivos na pasta de implantação no servidor antes de reimplantar o aplicativo.

Recursos adicionais

• Depurar o código-fonte .NET e ASP.NET Core com o Visual Studio
• Solucionar problemas e depurar projetos do ASP.NET Core
• Solucionar problemas com erros comuns no Serviço de Aplicativo do Azure e no IIS com o ASP.NET Core
• Tratar erros no ASP.NET Core
• Módulo do ASP.NET Core(ANCM) para IIS

Documentação do Azure

• Application Insights para ASP.NET Core
• Seção "Depuração remota de aplicativos Web" de "Solucionar problemas de um aplicativo Web no Serviço de Aplicativo do Azure usando o Visual Studio"
• Visão geral de diagnóstico do Serviço de Aplicativo do Azure
• Como monitorar aplicativos Web no Serviço de Aplicativo do Azure
• Solucionar problemas de um aplicativo Web no Serviço de Aplicativo do Azure usando o Visual Studio
• Solucionar problemas de erros HTTP de "502 Gateway Incorreto" e "503 Serviço Indisponível" em seus Aplicativos Web do Azure
• Solucionar problemas de desempenho de aplicativo Web lento no Serviço de Aplicativo do Azure
• Perguntas frequentes do desempenho do aplicativo para Aplicativos Web no Azure
• Área restrita do aplicativo Web do Azure (limitações de execução de runtime do Serviço de Aplicativo)

Documentação do Visual Studio

• Depuração Remota do ASP.NET Core no IIS no Azure no Visual Studio 2017
• Depuração remota do ASP.NET Core em um computador IIS remoto no Visual Studio 2017
• Aprenda a depurar usando o Visual Studio

Documentação do Visual Studio Code

• Depuração com o Visual Studio Code