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 de aplicativos 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.

Solucionar problemas no Serviço de Aplicativo do Azure
Fornece conselhos de solução de problemas para aplicativos implantados no 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 executados no IIS Express localmente. As diretrizes se aplicam tanto a implantações do Windows Server quanto do ambiente de trabalho do Windows.

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

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

Erros de arranque da aplicação

No Visual Studio, o servidor padrão do projeto 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 ocorrem ao depurar localmente com o IIS Express pode ser diagnosticada usando as recomendações deste 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 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 de publicação 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 seu conteúdo está correto.
   • Ao hospedar no Serviço de Aplicativo do Azure, confirme se o aplicativo está implantado na D:\home\site\wwwroot pasta.
   • Quando o aplicativo for hospedado pelo IIS, confirme se o aplicativo foi 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 foram 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 ASP.NET estrutura de diretórios Core. Para obter mais informações sobre o arquivo web.config, consulte ASP.NET ANCM (Core Module) para IIS.

500 Erro interno do servidor

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

Este erro ocorre dentro do código do aplicativo durante a inicialização ou ao criar uma resposta. A resposta pode não conter conteúdo, ou a resposta pode aparecer como um erro de servidor interno 500 no navegador. O Log de Eventos do Aplicativo geralmente indica que o aplicativo foi iniciado normalmente. Do ponto de vista do servidor, isso está correto. O aplicativo foi iniciado, mas não pode gerar uma resposta válida. Execute o aplicativo em um prompt de comando no servidor ou habilite o log stdout do ASP.NET Core Module para solucionar o problema.

Este erro também pode ocorrer quando o .NET Hosting Bundle não está instalado ou está corrompido. Instalar ou reparar a instalação do .NET Hosting Bundle (para IIS) ou Visual Studio (para IIS Express) pode corrigir o problema.

Falha de carga do manipulador de In-Process 500.0

O processo de trabalho falha. O aplicativo não inicia.

Ocorreu um erro desconhecido ao carregar componentes do módulo ASP.NET Core. Efetue uma das seguintes ações:

• Entre em contato com o Suporte da Microsoft (selecione Ferramentas de Desenvolvimento e, em seguida, ASP.NET Core).
• Faça uma pergunta sobre Stack Overflow.
• Registre um problema em nosso repositório GitHub.

500.30 Falha de inicialização do In-Process

O processo de trabalho falha. O aplicativo não inicia.

O ASP.NET Core Module tenta iniciar o .NET CLR em processo, mas não consegue iniciar. A causa de uma falha de inicialização do processo geralmente pode ser determinada a partir de entradas no log de eventos do aplicativo e no log stdout do módulo principal do ASP.NET.

Condições comuns de falha:

• A aplicação está mal configurada por visar uma versão do framework partilhado do ASP.NET Core que não está presente. Verifique quais versões da estrutura compartilhada do ASP.NET Core estão instaladas na máquina de destino.
• Usando o Azure Key Vault, falta de permissões para o Key Vault. Verifique as políticas de acesso no Cofre da Chave de destino para garantir que as permissões corretas sejam concedidas.

500.31 ANCM falha ao encontrar dependências nativas

O processo de trabalho falha. O aplicativo não inicia.

O Módulo ASP.NET Core tenta iniciar o runtime do .NET em modo in-processo, mas ele não consegue iniciar. A causa mais comum dessa falha de arranque é quando o runtime Microsoft.NETCore.App ou o Microsoft.AspNetCore.App não está instalado. Se a aplicação for implantada para destinar o ASP.NET Core 3.0 e essa versão não estiver disponível no computador, esse erro ocorrerá. Segue-se 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 do .NET instaladas e a versão solicitada pelo aplicativo. Para corrigir esse erro:

• Instale a versão apropriada do .NET no computador.
• Altere o aplicativo para direcionar uma versão do .NET presente no computador.
• Publique o aplicativo como uma implantação independente.

