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

De Justin Kotalik

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

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

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

Solução de problemas no IIS
Fornece conselhos de solução de problemas para aplicativos implantados no IIS ou em execução IIS Express localmente. As diretrizes se aplica a implantações Windows Server e Windows desktop.

Limpar caches de pacote
Explica o que fazer quando pacotes incoerentes quebram um aplicativo ao executar atualizações importantes ou alterar versões de pacote.

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

Erros de inicialização do aplicativo

No Visual Studio, um projeto ASP.NET Core padrão é IIS Express hospedagem durante a depuração. Uma 502.5 – Falha no processo ou uma 500,30 – Falha de início que ocorre quando a depuração local pode ser diagnosticada usando os conselhos neste tópico.

403.14 Proibido

Falha ao iniciar o aplicativo. O seguinte erro é registrado:

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 web.config está ausente da implantação ou o web.config arquivo 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 publish do aplicativo no sistema de hospedagem usando seu método normal de implantação, como Visual Studio, PowerShell ou implantação manual:
    • Confirme se oweb.config está presente na implantação e se seu conteúdo está correto.
    • Ao hospedar na Serviço de Aplicativo do Azure, confirme se o aplicativo está implantado na D:\home\site\wwwroot pasta .
    • Quando o aplicativo estiver hospedado pelo IIS, confirme se o aplicativo está implantado no caminho físico do IIS mostrado no guia Básico do Gerenciador do IIS Configurações.
  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 de publicação do projeto.

Para obter mais informações sobre o layout de um aplicativo ASP.NET Core publicado, consulte Estrutura do diretório do ASP.NET Core . Para obter mais informações sobre oweb.config, consulte Módulo do ASP.NET Core .

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.

500.0 Falha de carregamento de manipulador em processo

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

Ocorreu um erro desconhecido ao carregar ASP.NET Core componentes do Módulo. 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 ASP.NET Core módulo 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 está configurado in errado devido ao direcionamento de uma versão ASP.NET Core estrutura compartilhada que não está presente. Verifique quais versões da estrutura compartilhada do ASP.NET Core estão instaladas no computador de destino.
  • Usando Azure Key Vault, falta de permissões para o Key Vault. Verifique as políticas de acesso no Key Vault 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 ASP.NET Core módulo tenta iniciar o runtime do .NET Core em processo, mas falha ao iniciar. 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:

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 aplicativos destinados Microsoft.AspNetCore.App à estrutura podem ser hospedados pelo módulo 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 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 foi inicializado 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 do aplicativo ANCM não encontrada

O ANCM não conseguiu localizar a DLL do aplicativo, que deve estar ao lado do 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 existente do IIS. Esse cenário não é suportado pelo 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 PublishSingleFile propriedade MSBuild como false .
  2. Alternar para o modelo de hospedagem fora do processo definindo a AspNetCoreHostingModel propriedade 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 MSBuild no arquivo de projeto e a <Platform> bitness publicada do aplicativo.

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 ASP.NET Core módulo é 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.

Solução de problemas 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.

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 → Ir. 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 → Ir. 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. Executar o aplicativo:

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

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.