Quando executado em desenvolvimento (a ASPNETCORE_ENVIRONMENT variável de ambiente é 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 ANCM falhou ao carregar DLL

O processo de trabalho falha. O aplicativo não inicia.

A causa mais comum para esse erro é que o aplicativo é publicado para uma arquitetura de processador incompatível. Se o processo de trabalho estiver sendo executado como um aplicativo de 32 bits e o aplicativo tiver sido publicado para o destino de 64 bits, esse erro ocorrerá.

Para corrigir esse erro:

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

500.33 Falha de carga do manipulador de solicitações ANCM

O processo de trabalho falha. O aplicativo não inicia.

O aplicativo não fez referência à Microsoft.AspNetCore.App estrutura. Somente os aplicativos direcionados à Microsoft.AspNetCore.App estrutura podem ser hospedados pelo ASP.NET Core Module.

Para corrigir esse erro, confirme se o aplicativo está direcionando a Microsoft.AspNetCore.App estrutura. Verifique o .runtimeconfig.json para confirmar o framework visado pela aplicação.

500.34 Modelos de hospedagem mista ANCM não suportados

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

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

500.35 ANCM Múltiplas Aplicações em Processamento 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 out-of-process ANCM

O manipulador de solicitações fora do processo, aspnetcorev2_outofprocess.dll, não está ao lado do arquivo aspnetcorev2.dll . Isso indica uma instalação corrompida do ASP.NET Core Module.

Para corrigir esse erro, repare a instalação do .NET Hosting Bundle (para IIS) ou Visual Studio (para IIS Express).

500.37 ANCM falhou ao iniciar dentro do limite de tempo de arranque

ANCM falhou ao iniciar dentro do limite de tempo de inicialização fornecido. Por padrão, o tempo limite é de 120 segundos.

Este erro pode ocorrer ao iniciar um grande número de aplicativos na mesma máquina. Verifique se há picos de uso de CPU/memória no servidor durante a inicialização. Pode ser necessário escalonar o processo de inicialização de vários aplicativos.

500.38 DLL de aplicativo ANCM não encontrada

ANCM não conseguiu localizar a DLL do aplicativo, que deve estar ao lado do executável.

Este 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 no processo do IIS existente. 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. Desative a publicação de arquivo único definindo a PublishSingleFile propriedade MSBuild como false.
2. Altere para o modelo de hospedagem independente do processo definindo a AspNetCoreHostingModel propriedade MSBuild como OutOfProcess.

Falha no Processo 502.5

O processo de trabalho falha. O aplicativo não inicia.

O Módulo ASP.NET Core tenta iniciar o processo de trabalho, mas não consegue iniciar. A causa de uma falha de inicialização do processo geralmente pode ser determinada a partir de entradas no log de eventos do aplicativo e no log stdout do módulo principal do ASP.NET.

Uma falha comum ocorre quando a aplicação está mal configurada devido ao direcionamento de uma versão que não está presente da estrutura partilhada do ASP.NET Core. Verifique quais versões da estrutura compartilhada do ASP.NET Core estão instaladas na máquina de destino. A estrutura partilhada é o conjunto de assemblies (arquivos .dll) instalados na máquina e referenciados por um(a) metapacote como Microsoft.AspNetCore.App. A referência do metapacote pode especificar uma versão mínima necessária. Para obter mais informações, consulte A estrutura compartilhada.

A página de erro Falha de processo 502.5 é retornada quando uma hospedagem ou configuração incorreta 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 iniciar porque o assembly do aplicativo (.dll) não pôde ser carregado.

Este erro ocorre quando há uma incompatibilidade 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 nos Pools de Aplicativos do Gerenciador do IIS.
2. Selecione Configurações avançadas em Editar pool de aplicativos no painel Ações .
3. Definir Ativar 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 do <Platform> MSBuild no ficheiro de projeto e o bitness 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 falhou ao iniciar porque um serviço do Windows falhou ao carregar.

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

Reinício da ligação

Se ocorrer um erro depois que os cabeçalhos forem enviados, é tarde demais para o servidor enviar um erro interno do servidor 500 quando ocorrer um erro. Isso geralmente acontece quando ocorre um erro durante a serialização de objetos complexos para uma resposta. Esse tipo de erro aparece como um erro de redefinição de conexão no cliente. O log de aplicativos pode ajudar a solucionar esses tipos de erros.

Limites de inicialização padrão

O ASP.NET Core Module é configurado com um startupTimeLimit padrão de 120 segundos. Quando deixado no valor padrão, um aplicativo pode levar até dois minutos para ser iniciado antes que o módulo registre uma falha de processo. Para obter informações sobre como configurar o módulo, consulte Atributos do elemento aspNetCore.

Solucionar problemas no Serviço de Aplicativo do Azure

Fluxo de log dos Serviços de Aplicativo do Azure

O Log dos Serviços de Aplicativo do Azure transmite informações de log à medida que ocorrem. Para visualizar os logs de streaming:

1. No portal do Azure, abra o aplicativo nos Serviços de Aplicativo.
2. No painel esquerdo, navegue até Monitorização>Logs do Serviço de Aplicações.
3. Selecione Sistema de arquivos para registro em log do servidor Web. Opcionalmente, habilite o log do aplicativo.
4. No painel esquerdo, navegue até Fluxo de Log de Monitoramento> e selecione Logs de aplicativos ou Logs de servidor Web.

As imagens a seguir 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 resolver problemas no portal do Azure:

1. No portal do Azure, abra o aplicativo nos Serviços de Aplicativo.
2. Selecione Diagnosticar e resolver 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 Source .

Uma alternativa para usar o painel Diagnosticar e resolver problemas é examinar o ficheiro de registo de eventos da aplicação diretamente usando Kudu:

1. Abra Ferramentas Avançadas na área Ferramentas de Desenvolvimento . Selecione o botão Ir→ . O console Kudu é aberto em uma nova guia ou janela do navegador.
2. Usando a barra de navegação na parte superior da página, abra o console Debug e selecione CMD.
3. Abra a pasta LogFiles .
4. Selecione o ícone de lápis ao lado do eventlog.xml arquivo.
5. Examine o registo. Desloque-se para a parte inferior do registo 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 Kudu Remote Execution Console para descobrir o erro:

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

Testar um aplicativo de 32 bits (x86)

Lançamento atual

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

   • Se a aplicação for uma implementação dependente do framework:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Se o aplicativo for uma implantação independente:

     {ASSEMBLY NAME}.exe
     

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

Implementação dependente de framework em execução numa versão prévia

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

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

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

Testar uma aplicação de 64 bits (x64)

Lançamento atual

• Se a aplicação for uma implementação dependente do framework 64 bits (x64):
  1. cd D:\Program Files\dotnet
  2. Execute a aplicação: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Se o aplicativo for uma implantação independente:
  1. cd D:\home\site\wwwroot
  2. Execute a aplicação: {ASSEMBLY NAME}.exe

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

Implementação dependente de framework em execução numa versão prévia

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

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

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

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

O log stdout do módulo principal do ASP.NET geralmente registra mensagens de erro úteis não encontradas no log de eventos do aplicativo. Para habilitar e visualizar logs de stdout:

1. No Portal do Azure, navegue até o aplicativo Web.
2. Na folha Serviço de Aplicativo , digite kudu na caixa de pesquisa.
3. Selecione Advanced Tools>Go.
4. Selecione Console de depuração CMD>.
5. Navegue até site/wwwroot
6. Selecione o ícone de lápis para editar o arquivo web.config .
7. No elemento <aspNetCore />, defina stdoutLogEnabled="true" e selecione Guardar.

Desative o registro stdout quando a solução de problemas estiver concluída definindo stdoutLogEnabled="false".

Para obter mais informações, consulte ASP.NET ANCM (Core Module) para IIS.

Log de depuração do módulo ASP.NET Core (Serviço de Aplicações do Azure)

O log de depuração do Módulo ASP.NET Core proporciona um registo adicional e mais detalhado. Para habilitar e visualizar logs de stdout:

1. Para habilitar o log de diagnóstico avançado, execute um dos seguintes procedimentos:
   • Siga as instruções em Registos de diagnóstico aprimorados para configurar a aplicação para registos de diagnóstico aprimorados. Reimplemente a aplicação.
   • Adicione o <handlerSettings> mostrado em Registos de diagnóstico melhorados ao arquivo web.config da aplicação em execução usando o console Kudu.
     1. Abra Ferramentas Avançadas na área Ferramentas de Desenvolvimento . Selecione o botão Ir→ . O console Kudu é aberto em uma nova guia ou janela do navegador.
     2. Usando a barra de navegação na parte superior da página, abra o console Debug e selecione CMD.
     3. Abra as pastas para o caminho site>wwwroot. Edite o arquivo web.config selecionando o botão de lápis. Adicione a <handlerSettings> seção 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 Kudu é aberto em uma nova guia ou janela do navegador.
3. Usando a barra de navegação na parte superior da página, abra o console Debug e selecione CMD.
4. Abra as pastas para o caminho site>wwwroot. Se você não forneceu um caminho para o arquivo aspnetcore-debug.log , o arquivo aparecerá na lista. Se você forneceu 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.

Desative o log de depuração quando a solução de problemas estiver concluída:

Para desativar o log de depuração avançado, execute um dos seguintes procedimentos:

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

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

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

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

Monitorização das lâminas

As lâminas de monitoramento fornecem uma experiência de solução de problemas alternativa aos métodos descritos anteriormente no tópico. Esses módulos podem ser usados para diagnosticar erros da "série 500".

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

1. Na secção FERRAMENTAS DE DESENVOLVIMENTO, selecione a folha Extensões.
2. O ASP.NET Core Extensions deve aparecer na lista.
3. Se as extensões não estiverem instaladas, selecione o botão Adicionar .
4. Escolha as ASP.NET extensões principais na 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 registo stdout não estiver ativado, siga estes passos:

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

Prossiga para ativar o log de diagnóstico:

1. No portal do Azure, selecione o separador Logs de Diagnóstico.
2. Selecione a opção On para Log de aplicativos (sistema de arquivos) e mensagens de erro detalhadas. Selecione o botão Guardar na parte superior do painel.
3. Para incluir o rastreamento de solicitações com falha, também conhecido como registo FREB (Failed Request Event Buffering), selecione a opção Ativa para rastreamento de solicitações com falha.
4. Selecione o painel Fluxo de log, que é encontrado imediatamente abaixo do painel Logs de diagnóstico no portal.
5. Faça uma solicitação para o aplicativo.
6. Nos dados do fluxo de log, a causa do erro é indicada.

Certifique-se de desativar o registro stdout quando a solução de problemas estiver concluída.

Para visualizar os registos de rastreamento de solicitações com falha (registos FREB):

1. Navegue até a folha Diagnosticar e resolver problemas no portal do Azure.
2. Selecione Registros de rastreamento de solicitação com falha na área FERRAMENTAS DE SUPORTE da barra lateral.

Consulte a seção Rastreamentos de solicitação com falha do tópico Habilitar log de diagnóstico para aplicativos Web no Serviço de Aplicativo do Azure e as Perguntas frequentes sobre desempenho de aplicativos para aplicativos Web no Azure: Como faço para ativar o rastreamento de solicitação com falha? para obter mais informações.

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

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 o Visualizador de Eventose selecione a aplicação Visualizador de Eventos.
2. Em Visualizador de Eventos, abra o nó Logs do Windows.
3. Selecione Aplicação para abrir o Log de Eventos da Aplicação.
4. Procure pelos erros associados à aplicação com falha. Os erros têm um valor de IIS AspNetCore Module ou IIS Express AspNetCore Module na coluna Source .

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 executando o aplicativo em um prompt de comando no sistema de hospedagem.

Implantação dependente da estrutura

Se a aplicação for uma implementação dependente do framework:

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 quaisquer 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 está a escutar. Usando o host e a postagem padrão, faça uma solicitação para http://localhost:5000/. Se a aplicação responder normalmente no endereço do Kestrel ponto final, é mais provável que o problema esteja relacionado à configuração de hospedagem e menos provável que seja interno à aplicação.

Implantação autônoma

Se o aplicativo for uma implantação independente:

1. Em um prompt de comando, navegue até a pasta de implantação e execute o 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 quaisquer 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 está a escutar. Usando o host e a postagem padrão, faça uma solicitação para http://localhost:5000/. Se a aplicação responder normalmente no endereço do Kestrel ponto final, é mais provável que o problema esteja relacionado à configuração de hospedagem e menos provável que seja interno à aplicação.

ASP.NET Log stdout do módulo principal (IIS)

Para habilitar e visualizar 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 pasta. Para obter instruções sobre como habilitar o MSBuild para criar a pasta logs na implantação automaticamente, consulte o tópico Estrutura de diretórios .
3. Edite o arquivo web.config . Defina stdoutLogEnabled como true e altere o caminho stdoutLogFile para apontar para a pasta logs (por exemplo, .\logs\stdout). stdout no caminho está o prefixo do nome do arquivo de log. Um carimbo de data/hora, ID do processo e extensão de arquivo são adicionados automaticamente quando o log é criado. Usando stdout como o prefixo do nome do arquivo, um arquivo de log típico é chamado stdout_20180205184032_5412.log.
4. Assegure-se de que a identidade do pool de aplicações tem permissões de gravação na pasta logs.
5. Salve o arquivo deweb.config atualizado.
6. Faça uma solicitação para o aplicativo.
7. Navegue até a pasta logs . Localize e abra o log stdout mais recente.
8. Estude o log em busca de erros.

Desative o registro stdout quando a solução de problemas estiver concluída:

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

Para obter mais informações, consulte ASP.NET ANCM (Core Module) para IIS.

ASP.NET log de depuração do módulo principal (IIS)

Adicione as seguintes configurações do 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 identidade do pool de aplicações tem permissões de escrita no local.

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

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

A ASPNETCORE_ENVIRONMENTvariável de ambiente pode ser adicionada a web.config para executar a aplicação no Development ambiente. Contanto que o ambiente não seja substituído na inicialização do aplicativo pelo UseEnvironment construtor de hosts, a configuração da variável de ambiente permite que a Página de Exceção do Desenvolvedor apareça quando o aplicativo for executado.

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

A configuração da variável de ambiente para ASPNETCORE_ENVIRONMENT só é recomendada para uso em servidores de preparo e teste que não estão 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, consulte o elemento filho environmentVariables do aspNetCore.

Obter dados de um aplicativo

Se uma aplicação for capaz de responder a pedidos, obtenha dados de solicitação, conexão e adicionais da aplicação usando middleware terminal em linha. Para obter mais informações e código de exemplo, consulte Solucionar problemas e depurar projetos 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 aplicação, falha de inicialização ou aplicação lenta.

O aplicativo falha ou encontra uma exceção

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

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

2. Corra o EnableDumps PowerShell script:

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

     .\EnableDumps w3wp.exe c:\dumps
     

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

     .\EnableDumps dotnet.exe c:\dumps
     

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

4. Depois que a falha tiver ocorrido, execute o script DisableDumps PowerShell:

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

     .\DisableDumps w3wp.exe
     

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

     .\DisableDumps dotnet.exe
     

Depois que um aplicativo falha e a coleta de despejo é concluída, o aplicativo pode ser encerrado normalmente. O script do PowerShell configura o WER para coletar até cinco despejos por aplicativo.

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

Quando um aplicativo para de responder, mas não falha, falha durante a inicialização ou funciona normalmente, consulte User-Mode Arquivos de despejo: Escolhendo a melhor ferramenta para selecionar uma ferramenta apropriada para produzir o despejo.

Analise o despejo

Um despejo pode ser analisado usando várias abordagens. Para obter mais informações, consulte Analisando um ficheiro de despejo User-Mode.

Limpar caches de pacotes

Um aplicativo em funcionamento pode falhar imediatamente após atualizar o SDK do .NET na máquina de desenvolvimento ou alterar as versões do pacote dentro do aplicativo. Em alguns casos, pacotes incoerentes podem quebrar um aplicativo ao executar grandes atualizações. A maioria desses problemas pode ser corrigida seguindo estas instruções:

1. Apague as pastas do compartimento e obj .

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

   A limpeza de caches de pacotes também pode ser realizada com a ferramenta nuget.exe e executando o comando nuget locals all -clear. nuget.exe não é uma instalação integrada com o sistema operacional de desktop Windows e deve ser obtida separadamente do site NuGet.

3. Restaure e reconstrua 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 ASP.NET Core
• Solução de problemas de erro comum para o Serviço de Aplicativo do Azure e o IIS com ASP.NET Core
• Manipular erros no ASP.NET Core
• ASP.NET Módulo Principal (ANCM) para IIS

Documentação de Azure

• Application Insights para ASP.NET Core
• Seção de depuração remota de aplicativos web do Solucionar Problemas de um Aplicativo Web no Serviço de Aplicativo Azure usando o Visual Studio
• Visão geral do diagnóstico do Serviço de Aplicações do Azure
• Como: Monitorar aplicativos 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 erros HTTP de "502 bad gateway" e "503 service unavailable" nas suas aplicações web do Azure
• Troubleshoot slow web app performance issues in Azure App Service (Resolver problemas de desempenho lento das aplicações Web no Serviço de Aplicações do Azure)
• Perguntas frequentes sobre desempenho de aplicativos para aplicativos Web no Azure
• Sandbox do App Web do Azure (limitações de execução do Serviço de Aplicativo)

Documentação do Visual Studio

• Depuração remota ASP.NET Core no IIS no Azure no Visual Studio 2017
• Depuração remota de ASP.NET Core num computador IIS remoto no Visual Studio 2017
• Aprenda a depurar usando o Visual Studio

Documentação do Visual Studio Code

• Depuração com código do Visual Studio

Este artigo fornece informações sobre erros comuns de inicialização de aplicativos 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.

Solucionar problemas no Serviço de Aplicativo do Azure
Fornece conselhos de solução de problemas para aplicativos implantados no 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 executados no IIS Express localmente. As diretrizes se aplicam tanto a implantações do Windows Server quanto do ambiente de trabalho do Windows.

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

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

Erros de arranque da aplicação

No Visual Studio, um projeto ASP.NET Core assume como padrão a hospedagem do IIS Express durante a depuração. A 502.5 - Falha de processo ou uma 500.30 - Falha de início que ocorre ao depurar localmente pode ser diagnosticada usando os conselhos deste 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 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 de publicação 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 seu conteúdo está correto.
   • Ao hospedar no Serviço de Aplicativo do Azure, confirme se o aplicativo está implantado na D:\home\site\wwwroot pasta.
   • Quando o aplicativo for hospedado pelo IIS, confirme se o aplicativo foi 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 foram 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 ASP.NET estrutura de diretórios Core. Para obter mais informações sobre o arquivo web.config, consulte ASP.NET ANCM (Core Module) para IIS.

500 Erro interno do servidor

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

Este erro ocorre dentro do código do aplicativo durante a inicialização ou ao criar uma resposta. A resposta pode não conter conteúdo, ou a resposta pode aparecer como um erro de servidor interno 500 no navegador. O Log de Eventos do Aplicativo geralmente indica que o aplicativo foi iniciado normalmente. Do ponto de vista do servidor, isso está correto. O aplicativo foi iniciado, mas não pode gerar uma resposta válida. Execute o aplicativo em um prompt de comando no servidor ou habilite o log stdout do ASP.NET Core Module para solucionar o problema.

Este erro também pode ocorrer quando o .NET Core Hosting Bundle não está instalado ou está corrompido. Instalar ou reparar a instalação do .NET Core Hosting Bundle (para IIS) ou Visual Studio (para IIS Express) pode corrigir o problema.

Falha de carga do manipulador de In-Process 500.0

O processo de trabalho falha. O aplicativo não inicia.

O ASP.NET Core Module não consegue localizar o CLR do .NET Core e localizar o manipulador de solicitação em processo (aspnetcorev2_inprocess.dll). Verifique se:

• O aplicativo tem como alvo o pacote NuGet Microsoft.AspNetCore.Server.IIS ou o metapacote Microsoft.AspNetCore.App.
• A versão do framework partilhado do ASP.NET Core que o aplicativo tem como alvo está instalada na máquina de destino.

Falha de carregamento do manipulador fora de processo 500.0

O processo de trabalho falha. O aplicativo não inicia.

O ASP.NET Core Module não consegue encontrar o manipulador de solicitação de hospedagem fora do processo. Verifique se o aspnetcorev2_outofprocess.dll está presente numa subpasta junto ao aspnetcorev2.dll.

Falha no Processo 502.5

O processo de trabalho falha. O aplicativo não inicia.

O Módulo ASP.NET Core tenta iniciar o processo de trabalho, mas não consegue iniciar. A causa de uma falha de inicialização do processo geralmente pode ser determinada a partir de entradas no log de eventos do aplicativo e no log stdout do módulo principal do ASP.NET.

Uma falha comum ocorre quando a aplicação está mal configurada devido ao direcionamento de uma versão que não está presente da estrutura partilhada do ASP.NET Core. Verifique quais versões da estrutura compartilhada do ASP.NET Core estão instaladas na máquina de destino. A estrutura partilhada é o conjunto de assemblies (arquivos .dll) instalados na máquina e referenciados por um(a) metapacote como Microsoft.AspNetCore.App. A referência do metapacote pode especificar uma versão mínima necessária. Para obter mais informações, consulte A estrutura compartilhada.

A página de erro Falha de processo 502.5 é retornada quando uma hospedagem ou configuração incorreta 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 iniciar porque o assembly do aplicativo (.dll) não pôde ser carregado.

Este erro ocorre quando há uma incompatibilidade 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 nos Pools de Aplicativos do Gerenciador do IIS.
2. Selecione Configurações avançadas em Editar pool de aplicativos no painel Ações .
3. Definir Ativar 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 do <Platform> MSBuild no ficheiro de projeto e o bitness publicado do aplicativo.

Reinício da ligação

Se ocorrer um erro depois que os cabeçalhos forem enviados, é tarde demais para o servidor enviar um erro interno do servidor 500 quando ocorrer um erro. Isso geralmente acontece quando ocorre um erro durante a serialização de objetos complexos para uma resposta. Esse tipo de erro aparece como um erro de redefinição de conexão no cliente. O log de aplicativos pode ajudar a solucionar esses tipos de erros.

Limites de inicialização padrão

O ASP.NET Core Module é configurado com um startupTimeLimit padrão de 120 segundos. Quando deixado no valor padrão, um aplicativo pode levar até dois minutos para ser iniciado antes que o módulo registre uma falha de processo. Para obter informações sobre como configurar o módulo, consulte Atributos do elemento aspNetCore.

Solucionar problemas no 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 resolver problemas no portal do Azure:

1. No portal do Azure, abra o aplicativo nos Serviços de Aplicativo.
2. Selecione Diagnosticar e resolver 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 Source .

Uma alternativa para usar o painel Diagnosticar e resolver problemas é examinar o ficheiro de registo de eventos da aplicação diretamente usando Kudu:

1. Abra Ferramentas Avançadas na área Ferramentas de Desenvolvimento . Selecione o botão Ir→ . O console Kudu é aberto em uma nova guia ou janela do navegador.
2. Usando a barra de navegação na parte superior da página, abra o console Debug e selecione CMD.
3. Abra a pasta LogFiles .
4. Selecione o ícone de lápis ao lado do eventlog.xml arquivo.
5. Examine o registo. Desloque-se para a parte inferior do registo 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 Kudu Remote Execution Console para descobrir o erro:

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

Testar um aplicativo de 32 bits (x86)

Lançamento atual

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

   • Se a aplicação for uma implementação dependente do framework:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Se o aplicativo for uma implantação independente:

     {ASSEMBLY NAME}.exe
     

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

Implementação dependente de framework em execução numa versão prévia

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

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

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

Testar uma aplicação de 64 bits (x64)

Lançamento atual

• Se a aplicação for uma implementação dependente do framework 64 bits (x64):
  1. cd D:\Program Files\dotnet
  2. Execute a aplicação: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Se o aplicativo for uma implantação independente:
  1. cd D:\home\site\wwwroot
  2. Execute a aplicação: {ASSEMBLY NAME}.exe

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

Implementação dependente de framework em execução numa versão prévia

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

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

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

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

O log stdout do módulo principal do ASP.NET geralmente registra mensagens de erro úteis não encontradas no log de eventos do aplicativo. Para habilitar e visualizar logs de stdout:

1. Navegue até a folha Diagnosticar e resolver problemas no portal do Azure.
2. Em SELECT PROBLEM CATEGORY, selecione o botão Web App Down.
3. Em Soluções sugeridas>Ativar o redirecionamento de log do Stdout, selecione o botão para Abrir a Consola Kudu para editar o Web.Config.
4. No Console de Diagnóstico do Kudu, abra as pastas até o caminho site>wwwroot. Desloque-se para baixo para revelar o ficheiroweb.config na parte inferior da lista.
5. Clique no ícone de lápis ao lado do arquivo web.config .
6. Configure stdoutLogEnabled para true e defina o caminho do stdoutLogFile para: \\?\%home%\LogFiles\stdout.
7. Selecione Salvar para salvar o arquivo deweb.config atualizado.
8. Faça uma solicitação para o aplicativo.
9. Retorne ao portal do Azure. Selecione a seção Ferramentas Avançadas na área Ferramentas de Desenvolvimento. Selecione o botão Ir→ . O console Kudu é aberto em uma nova guia ou janela do navegador.
10. Usando a barra de navegação na parte superior da página, abra o console Debug e selecione CMD.
11. Selecione a pasta LogFiles .
12. Inspecione a coluna Modificado e selecione o ícone de lápis para editar o log stdout com a data da última modificação.
13. Quando o arquivo de log é aberto, o erro é exibido.

Desative o registro stdout quando a solução de problemas estiver concluída:

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

Para obter mais informações, consulte ASP.NET ANCM (Core Module) para IIS.

Log de depuração do módulo ASP.NET Core (Serviço de Aplicações do Azure)

O log de depuração do Módulo ASP.NET Core proporciona um registo adicional e mais detalhado. Para habilitar e visualizar logs de stdout:

1. Para habilitar o log de diagnóstico avançado, execute um dos seguintes procedimentos:
   • Siga as instruções em Registos de diagnóstico aprimorados para configurar a aplicação para registos de diagnóstico aprimorados. Reimplemente a aplicação.
   • Adicione o <handlerSettings> mostrado em Registos de diagnóstico melhorados ao arquivo web.config da aplicação em execução usando o console Kudu.
     1. Abra Ferramentas Avançadas na área Ferramentas de Desenvolvimento . Selecione o botão Ir→ . O console Kudu é aberto em uma nova guia ou janela do navegador.
     2. Usando a barra de navegação na parte superior da página, abra o console Debug e selecione CMD.
     3. Abra as pastas para o caminho site>wwwroot. Edite o arquivo web.config selecionando o botão de lápis. Adicione a <handlerSettings> seção 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 Kudu é aberto em uma nova guia ou janela do navegador.
3. Usando a barra de navegação na parte superior da página, abra o console Debug e selecione CMD.
4. Abra as pastas para o caminho site>wwwroot. Se você não forneceu um caminho para o arquivo aspnetcore-debug.log , o arquivo aparecerá na lista. Se você forneceu 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.

Desative o log de depuração quando a solução de problemas estiver concluída:

Para desativar o log de depuração avançado, execute um dos seguintes procedimentos:

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

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

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

Quando um aplicativo responde lentamente ou não responde a uma solicitação, consulte os seguintes artigos:

• Troubleshoot slow web app performance issues in Azure App Service (Resolver problemas de desempenho lento das aplicações Web no Serviço de Aplicações do Azure)
• Usar a Extensão de Site do Diagnóstico de Falhas para capturar despejo de memória para problemas de exceção intermitente ou problemas de desempenho na Aplicação Web do Azure

Monitorização das lâminas

As lâminas de monitoramento fornecem uma experiência de solução de problemas alternativa aos métodos descritos anteriormente no tópico. Esses módulos podem ser usados para diagnosticar erros da "série 500".

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

1. Na secção FERRAMENTAS DE DESENVOLVIMENTO, selecione a folha Extensões.
2. O ASP.NET Core Extensions deve aparecer na lista.
3. Se as extensões não estiverem instaladas, selecione o botão Adicionar .
4. Escolha as ASP.NET extensões principais na 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 registo stdout não estiver ativado, siga estes passos:

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

Prossiga para ativar o log de diagnóstico:

1. No portal do Azure, selecione o separador Logs de Diagnóstico.
2. Selecione a opção On para Log de aplicativos (sistema de arquivos) e mensagens de erro detalhadas. Selecione o botão Guardar na parte superior do painel.
3. Para incluir o rastreamento de solicitações com falha, também conhecido como registo FREB (Failed Request Event Buffering), selecione a opção Ativa para rastreamento de solicitações com falha.
4. Selecione o painel Fluxo de log, que é encontrado imediatamente abaixo do painel Logs de diagnóstico no portal.
5. Faça uma solicitação para o aplicativo.
6. Nos dados do fluxo de log, a causa do erro é indicada.

Certifique-se de desativar o registro stdout quando a solução de problemas estiver concluída.

Para visualizar os registos de rastreamento de solicitações com falha (registos FREB):

1. Navegue até a folha Diagnosticar e resolver problemas no portal do Azure.
2. Selecione Registros de rastreamento de solicitação com falha na área FERRAMENTAS DE SUPORTE da barra lateral.

Consulte a seção Rastreamentos de solicitação com falha do tópico Habilitar log de diagnóstico para aplicativos Web no Serviço de Aplicativo do Azure e as Perguntas frequentes sobre desempenho de aplicativos para aplicativos Web no Azure: Como faço para ativar o rastreamento de solicitação com falha? para obter mais informações.

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

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 o Visualizador de Eventose selecione a aplicação Visualizador de Eventos.
2. Em Visualizador de Eventos, abra o nó Logs do Windows.
3. Selecione Aplicação para abrir o Log de Eventos da Aplicação.
4. Procure pelos erros associados à aplicação com falha. Os erros têm um valor de IIS AspNetCore Module ou IIS Express AspNetCore Module na coluna Source .

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 executando o aplicativo em um prompt de comando no sistema de hospedagem.

Implantação dependente da estrutura

Se a aplicação for uma implementação dependente do framework:

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 quaisquer 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 está a escutar. Usando o host e a postagem padrão, faça uma solicitação para http://localhost:5000/. Se a aplicação responder normalmente no endereço do Kestrel ponto final, é mais provável que o problema esteja relacionado à configuração de hospedagem e menos provável que seja interno à aplicação.

Implantação autônoma

Se o aplicativo for uma implantação independente:

1. Em um prompt de comando, navegue até a pasta de implantação e execute o 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 quaisquer 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 está a escutar. Usando o host e a postagem padrão, faça uma solicitação para http://localhost:5000/. Se a aplicação responder normalmente no endereço do Kestrel ponto final, é mais provável que o problema esteja relacionado à configuração de hospedagem e menos provável que seja interno à aplicação.

ASP.NET Log stdout do módulo principal (IIS)

Para habilitar e visualizar 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 pasta. Para obter instruções sobre como habilitar o MSBuild para criar a pasta logs na implantação automaticamente, consulte o tópico Estrutura de diretórios .
3. Edite o arquivo web.config . Defina stdoutLogEnabled como true e altere o caminho stdoutLogFile para apontar para a pasta logs (por exemplo, .\logs\stdout). stdout no caminho está o prefixo do nome do arquivo de log. Um carimbo de data/hora, ID do processo e extensão de arquivo são adicionados automaticamente quando o log é criado. Usando stdout como o prefixo do nome do arquivo, um arquivo de log típico é chamado stdout_20180205184032_5412.log.
4. Assegure-se de que a identidade do pool de aplicações tem permissões de gravação na pasta logs.
5. Salve o arquivo deweb.config atualizado.
6. Faça uma solicitação para o aplicativo.
7. Navegue até a pasta logs . Localize e abra o log stdout mais recente.
8. Estude o log em busca de erros.

Desative o registro stdout quando a solução de problemas estiver concluída:

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

Para obter mais informações, consulte ASP.NET ANCM (Core Module) para IIS.

ASP.NET log de depuração do módulo principal (IIS)

Adicione as seguintes configurações do 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 identidade do pool de aplicações tem permissões de escrita no local.

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

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

A ASPNETCORE_ENVIRONMENTvariável de ambiente pode ser adicionada a web.config para executar a aplicação no Development ambiente. Contanto que o ambiente não seja substituído na inicialização do aplicativo pelo UseEnvironment construtor de hosts, a configuração da variável de ambiente permite que a Página de Exceção do Desenvolvedor apareça quando o aplicativo for executado.

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

A configuração da variável de ambiente para ASPNETCORE_ENVIRONMENT só é recomendada para uso em servidores de preparo e teste que não estão 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, consulte o elemento filho environmentVariables do aspNetCore.

Obter dados de um aplicativo

Se uma aplicação for capaz de responder a pedidos, obtenha dados de solicitação, conexão e adicionais da aplicação usando middleware terminal em linha. Para obter mais informações e código de exemplo, consulte Solucionar problemas e depurar projetos 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 aplicação, falha de inicialização ou aplicação lenta.

O aplicativo falha ou encontra uma exceção

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

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

2. Corra o EnableDumps PowerShell script:

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

     .\EnableDumps w3wp.exe c:\dumps
     

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

     .\EnableDumps dotnet.exe c:\dumps
     

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

4. Depois que a falha tiver ocorrido, execute o script DisableDumps PowerShell:

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

     .\DisableDumps w3wp.exe
     

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

     .\DisableDumps dotnet.exe
     

Depois que um aplicativo falha e a coleta de despejo é concluída, o aplicativo pode ser encerrado normalmente. O script do PowerShell configura o WER para coletar até cinco despejos por aplicativo.

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

Quando um aplicativo para de responder, mas não falha, falha durante a inicialização ou funciona normalmente, consulte User-Mode Arquivos de despejo: Escolhendo a melhor ferramenta para selecionar uma ferramenta apropriada para produzir o despejo.

Analise o despejo

Um despejo pode ser analisado usando várias abordagens. Para obter mais informações, consulte Analisando um ficheiro de despejo User-Mode.

Limpar caches de pacotes

Um aplicativo em funcionamento pode falhar imediatamente após atualizar o SDK do .NET Core na máquina de desenvolvimento ou alterar as versões do pacote no aplicativo. Em alguns casos, pacotes incoerentes podem quebrar um aplicativo ao executar grandes atualizações. A maioria desses problemas pode ser corrigida seguindo estas instruções:

1. Apague as pastas do compartimento e obj .

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

   A limpeza de caches de pacotes também pode ser realizada com a ferramenta nuget.exe e executando o comando nuget locals all -clear. nuget.exe não é uma instalação integrada com o sistema operacional de desktop Windows e deve ser obtida separadamente do site NuGet.

3. Restaure e reconstrua o projeto.

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

Recursos adicionais

• Solucionar problemas e depurar projetos ASP.NET Core
• Solução de problemas de erro comum para o Serviço de Aplicativo do Azure e o IIS com ASP.NET Core
• Manipular erros no ASP.NET Core
• ASP.NET Módulo Principal (ANCM) para IIS

Documentação de Azure

• Application Insights para ASP.NET Core
• Seção de depuração remota de aplicativos web do Solucionar Problemas de um Aplicativo Web no Serviço de Aplicativo Azure usando o Visual Studio
• Visão geral do diagnóstico do Serviço de Aplicações do Azure
• Como: Monitorar aplicativos 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 erros HTTP de "502 bad gateway" e "503 service unavailable" nas suas aplicações web do Azure
• Troubleshoot slow web app performance issues in Azure App Service (Resolver problemas de desempenho lento das aplicações Web no Serviço de Aplicações do Azure)
• Perguntas frequentes sobre desempenho de aplicativos para aplicativos Web no Azure
• Sandbox do App Web do Azure (limitações de execução do Serviço de Aplicativo)

Documentação do Visual Studio

• Depuração remota ASP.NET Core no IIS no Azure no Visual Studio 2017
• Depuração remota de ASP.NET Core num computador IIS remoto no Visual Studio 2017
• Aprenda a depurar usando o Visual Studio

Documentação do Visual Studio Code

• Depuração com código do Visual Studio

Este artigo fornece informações sobre erros comuns de inicialização de aplicativos 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.

Solucionar problemas no Serviço de Aplicativo do Azure
Fornece conselhos de solução de problemas para aplicativos implantados no 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 executados no IIS Express localmente. As diretrizes se aplicam tanto a implantações do Windows Server quanto do ambiente de trabalho do Windows.

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

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

Erros de arranque da aplicação

No Visual Studio, um projeto ASP.NET Core assume como padrão a hospedagem do IIS Express durante a depuração. Uma falha de processo 502.5 que ocorre ao depurar localmente pode ser diagnosticada usando as recomendações deste 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 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 de publicação 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 seu conteúdo está correto.
   • Ao hospedar no Serviço de Aplicativo do Azure, confirme se o aplicativo está implantado na D:\home\site\wwwroot pasta.
   • Quando o aplicativo for hospedado pelo IIS, confirme se o aplicativo foi 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 foram 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 ASP.NET estrutura de diretórios Core. Para obter mais informações sobre o arquivo web.config, consulte ASP.NET ANCM (Core Module) para IIS.

500 Erro interno do servidor

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

Este erro ocorre dentro do código do aplicativo durante a inicialização ou ao criar uma resposta. A resposta pode não conter conteúdo, ou a resposta pode aparecer como um erro de servidor interno 500 no navegador. O Log de Eventos do Aplicativo geralmente indica que o aplicativo foi iniciado normalmente. Do ponto de vista do servidor, isso está correto. O aplicativo foi iniciado, mas não pode gerar uma resposta válida. Execute o aplicativo em um prompt de comando no servidor ou habilite o log stdout do ASP.NET Core Module para solucionar o problema.

Este erro também pode ocorrer quando o .NET Core Hosting Bundle não está instalado ou está corrompido. Instalar ou reparar a instalação do .NET Core Hosting Bundle (para IIS) ou Visual Studio (para IIS Express) pode corrigir o problema.

Falha no Processo 502.5

O processo de trabalho falha. O aplicativo não inicia.

O Módulo ASP.NET Core tenta iniciar o processo de trabalho, mas não consegue iniciar. A causa de uma falha de inicialização do processo geralmente pode ser determinada a partir de entradas no log de eventos do aplicativo e no log stdout do módulo principal do ASP.NET.

Uma falha comum ocorre quando a aplicação está mal configurada devido ao direcionamento de uma versão que não está presente da estrutura partilhada do ASP.NET Core. Verifique quais versões da estrutura compartilhada do ASP.NET Core estão instaladas na máquina de destino. A estrutura partilhada é o conjunto de assemblies (arquivos .dll) instalados na máquina e referenciados por um(a) metapacote como Microsoft.AspNetCore.App. A referência do metapacote pode especificar uma versão mínima necessária. Para obter mais informações, consulte A estrutura compartilhada.

A página de erro Falha de processo 502.5 é retornada quando uma hospedagem ou configuração incorreta 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 iniciar porque o assembly do aplicativo (.dll) não pôde ser carregado.

Este erro ocorre quando há uma incompatibilidade 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 nos Pools de Aplicativos do Gerenciador do IIS.
2. Selecione Configurações avançadas em Editar pool de aplicativos no painel Ações .
3. Definir Ativar 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 do <Platform> MSBuild no ficheiro de projeto e o bitness publicado do aplicativo.

Reinício da ligação

Se ocorrer um erro depois que os cabeçalhos forem enviados, é tarde demais para o servidor enviar um erro interno do servidor 500 quando ocorrer um erro. Isso geralmente acontece quando ocorre um erro durante a serialização de objetos complexos para uma resposta. Esse tipo de erro aparece como um erro de redefinição de conexão no cliente. O log de aplicativos pode ajudar a solucionar esses tipos de erros.

Limites de inicialização padrão

O ASP.NET Core Module é configurado com um startupTimeLimit padrão de 120 segundos. Quando deixado no valor padrão, um aplicativo pode levar até dois minutos para ser iniciado antes que o módulo registre uma falha de processo. Para obter informações sobre como configurar o módulo, consulte Atributos do elemento aspNetCore.

Solucionar problemas no 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 resolver problemas no portal do Azure:

1. No portal do Azure, abra o aplicativo nos Serviços de Aplicativo.
2. Selecione Diagnosticar e resolver 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 Source .

Uma alternativa para usar o painel Diagnosticar e resolver problemas é examinar o ficheiro de registo de eventos da aplicação diretamente usando Kudu:

1. Abra Ferramentas Avançadas na área Ferramentas de Desenvolvimento . Selecione o botão Ir→ . O console Kudu é aberto em uma nova guia ou janela do navegador.
2. Usando a barra de navegação na parte superior da página, abra o console Debug e selecione CMD.
3. Abra a pasta LogFiles .
4. Selecione o ícone de lápis ao lado do eventlog.xml arquivo.
5. Examine o registo. Desloque-se para a parte inferior do registo 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 Kudu Remote Execution Console para descobrir o erro:

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

Testar um aplicativo de 32 bits (x86)

Lançamento atual

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

   • Se a aplicação for uma implementação dependente do framework:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Se o aplicativo for uma implantação independente:

     {ASSEMBLY NAME}.exe
     

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

Implementação dependente de framework em execução numa versão prévia

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

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

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

Testar uma aplicação de 64 bits (x64)

Lançamento atual

• Se a aplicação for uma implementação dependente do framework 64 bits (x64):
  1. cd D:\Program Files\dotnet
  2. Execute a aplicação: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Se o aplicativo for uma implantação independente:
  1. cd D:\home\site\wwwroot
  2. Execute a aplicação: {ASSEMBLY NAME}.exe

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

Implementação dependente de framework em execução numa versão prévia

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

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

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

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

O log stdout do módulo principal do ASP.NET geralmente registra mensagens de erro úteis não encontradas no log de eventos do aplicativo. Para habilitar e visualizar logs de stdout:

1. Navegue até a folha Diagnosticar e resolver problemas no portal do Azure.
2. Em SELECT PROBLEM CATEGORY, selecione o botão Web App Down.
3. Em Soluções sugeridas>Ativar o redirecionamento de log do Stdout, selecione o botão para Abrir a Consola Kudu para editar o Web.Config.
4. No Console de Diagnóstico do Kudu, abra as pastas até o caminho site>wwwroot. Desloque-se para baixo para revelar o ficheiroweb.config na parte inferior da lista.
5. Clique no ícone de lápis ao lado do arquivo web.config .
6. Configure stdoutLogEnabled para true e defina o caminho do stdoutLogFile para: \\?\%home%\LogFiles\stdout.
7. Selecione Salvar para salvar o arquivo deweb.config atualizado.
8. Faça uma solicitação para o aplicativo.
9. Retorne ao portal do Azure. Selecione a seção Ferramentas Avançadas na área Ferramentas de Desenvolvimento. Selecione o botão Ir→ . O console Kudu é aberto em uma nova guia ou janela do navegador.
10. Usando a barra de navegação na parte superior da página, abra o console Debug e selecione CMD.
11. Selecione a pasta LogFiles .
12. Inspecione a coluna Modificado e selecione o ícone de lápis para editar o log stdout com a data da última modificação.
13. Quando o arquivo de log é aberto, o erro é exibido.

Desative o registro stdout quando a solução de problemas estiver concluída:

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

Para obter mais informações, consulte ASP.NET ANCM (Core Module) para IIS.

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

Quando um aplicativo responde lentamente ou não responde a uma solicitação, consulte os seguintes artigos:

• Troubleshoot slow web app performance issues in Azure App Service (Resolver problemas de desempenho lento das aplicações Web no Serviço de Aplicações do Azure)
• Usar a Extensão de Site do Diagnóstico de Falhas para capturar despejo de memória para problemas de exceção intermitente ou problemas de desempenho na Aplicação Web do Azure

Monitorização das lâminas

As lâminas de monitoramento fornecem uma experiência de solução de problemas alternativa aos métodos descritos anteriormente no tópico. Esses módulos podem ser usados para diagnosticar erros da "série 500".

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

1. Na secção FERRAMENTAS DE DESENVOLVIMENTO, selecione a folha Extensões.
2. O ASP.NET Core Extensions deve aparecer na lista.
3. Se as extensões não estiverem instaladas, selecione o botão Adicionar .
4. Escolha as ASP.NET extensões principais na 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 registo stdout não estiver ativado, siga estes passos:

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

Prossiga para ativar o log de diagnóstico:

1. No portal do Azure, selecione o separador Logs de Diagnóstico.
2. Selecione a opção On para Log de aplicativos (sistema de arquivos) e mensagens de erro detalhadas. Selecione o botão Guardar na parte superior do painel.
3. Para incluir o rastreamento de solicitações com falha, também conhecido como registo FREB (Failed Request Event Buffering), selecione a opção Ativa para rastreamento de solicitações com falha.
4. Selecione o painel Fluxo de log, que é encontrado imediatamente abaixo do painel Logs de diagnóstico no portal.
5. Faça uma solicitação para o aplicativo.
6. Nos dados do fluxo de log, a causa do erro é indicada.

Certifique-se de desativar o registro stdout quando a solução de problemas estiver concluída.

Para visualizar os registos de rastreamento de solicitações com falha (registos FREB):

1. Navegue até a folha Diagnosticar e resolver problemas no portal do Azure.
2. Selecione Registros de rastreamento de solicitação com falha na área FERRAMENTAS DE SUPORTE da barra lateral.

Consulte a seção Rastreamentos de solicitação com falha do tópico Habilitar log de diagnóstico para aplicativos Web no Serviço de Aplicativo do Azure e as Perguntas frequentes sobre desempenho de aplicativos para aplicativos Web no Azure: Como faço para ativar o rastreamento de solicitação com falha? para obter mais informações.

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

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 o Visualizador de Eventose selecione a aplicação Visualizador de Eventos.
2. Em Visualizador de Eventos, abra o nó Logs do Windows.
3. Selecione Aplicação para abrir o Log de Eventos da Aplicação.
4. Procure pelos erros associados à aplicação com falha. Os erros têm um valor de IIS AspNetCore Module ou IIS Express AspNetCore Module na coluna Source .

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 executando o aplicativo em um prompt de comando no sistema de hospedagem.

Implantação dependente da estrutura

Se a aplicação for uma implementação dependente do framework:

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 quaisquer 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 está a escutar. Usando o host e a postagem padrão, faça uma solicitação para http://localhost:5000/. Se a aplicação responder normalmente no endereço do Kestrel ponto final, é mais provável que o problema esteja relacionado à configuração de hospedagem e menos provável que seja interno à aplicação.

Implantação autônoma

Se o aplicativo for uma implantação independente:

1. Em um prompt de comando, navegue até a pasta de implantação e execute o 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 quaisquer 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 está a escutar. Usando o host e a postagem padrão, faça uma solicitação para http://localhost:5000/. Se a aplicação responder normalmente no endereço do Kestrel ponto final, é mais provável que o problema esteja relacionado à configuração de hospedagem e menos provável que seja interno à aplicação.

ASP.NET Log stdout do módulo principal (IIS)

Para habilitar e visualizar 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 pasta. Para obter instruções sobre como habilitar o MSBuild para criar a pasta logs na implantação automaticamente, consulte o tópico Estrutura de diretórios .
3. Edite o arquivo web.config . Defina stdoutLogEnabled como true e altere o caminho stdoutLogFile para apontar para a pasta logs (por exemplo, .\logs\stdout). stdout no caminho está o prefixo do nome do arquivo de log. Um carimbo de data/hora, ID do processo e extensão de arquivo são adicionados automaticamente quando o log é criado. Usando stdout como o prefixo do nome do arquivo, um arquivo de log típico é chamado stdout_20180205184032_5412.log.
4. Assegure-se de que a identidade do pool de aplicações tem permissões de gravação na pasta logs.
5. Salve o arquivo deweb.config atualizado.
6. Faça uma solicitação para o aplicativo.
7. Navegue até a pasta logs . Localize e abra o log stdout mais recente.
8. Estude o log em busca de erros.

Desative o registro stdout quando a solução de problemas estiver concluída:

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

Para obter mais informações, consulte ASP.NET ANCM (Core Module) para IIS.

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

A ASPNETCORE_ENVIRONMENTvariável de ambiente pode ser adicionada a web.config para executar a aplicação no Development ambiente. Contanto que o ambiente não seja substituído na inicialização do aplicativo pelo UseEnvironment construtor de hosts, a configuração da variável de ambiente permite que a Página de Exceção do Desenvolvedor apareça quando o aplicativo for executado.

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

A configuração da variável de ambiente para ASPNETCORE_ENVIRONMENT só é recomendada para uso em servidores de preparo e teste que não estão 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, consulte o elemento filho environmentVariables do aspNetCore.

Obter dados de um aplicativo

Se uma aplicação for capaz de responder a pedidos, obtenha dados de solicitação, conexão e adicionais da aplicação usando middleware terminal em linha. Para obter mais informações e código de exemplo, consulte Solucionar problemas e depurar projetos 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 aplicação, falha de inicialização ou aplicação lenta.

O aplicativo falha ou encontra uma exceção

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

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

2. Corra o EnableDumps PowerShell script:

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

     .\EnableDumps w3wp.exe c:\dumps
     

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

     .\EnableDumps dotnet.exe c:\dumps
     

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

4. Depois que a falha tiver ocorrido, execute o script DisableDumps PowerShell:

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

     .\DisableDumps w3wp.exe
     

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

     .\DisableDumps dotnet.exe
     

Depois que um aplicativo falha e a coleta de despejo é concluída, o aplicativo pode ser encerrado normalmente. O script do PowerShell configura o WER para coletar até cinco despejos por aplicativo.

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

Quando um aplicativo para de responder, mas não falha, falha durante a inicialização ou funciona normalmente, consulte User-Mode Arquivos de despejo: Escolhendo a melhor ferramenta para selecionar uma ferramenta apropriada para produzir o despejo.

Analise o despejo

Um despejo pode ser analisado usando várias abordagens. Para obter mais informações, consulte Analisando um ficheiro de despejo User-Mode.

Limpar caches de pacotes

Um aplicativo em funcionamento pode falhar imediatamente após atualizar o SDK do .NET Core na máquina de desenvolvimento ou alterar as versões do pacote no aplicativo. Em alguns casos, pacotes incoerentes podem quebrar um aplicativo ao executar grandes atualizações. A maioria desses problemas pode ser corrigida seguindo estas instruções:

1. Apague as pastas do compartimento e obj .

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

   A limpeza de caches de pacotes também pode ser realizada com a ferramenta nuget.exe e executando o comando nuget locals all -clear. nuget.exe não é uma instalação integrada com o sistema operacional de desktop Windows e deve ser obtida separadamente do site NuGet.

3. Restaure e reconstrua o projeto.

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

Recursos adicionais

• Solucionar problemas e depurar projetos ASP.NET Core
• Solução de problemas de erro comum para o Serviço de Aplicativo do Azure e o IIS com ASP.NET Core
• Manipular erros no ASP.NET Core
• ASP.NET Módulo Principal (ANCM) para IIS

Documentação de Azure

• Application Insights para ASP.NET Core
• Seção de depuração remota de aplicativos web do Solucionar Problemas de um Aplicativo Web no Serviço de Aplicativo Azure usando o Visual Studio
• Visão geral do diagnóstico do Serviço de Aplicações do Azure
• Como: Monitorar aplicativos 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 erros HTTP de "502 bad gateway" e "503 service unavailable" nas suas aplicações web do Azure
• Troubleshoot slow web app performance issues in Azure App Service (Resolver problemas de desempenho lento das aplicações Web no Serviço de Aplicações do Azure)
• Perguntas frequentes sobre desempenho de aplicativos para aplicativos Web no Azure
• Sandbox do App Web do Azure (limitações de execução do Serviço de Aplicativo)

Documentação do Visual Studio

• Depuração remota ASP.NET Core no IIS no Azure no Visual Studio 2017
• Depuração remota de ASP.NET Core num computador IIS remoto no Visual Studio 2017
• Aprenda a depurar usando o Visual Studio

Documentação do Visual Studio Code

• Depuração com código do Visual Studio

Este artigo fornece informações sobre erros comuns de inicialização de aplicativos 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.

Solucionar problemas no Serviço de Aplicativo do Azure
Fornece conselhos de solução de problemas para aplicativos implantados no 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 executados no IIS Express localmente. As diretrizes se aplicam tanto a implantações do Windows Server quanto do ambiente de trabalho do Windows.

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

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

Erros de arranque da aplicação

No Visual Studio, o servidor padrão do projeto 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 ocorrem ao depurar localmente com o IIS Express pode ser diagnosticada usando as recomendações deste 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 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 de publicação 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 seu conteúdo está correto.
   • Ao hospedar no Serviço de Aplicativo do Azure, confirme se o aplicativo está implantado na D:\home\site\wwwroot pasta.
   • Quando o aplicativo for hospedado pelo IIS, confirme se o aplicativo foi 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 foram 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 ASP.NET estrutura de diretórios Core. Para obter mais informações sobre o arquivo web.config, consulte ASP.NET ANCM (Core Module) para IIS.

500 Erro interno do servidor

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

Este erro ocorre dentro do código do aplicativo durante a inicialização ou ao criar uma resposta. A resposta pode não conter conteúdo, ou a resposta pode aparecer como um erro de servidor interno 500 no navegador. O Log de Eventos do Aplicativo geralmente indica que o aplicativo foi iniciado normalmente. Do ponto de vista do servidor, isso está correto. O aplicativo foi iniciado, mas não pode gerar uma resposta válida. Execute o aplicativo em um prompt de comando no servidor ou habilite o log stdout do ASP.NET Core Module para solucionar o problema.

Este erro também pode ocorrer quando o .NET Hosting Bundle não está instalado ou está corrompido. Instalar ou reparar a instalação do .NET Hosting Bundle (para IIS) ou Visual Studio (para IIS Express) pode corrigir o problema.

Falha de carga do manipulador de In-Process 500.0

O processo de trabalho falha. O aplicativo não inicia.

Ocorreu um erro desconhecido ao carregar componentes do módulo ASP.NET Core. Efetue uma das seguintes ações:

• Entre em contato com o Suporte da Microsoft (selecione Ferramentas de Desenvolvimento e, em seguida, ASP.NET Core).
• Faça uma pergunta sobre Stack Overflow.
• Registre um problema em nosso repositório GitHub.

500.30 Falha de inicialização do In-Process

O processo de trabalho falha. O aplicativo não inicia.

O ASP.NET Core Module tenta iniciar o .NET CLR em processo, mas não consegue iniciar. A causa de uma falha de inicialização do processo geralmente pode ser determinada a partir de entradas no log de eventos do aplicativo e no log stdout do módulo principal do ASP.NET.

Condições comuns de falha:

• A aplicação está mal configurada por visar uma versão do framework partilhado do ASP.NET Core que não está presente. Verifique quais versões da estrutura compartilhada do ASP.NET Core estão instaladas na máquina de destino.
• Usando o Azure Key Vault, falta de permissões para o Key Vault. Verifique as políticas de acesso no Cofre da Chave de destino para garantir que as permissões corretas sejam concedidas.

500.31 ANCM falha ao encontrar dependências nativas

O processo de trabalho falha. O aplicativo não inicia.

O Módulo ASP.NET Core tenta iniciar o runtime do .NET em modo in-processo, mas ele não consegue iniciar. A causa mais comum dessa falha de arranque é quando o runtime Microsoft.NETCore.App ou o Microsoft.AspNetCore.App não está instalado. Se a aplicação for implantada para destinar o ASP.NET Core 3.0 e essa versão não estiver disponível no computador, esse erro ocorrerá. Segue-se 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 do .NET instaladas e a versão solicitada pelo aplicativo. Para corrigir esse erro:

• Instale a versão apropriada do .NET no computador.
• Altere o aplicativo para direcionar uma versão do .NET presente no computador.
• Publique o aplicativo como uma implantação independente.

Quando executado em desenvolvimento (a ASPNETCORE_ENVIRONMENT variável de ambiente é 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 ANCM falhou ao carregar DLL

O processo de trabalho falha. O aplicativo não inicia.

A causa mais comum para esse erro é que o aplicativo é publicado para uma arquitetura de processador incompatível. Se o processo de trabalho estiver sendo executado como um aplicativo de 32 bits e o aplicativo tiver sido publicado para o destino de 64 bits, esse erro ocorrerá.

Para corrigir esse erro:

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

500.33 Falha de carga do manipulador de solicitações ANCM

O processo de trabalho falha. O aplicativo não inicia.

O aplicativo não fez referência à Microsoft.AspNetCore.App estrutura. Somente os aplicativos direcionados à Microsoft.AspNetCore.App estrutura podem ser hospedados pelo ASP.NET Core Module.

Para corrigir esse erro, confirme se o aplicativo está direcionando a Microsoft.AspNetCore.App estrutura. Verifique o .runtimeconfig.json para confirmar o framework visado pela aplicação.

500.34 Modelos de hospedagem mista ANCM não suportados

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

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

500.35 ANCM Múltiplas Aplicações em Processamento 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 out-of-process ANCM

O manipulador de solicitações fora do processo, aspnetcorev2_outofprocess.dll, não está ao lado do arquivo aspnetcorev2.dll . Isso indica uma instalação corrompida do ASP.NET Core Module.

Para corrigir esse erro, repare a instalação do .NET Hosting Bundle (para IIS) ou Visual Studio (para IIS Express).

500.37 ANCM falhou ao iniciar dentro do limite de tempo de arranque

ANCM falhou ao iniciar dentro do limite de tempo de inicialização fornecido. Por padrão, o tempo limite é de 120 segundos.

Este erro pode ocorrer ao iniciar um grande número de aplicativos na mesma máquina. Verifique se há picos de uso de CPU/memória no servidor durante a inicialização. Pode ser necessário escalonar o processo de inicialização de vários aplicativos.

500.38 DLL de aplicativo ANCM não encontrada

ANCM não conseguiu localizar a DLL do aplicativo, que deve estar ao lado do executável.

Este 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 no processo do IIS existente. 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. Desative a publicação de arquivo único definindo a PublishSingleFile propriedade MSBuild como false.
2. Altere para o modelo de hospedagem independente do processo definindo a AspNetCoreHostingModel propriedade MSBuild como OutOfProcess.

Falha no Processo 502.5

O processo de trabalho falha. O aplicativo não inicia.

O Módulo ASP.NET Core tenta iniciar o processo de trabalho, mas não consegue iniciar. A causa de uma falha de inicialização do processo geralmente pode ser determinada a partir de entradas no log de eventos do aplicativo e no log stdout do módulo principal do ASP.NET.

Uma falha comum ocorre quando a aplicação está mal configurada devido ao direcionamento de uma versão que não está presente da estrutura partilhada do ASP.NET Core. Verifique quais versões da estrutura compartilhada do ASP.NET Core estão instaladas na máquina de destino. A estrutura partilhada é o conjunto de assemblies (arquivos .dll) instalados na máquina e referenciados por um(a) metapacote como Microsoft.AspNetCore.App. A referência do metapacote pode especificar uma versão mínima necessária. Para obter mais informações, consulte A estrutura compartilhada.

A página de erro Falha de processo 502.5 é retornada quando uma hospedagem ou configuração incorreta 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 iniciar porque o assembly do aplicativo (.dll) não pôde ser carregado.

Este erro ocorre quando há uma incompatibilidade 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 nos Pools de Aplicativos do Gerenciador do IIS.
2. Selecione Configurações avançadas em Editar pool de aplicativos no painel Ações .
3. Definir Ativar 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 do <Platform> MSBuild no ficheiro de projeto e o bitness 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 falhou ao iniciar porque um serviço do Windows falhou ao carregar.

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

Reinício da ligação

Se ocorrer um erro depois que os cabeçalhos forem enviados, é tarde demais para o servidor enviar um erro interno do servidor 500 quando ocorrer um erro. Isso geralmente acontece quando ocorre um erro durante a serialização de objetos complexos para uma resposta. Esse tipo de erro aparece como um erro de redefinição de conexão no cliente. O log de aplicativos pode ajudar a solucionar esses tipos de erros.

Limites de inicialização padrão

O ASP.NET Core Module é configurado com um startupTimeLimit padrão de 120 segundos. Quando deixado no valor padrão, um aplicativo pode levar até dois minutos para ser iniciado antes que o módulo registre uma falha de processo. Para obter informações sobre como configurar o módulo, consulte Atributos do elemento aspNetCore.

Solucionar problemas no Serviço de Aplicativo do Azure

Fluxo de log dos Serviços de Aplicativo do Azure

O Log dos Serviços de Aplicativo do Azure transmite informações de log à medida que ocorrem. Para visualizar os logs de streaming:

1. No portal do Azure, abra o aplicativo nos Serviços de Aplicativo.
2. No painel esquerdo, navegue até Monitorização>Logs do Serviço de Aplicações.
3. Selecione Sistema de arquivos para registro em log do servidor Web. Opcionalmente, habilite o log do aplicativo.
4. No painel esquerdo, navegue até Fluxo de Log de Monitoramento> e selecione Logs de aplicativos ou Logs de servidor Web.

As imagens a seguir 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 resolver problemas no portal do Azure:

1. No portal do Azure, abra o aplicativo nos Serviços de Aplicativo.
2. Selecione Diagnosticar e resolver 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 Source .

Uma alternativa para usar o painel Diagnosticar e resolver problemas é examinar o ficheiro de registo de eventos da aplicação diretamente usando Kudu:

1. Abra Ferramentas Avançadas na área Ferramentas de Desenvolvimento . Selecione o botão Ir→ . O console Kudu é aberto em uma nova guia ou janela do navegador.
2. Usando a barra de navegação na parte superior da página, abra o console Debug e selecione CMD.
3. Abra a pasta LogFiles .
4. Selecione o ícone de lápis ao lado do eventlog.xml arquivo.
5. Examine o registo. Desloque-se para a parte inferior do registo 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 Kudu Remote Execution Console para descobrir o erro:

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

Testar um aplicativo de 32 bits (x86)

Lançamento atual

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

   • Se a aplicação for uma implementação dependente do framework:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Se o aplicativo for uma implantação independente:

     {ASSEMBLY NAME}.exe
     

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

Implementação dependente de framework em execução numa versão prévia

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

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

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

Testar uma aplicação de 64 bits (x64)

Lançamento atual

• Se a aplicação for uma implementação dependente do framework 64 bits (x64):
  1. cd D:\Program Files\dotnet
  2. Execute a aplicação: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Se o aplicativo for uma implantação independente:
  1. cd D:\home\site\wwwroot
  2. Execute a aplicação: {ASSEMBLY NAME}.exe

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

Implementação dependente de framework em execução numa versão prévia

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

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

A saída da consola na aplicação, a mostrar os erros, é encaminhada para a consola do Kudu.

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

O log stdout do módulo principal do ASP.NET geralmente registra mensagens de erro úteis não encontradas no log de eventos do aplicativo. Para habilitar e visualizar logs de stdout:

1. No Portal do Azure, navegue até o aplicativo Web.
2. Na folha Serviço de Aplicativo , digite kudu na caixa de pesquisa.
3. Selecione Advanced Tools>Go.
4. Selecione Console de depuração CMD>.
5. Navegue até site/wwwroot
6. Selecione o ícone de lápis para editar o arquivo web.config .
7. No elemento <aspNetCore />, defina stdoutLogEnabled="true" e selecione Guardar.

Desative o registro stdout quando a solução de problemas estiver concluída definindo stdoutLogEnabled="false".

Para obter mais informações, consulte ASP.NET ANCM (Core Module) para IIS.

Log de depuração do módulo ASP.NET Core (Serviço de Aplicações do Azure)

O log de depuração do Módulo ASP.NET Core proporciona um registo adicional e mais detalhado. Para habilitar e visualizar logs de stdout:

1. Para habilitar o log de diagnóstico avançado, execute um dos seguintes procedimentos:
   • Siga as instruções em Registos de diagnóstico aprimorados para configurar a aplicação para registos de diagnóstico aprimorados. Reimplemente a aplicação.
   • Adicione o <handlerSettings> mostrado em Registos de diagnóstico melhorados ao arquivo web.config da aplicação em execução usando o console Kudu.
     1. Abra Ferramentas Avançadas na área Ferramentas de Desenvolvimento . Selecione o botão Ir→ . O console Kudu é aberto em uma nova guia ou janela do navegador.
     2. Usando a barra de navegação na parte superior da página, abra o console Debug e selecione CMD.
     3. Abra as pastas para o caminho site>wwwroot. Edite o arquivo web.config selecionando o botão de lápis. Adicione a <handlerSettings> seção 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 Kudu é aberto em uma nova guia ou janela do navegador.
3. Usando a barra de navegação na parte superior da página, abra o console Debug e selecione CMD.
4. Abra as pastas para o caminho site>wwwroot. Se você não forneceu um caminho para o arquivo aspnetcore-debug.log , o arquivo aparecerá na lista. Se você forneceu 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.

Desative o log de depuração quando a solução de problemas estiver concluída:

Para desativar o log de depuração avançado, execute um dos seguintes procedimentos:

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

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

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

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

Monitorização das lâminas

As lâminas de monitoramento fornecem uma experiência de solução de problemas alternativa aos métodos descritos anteriormente no tópico. Esses módulos podem ser usados para diagnosticar erros da "série 500".

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

1. Na secção FERRAMENTAS DE DESENVOLVIMENTO, selecione a folha Extensões.
2. O ASP.NET Core Extensions deve aparecer na lista.
3. Se as extensões não estiverem instaladas, selecione o botão Adicionar .
4. Escolha as ASP.NET extensões principais na 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 registo stdout não estiver ativado, siga estes passos:

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

Prossiga para ativar o log de diagnóstico:

1. No portal do Azure, selecione o separador Logs de Diagnóstico.
2. Selecione a opção On para Log de aplicativos (sistema de arquivos) e mensagens de erro detalhadas. Selecione o botão Guardar na parte superior do painel.
3. Para incluir o rastreamento de solicitações com falha, também conhecido como registo FREB (Failed Request Event Buffering), selecione a opção Ativa para rastreamento de solicitações com falha.
4. Selecione o painel Fluxo de log, que é encontrado imediatamente abaixo do painel Logs de diagnóstico no portal.
5. Faça uma solicitação para o aplicativo.
6. Nos dados do fluxo de log, a causa do erro é indicada.

Certifique-se de desativar o registro stdout quando a solução de problemas estiver concluída.

Para visualizar os registos de rastreamento de solicitações com falha (registos FREB):

1. Navegue até a folha Diagnosticar e resolver problemas no portal do Azure.
2. Selecione Registros de rastreamento de solicitação com falha na área FERRAMENTAS DE SUPORTE da barra lateral.

Consulte a seção Rastreamentos de solicitação com falha do tópico Habilitar log de diagnóstico para aplicativos Web no Serviço de Aplicativo do Azure e as Perguntas frequentes sobre desempenho de aplicativos para aplicativos Web no Azure: Como faço para ativar o rastreamento de solicitação com falha? para obter mais informações.

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

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 o Visualizador de Eventose selecione a aplicação Visualizador de Eventos.
2. Em Visualizador de Eventos, abra o nó Logs do Windows.
3. Selecione Aplicação para abrir o Log de Eventos da Aplicação.
4. Procure pelos erros associados à aplicação com falha. Os erros têm um valor de IIS AspNetCore Module ou IIS Express AspNetCore Module na coluna Source .

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 executando o aplicativo em um prompt de comando no sistema de hospedagem.

Implantação dependente da estrutura

Se a aplicação for uma implementação dependente do framework:

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 quaisquer 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 está a escutar. Usando o host e a postagem padrão, faça uma solicitação para http://localhost:5000/. Se a aplicação responder normalmente no endereço do Kestrel ponto final, é mais provável que o problema esteja relacionado à configuração de hospedagem e menos provável que seja interno à aplicação.

Implantação autônoma

Se o aplicativo for uma implantação independente:

1. Em um prompt de comando, navegue até a pasta de implantação e execute o 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 quaisquer 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 está a escutar. Usando o host e a postagem padrão, faça uma solicitação para http://localhost:5000/. Se a aplicação responder normalmente no endereço do Kestrel ponto final, é mais provável que o problema esteja relacionado à configuração de hospedagem e menos provável que seja interno à aplicação.

ASP.NET Log stdout do módulo principal (IIS)

Para habilitar e visualizar 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 pasta. Para obter instruções sobre como habilitar o MSBuild para criar a pasta logs na implantação automaticamente, consulte o tópico Estrutura de diretórios .
3. Edite o arquivo web.config . Defina stdoutLogEnabled como true e altere o caminho stdoutLogFile para apontar para a pasta logs (por exemplo, .\logs\stdout). stdout no caminho está o prefixo do nome do arquivo de log. Um carimbo de data/hora, ID do processo e extensão de arquivo são adicionados automaticamente quando o log é criado. Usando stdout como o prefixo do nome do arquivo, um arquivo de log típico é chamado stdout_20180205184032_5412.log.
4. Assegure-se de que a identidade do pool de aplicações tem permissões de gravação na pasta logs.
5. Salve o arquivo deweb.config atualizado.
6. Faça uma solicitação para o aplicativo.
7. Navegue até a pasta logs . Localize e abra o log stdout mais recente.
8. Estude o log em busca de erros.

Desative o registro stdout quando a solução de problemas estiver concluída:

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

Para obter mais informações, consulte ASP.NET ANCM (Core Module) para IIS.

ASP.NET log de depuração do módulo principal (IIS)

Adicione as seguintes configurações do 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 identidade do pool de aplicações tem permissões de escrita no local.

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

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

A ASPNETCORE_ENVIRONMENTvariável de ambiente pode ser adicionada a web.config para executar a aplicação no Development ambiente. Contanto que o ambiente não seja substituído na inicialização do aplicativo pelo UseEnvironment construtor de hosts, a configuração da variável de ambiente permite que a Página de Exceção do Desenvolvedor apareça quando o aplicativo for executado.

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

A configuração da variável de ambiente para ASPNETCORE_ENVIRONMENT só é recomendada para uso em servidores de preparo e teste que não estão 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, consulte o elemento filho environmentVariables do aspNetCore.

Obter dados de um aplicativo

Se uma aplicação for capaz de responder a pedidos, obtenha dados de solicitação, conexão e adicionais da aplicação usando middleware terminal em linha. Para obter mais informações e código de exemplo, consulte Solucionar problemas e depurar projetos 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 aplicação, falha de inicialização ou aplicação lenta.

O aplicativo falha ou encontra uma exceção

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

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

2. Corra o EnableDumps PowerShell script:

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

     .\EnableDumps w3wp.exe c:\dumps
     

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

     .\EnableDumps dotnet.exe c:\dumps
     

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

4. Depois que a falha tiver ocorrido, execute o script DisableDumps PowerShell:

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

     .\DisableDumps w3wp.exe
     

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

     .\DisableDumps dotnet.exe
     

Depois que um aplicativo falha e a coleta de despejo é concluída, o aplicativo pode ser encerrado normalmente. O script do PowerShell configura o WER para coletar até cinco despejos por aplicativo.

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

Quando um aplicativo para de responder, mas não falha, falha durante a inicialização ou funciona normalmente, consulte User-Mode Arquivos de despejo: Escolhendo a melhor ferramenta para selecionar uma ferramenta apropriada para produzir o despejo.

Analise o despejo

Um despejo pode ser analisado usando várias abordagens. Para obter mais informações, consulte Analisando um ficheiro de despejo User-Mode.

Limpar caches de pacotes

Um aplicativo em funcionamento pode falhar imediatamente após atualizar o SDK do .NET na máquina de desenvolvimento ou alterar as versões do pacote dentro do aplicativo. Em alguns casos, pacotes incoerentes podem quebrar um aplicativo ao executar grandes atualizações. A maioria desses problemas pode ser corrigida seguindo estas instruções:

1. Apague as pastas do compartimento e obj .

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

   A limpeza de caches de pacotes também pode ser realizada com a ferramenta nuget.exe e executando o comando nuget locals all -clear. nuget.exe não é uma instalação integrada com o sistema operacional de desktop Windows e deve ser obtida separadamente do site NuGet.

3. Restaure e reconstrua 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 ASP.NET Core
• Solução de problemas de erro comum para o Serviço de Aplicativo do Azure e o IIS com ASP.NET Core
• Manipular erros no ASP.NET Core
• ASP.NET Módulo Principal (ANCM) para IIS

Documentação de Azure

• Application Insights para ASP.NET Core
• Seção de depuração remota de aplicativos web do Solucionar Problemas de um Aplicativo Web no Serviço de Aplicativo Azure usando o Visual Studio
• Visão geral do diagnóstico do Serviço de Aplicações do Azure
• Como: Monitorar aplicativos 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 erros HTTP de "502 bad gateway" e "503 service unavailable" nas suas aplicações web do Azure
• Troubleshoot slow web app performance issues in Azure App Service (Resolver problemas de desempenho lento das aplicações Web no Serviço de Aplicações do Azure)
• Perguntas frequentes sobre desempenho de aplicativos para aplicativos Web no Azure
• Sandbox do App Web do Azure (limitações de execução do Serviço de Aplicativo)

Documentação do Visual Studio

• Depuração remota ASP.NET Core no IIS no Azure no Visual Studio 2017
• Depuração remota de ASP.NET Core num computador IIS remoto no Visual Studio 2017
• Aprenda a depurar usando o Visual Studio

Documentação do Visual Studio Code

• Depuração com código do Visual Studio