ASP.NET Core Log de stdout do módulo (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 > Vá.
  4. Selecione Console de depuração > CMD.
  5. Navegue até site/wwwroot
  6. Selecione o ícone de lápis para editar oweb.config arquivo.
  7. No elemento <aspNetCore /> , de definido e selecione stdoutLogEnabled="true" Salvar.

Desabilite o registro em log de stdout ao concluir a solução de problemas definindo stdoutLogEnabled="false" .

Para obter mais informações, consulte Módulo do ASP.NET Core.

ASP.NET Core Log de depuração do módulo (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 → Ir. 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 para o site de caminho > 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 → Ir. 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 para o site de caminho > 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 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 suspenso (Serviço de Aplicativo do Azure)

Quando um aplicativo responde lentamente ou trava em uma solicitação, consulte Solucionar problemas de desempenho lentos do aplicativo Web 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 → Ir. 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 site do caminho > 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, pesquise Visualizador de Eventos e selecione o Visualizador de Eventos aplicativo.
  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 ocorrerem erros ao fazer uma solicitação para o aplicativo, faça uma solicitação para o host e a porta em que Kestrel escuta. Usando o host e a porta padrão, faça uma solicitação para http://localhost:5000/. Se o aplicativo responder normalmente no Kestrel endereço do ponto de extremidade, é mais provável que o problema esteja relacionado à configuração de hospedagem e menos provável dentro do aplicativo.

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 onde Kestrel escuta. Usando o host e a porta padrão, faça uma solicitação para http://localhost:5000/. Se o aplicativo responder normalmente no Kestrel endereço do ponto de extremidade, é mais provável que o problema esteja relacionado à configuração de hospedagem e menos provável dentro do aplicativo.

ASP.NET Core Log stdout do módulo (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 identidade 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, consulte Módulo do ASP.NET Core.

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.

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

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

<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 identidade do pool de aplicativos tem permissões de gravação no local.

Para obter mais informações, consulte 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 saber mais e obter um código de exemplo, consulte solucionar problemas e depurar projetos ASP.NET Core.

Aplicativo lento ou suspenso (IIS)

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

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:

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

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

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 trava, falha durante a inicialização ou executa normalmente

Quando um aplicativo paralisa (para de responder, mas não falha), falha durante a inicialização ou é executado normalmente, consulte arquivos de despejo no modo de usuário: escolhendo a melhor ferramenta para selecionar uma ferramenta apropriada 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 após a atualização do SDK do .NET Core no computador de desenvolvimento ou a alteração das versões do pacote no 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 local All--Clear de um shell de comando.

    Limpar caches de pacote também pode ser feito com a ferramenta de nuget.exe e executar 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

Documentação do Azure

Documentação do Visual Studio

Documentação do Visual Studio Code

Este artigo fornece informações sobre erros de inicialização de aplicativo comuns e instruções sobre como diagnosticar erros quando um aplicativo é implantado no serviço de Azure App ou IIS:

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

Solucionar problemas no serviço Azure App
Fornece conselhos de solução de problemas para aplicativos implantados no serviço Azure App.

Solução de problemas no IIS
fornece conselhos de solução de problemas para aplicativos implantados no IIS ou em execução no IIS Express localmente. a orientação se aplica às implantações do Windows Server e do Windows desktop.

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

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

Erros de inicialização do aplicativo

no Visual Studio, um projeto de ASP.NET Core usa como padrão a hospedagem IIS Express durante a depuração. Uma falha de 502,5 processo ou uma falha de início de 500,30 que ocorre quando a depuração local pode ser diagnosticada usando o Conselho neste tópico.

403,14 proibido

Falha ao iniciar o aplicativo. 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 quebrada no sistema de hospedagem, que inclui qualquer um dos seguintes cenários:

  • O aplicativo é implantado na pasta incorreta no sistema de hospedagem.
  • O processo de implantação não moveu todos os arquivos e pastas do aplicativo para a pasta de implantação no sistema de hospedagem.
  • O arquivo de web.config está ausente na implantação ou o conteúdo do arquivo de 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 de publicação do aplicativo no sistema de hospedagem usando o método normal de implantação, como Visual Studio, PowerShell ou implantação manual:
    • Confirme se o arquivo de web.config está presente na implantação e se seu conteúdo está correto.
    • Ao hospedar no serviço Azure App, confirme se o aplicativo está implantado na D:\home\site\wwwroot pasta.
    • quando o aplicativo é hospedado pelo IIS, confirme se o aplicativo está implantado no caminho físico do iis mostrado na Configurações básica do gerenciador do iis.
  3. Confirme se todos os arquivos e pastas do aplicativo estão implantados comparando a implantação no sistema de hospedagem ao conteúdo da pasta de publicação do projeto.

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

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.

500.0 Falha de carregamento de manipulador em processo

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

o módulo ASP.NET Core falha ao localizar o .net Core CLR e localizar o manipulador de solicitação em processo (aspnetcorev2_inprocess.dll). Verifique se:

500.0 Falha de carregamento de manipulador fora de processo

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

o módulo ASP.NET Core falha ao localizar o manipulador de solicitação de hospedagem fora do processo. Verifique se a aspnetcorev2_outofprocess.dll está presente em uma subpasta próxima a aspnetcorev2.dll.

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 <Platform> propriedade MSBuild no arquivo de projeto e o bit de bits publicado do aplicativo.

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 ASP.NET Core é 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 Azure App

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.

Log de eventos do aplicativo (serviço Azure App)

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 → ir . 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 → ir . 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. Executar o aplicativo:

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

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.

ASP.NET Core Log stdout do módulo (serviço Azure App)

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. Navegue até a folha Diagnosticar e resolver problemas no portal do Azure.
  2. Em SELECIONAR CATEGORIA DE PROBLEMA, selecione o botão Aplicativo Web Inoperante.
  3. Em soluções sugeridas > habilitar o redirecionamento de log stdout, selecione o botão para abrir o console do kudu para editar Web.Config.
  4. No Console de Diagnóstico do Kudu, abra as pastas no caminho site > wwwroot. Role para baixo para revelar o arquivo web.config na parte inferior da lista.
  5. Clique no ícone de lápis ao lado do arquivo web.config.
  6. Defina stdoutLogEnabled para true e altere o caminho stdoutLogFile para \\?\%home%\LogFiles\stdout.
  7. Selecione Salvar para salvar o arquivo web.config atualizado.
  8. Faça uma solicitação ao aplicativo.
  9. Retorne ao portal do Azure. Selecione a folha Ferramentas Avançadas na área FERRAMENTAS DE DESENVOLVIMENTO. Selecione o botão → ir . O console do Kudu é aberto em uma nova janela ou guia do navegador.
  10. Usando a barra de navegação na parte superior da página, abra Console de depuração e selecione CMD.
  11. Abra a pasta LogFiles.
  12. Inspecione a coluna Modificado em e selecione o ícone de lápis para editar o log de stdout com a data da última modificação.
  13. Quando o arquivo de log é aberto, o erro é exibido.

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

  1. No Console de Diagnóstico do Kudu, retorne para o caminho site > wwwroot para revelar o arquivo web.config. Abra o arquivo web.config novamente, selecionando o ícone de lápis.
  2. Defina stdoutLogEnabled para false.
  3. Selecione Salvar para salvar o arquivo.

Para obter mais informações, consulte Módulo do ASP.NET Core.

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.

ASP.NET Core Log de depuração de módulo (serviço Azure App)

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 → ir . 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 → ir . 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 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 suspenso (serviço de Azure App)

Para saber mais sobre quando um aplicativo responde lentamente ou trava em uma solicitação, confira os seguintes artigos:

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 → ir . 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 para o site de caminho > wwwroot e role para baixo para revelar o web.config arquivo 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 onde Kestrel escuta. Usando o host e a porta padrão, faça uma solicitação para http://localhost:5000/. Se o aplicativo responder normalmente no Kestrel endereço do ponto de extremidade, é mais provável que o problema esteja relacionado à configuração de hospedagem e menos provável dentro do aplicativo.

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 onde Kestrel escuta. Usando o host e a porta padrão, faça uma solicitação para http://localhost:5000/. Se o aplicativo responder normalmente no Kestrel endereço do ponto de extremidade, é mais provável que o problema esteja relacionado à configuração de hospedagem e menos provável dentro do aplicativo.

ASP.NET Core Log stdout do módulo (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 identidade 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, consulte Módulo do ASP.NET Core.

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.

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

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

<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 identidade do pool de aplicativos tem permissões de gravação no local.

Para obter mais informações, consulte 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 saber mais e obter um código de exemplo, consulte solucionar problemas e depurar projetos ASP.NET Core.

Aplicativo lento ou suspenso (IIS)

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

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:

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

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

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 trava, falha durante a inicialização ou executa normalmente

Quando um aplicativo paralisa (para de responder, mas não falha), falha durante a inicialização ou é executado normalmente, consulte arquivos de despejo no modo de usuário: escolhendo a melhor ferramenta para selecionar uma ferramenta apropriada 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 após a atualização do SDK do .NET Core no computador de desenvolvimento ou a alteração das versões do pacote no 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 local All--Clear de um shell de comando.

    Limpar caches de pacote também pode ser feito com a ferramenta de nuget.exe e executar 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

Documentação do Azure

Documentação do Visual Studio

Documentação do Visual Studio Code

Este artigo fornece informações sobre erros de inicialização de aplicativo comuns e instruções sobre como diagnosticar erros quando um aplicativo é implantado no serviço de Azure App ou IIS:

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

Solucionar problemas no serviço Azure App
Fornece conselhos de solução de problemas para aplicativos implantados no serviço Azure App.

Solução de problemas no IIS
fornece conselhos de solução de problemas para aplicativos implantados no IIS ou em execução no IIS Express localmente. a orientação se aplica às implantações do Windows Server e do Windows desktop.

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

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

Erros de inicialização do aplicativo

no Visual Studio, um projeto de ASP.NET Core usa como padrão a hospedagem IIS Express durante a depuração. Uma falha de processo 502,5 que ocorre ao depurar localmente pode ser diagnosticada usando o Conselho neste tópico.

403,14 proibido

Falha ao iniciar o aplicativo. 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 quebrada no sistema de hospedagem, que inclui qualquer um dos seguintes cenários:

  • O aplicativo é implantado na pasta incorreta no sistema de hospedagem.
  • O processo de implantação não moveu todos os arquivos e pastas do aplicativo para a pasta de implantação no sistema de hospedagem.
  • O arquivo de web.config está ausente na implantação ou o conteúdo do arquivo de 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 de publicação do aplicativo no sistema de hospedagem usando o método normal de implantação, como Visual Studio, PowerShell ou implantação manual:
    • Confirme se o arquivo de web.config está presente na implantação e se seu conteúdo está correto.
    • Ao hospedar no serviço Azure App, confirme se o aplicativo está implantado na D:\home\site\wwwroot pasta.
    • quando o aplicativo é hospedado pelo IIS, confirme se o aplicativo está implantado no caminho físico do iis mostrado na Configurações básica do gerenciador do iis.
  3. Confirme se todos os arquivos e pastas do aplicativo estão implantados comparando a implantação no sistema de hospedagem ao conteúdo da pasta de publicação do projeto.

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

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.

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 MSBuild no arquivo de projeto e a <Platform> bitness publicada do aplicativo.

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 ASP.NET Core módulo é 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.

Solução de problemas 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.

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 → Ir. 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 → Ir. 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. Executar o aplicativo:

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

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.

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

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. Navegue até a folha Diagnosticar e resolver problemas no portal do Azure.
  2. Em SELECIONAR CATEGORIA DE PROBLEMA, selecione o botão Aplicativo Web Inoperante.
  3. Em Soluções > Sugeridas Habilitar Redirecionamento de Log stdout, selecione o botão abrir o Console do Kudu para editar Web.Config.
  4. No Console de Diagnóstico do Kudu, abra as pastas no caminho site > wwwroot. Role para baixo para revelar o arquivo web.config na parte inferior da lista.
  5. Clique no ícone de lápis ao lado do arquivo web.config.
  6. Defina stdoutLogEnabled para true e altere o caminho stdoutLogFile para \\?\%home%\LogFiles\stdout.
  7. Selecione Salvar para salvar o arquivo web.config atualizado.
  8. Faça uma solicitação ao aplicativo.
  9. Retorne ao portal do Azure. Selecione a folha Ferramentas Avançadas na área FERRAMENTAS DE DESENVOLVIMENTO. Selecione o botão → Ir. O console do Kudu é aberto em uma nova janela ou guia do navegador.
  10. Usando a barra de navegação na parte superior da página, abra Console de depuração e selecione CMD.
  11. Abra a pasta LogFiles.
  12. Inspecione a coluna Modificado em e selecione o ícone de lápis para editar o log de stdout com a data da última modificação.
  13. Quando o arquivo de log é aberto, o erro é exibido.

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

  1. No Console de Diagnóstico do Kudu, retorne para o caminho site > wwwroot para revelar o arquivo web.config. Abra o arquivo web.config novamente, selecionando o ícone de lápis.
  2. Defina stdoutLogEnabled para false.
  3. Selecione Salvar para salvar o arquivo.

Para obter mais informações, consulte Módulo do ASP.NET Core.

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.

Aplicativo lento ou suspenso (Serviço de Aplicativo do Azure)

Para saber mais sobre quando um aplicativo responde lentamente ou trava em uma solicitação, confira os seguintes artigos:

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 → ir . 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 para o site de caminho > wwwroot e role para baixo para revelar o web.config arquivo 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 onde Kestrel escuta. Usando o host e a porta padrão, faça uma solicitação para http://localhost:5000/. Se o aplicativo responder normalmente no Kestrel endereço do ponto de extremidade, é mais provável que o problema esteja relacionado à configuração de hospedagem e menos provável dentro do aplicativo.

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 onde Kestrel escuta. Usando o host e a porta padrão, faça uma solicitação para http://localhost:5000/. Se o aplicativo responder normalmente no Kestrel endereço do ponto de extremidade, é mais provável que o problema esteja relacionado à configuração de hospedagem e menos provável dentro do aplicativo.

ASP.NET Core Log stdout do módulo (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 identidade 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, consulte Módulo do ASP.NET Core.

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.

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">
  <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 saber mais e obter um código de exemplo, consulte solucionar problemas e depurar projetos ASP.NET Core.

Aplicativo lento ou suspenso (IIS)

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

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:

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

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

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 trava, falha durante a inicialização ou executa normalmente

Quando um aplicativo trava (para de responder, mas não falha), falha durante a inicialização ou é executado normalmente, consulte Arquivos de despejo do modo de usuário: escolhendo a melhor ferramenta para selecionar uma ferramenta apropriada 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 após atualizar o SDK do .NET Core no computador de desenvolvimento ou alterar as versões de 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 do pacote executando dotnet nuget locals all --clear de um shell de comando.

    Limpar caches de pacote também pode ser feito com a ferramentanuget.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

Documentação do Azure

Documentação do Visual Studio

Documentação do Visual Studio Code