Aumentar as chances de um problema de desempenho ser corrigido
A ferramenta "Relatar um problema" é muito usada pelos usuários do Visual Studio para relatar uma série de problemas. A equipe do Visual Studio detecta tendências de falha e lentidão nos comentários dos usuários e aborda os problemas que afetam diversos usuários. Quanto mais acionável for um tíquete de comentários específico, maior a probabilidade de ele ser diagnosticado e resolvido rapidamente pela equipe de produtos. Este documento descreve as melhores práticas ao relatar problemas de falha ou lentidão para torná-los mais acionáveis.
Práticas recomendadas gerais
O Visual Studio é uma plataforma grande e complexa que dá suporte a uma infinidade de linguagens, tipos de projeto, plataformas e muito mais. O desempenho dele é uma função de quais componentes estão instalados e ativos em uma sessão, as extensões instaladas, as configurações do Visual Studio, a configuração da máquina e, finalmente, a forma do código que está sendo editado. Dado o número de variáveis, é difícil saber se o relatório de problema de um usuário tem o mesmo problema subjacente que um relatório de problema de outro usuário, mesmo que o sintoma visível seja o mesmo. Considerando isso, veja abaixo estão algumas melhores práticas para garantir que seu relatório de problemas específico tenha maior probabilidade de ser diagnosticado.
Fornecer um título o mais específico possível
Procure assinaturas diferentes para o problema que está sendo relatado e inclua o máximo possível no título. Se o título for descritivo, é menos provável que os usuários com problemas não relacionados (mas mesmo sintoma superficial) votem ou comentem no seu tíquete, dificultando assim o diagnóstico do seu problema.
Em caso de dúvida, registre um novo relatório de problemas
Muitos problemas podem não ter assinaturas ou etapas diferentes a reproduzir. Nesses casos, um novo relatório é melhor do que um voto a favor ou um comentário em outro relatório, que está relatando um sintoma externo semelhante. Dependendo do tipo de relatório, inclua arquivos de diagnóstico adicionais no relatório, conforme descrito posteriormente neste documento.
Melhores práticas específicas do problema
Veja abaixo a descrição dos problemas difíceis de diagnosticar sem arquivos de diagnóstico válidos. Depois de identificar o caso que melhor descreve seu problema, siga as etapas de comentários específicas para esse caso.
Falhas: uma falha ocorre quando o processo (Visual Studio) termina inesperadamente.
Ausência de resposta: o VS não responde durante um longo período.
Problemas de lentidão: qualquer ação específica no VS é mais lenta do que o desejado
Alta utilização da CPU: períodos estendidos de alta utilização da CPU inesperada
Problemas fora do processo: um problema causado por um processo satélite do Visual Studio
Falhas
Uma falha ocorre quando o processo (Visual Studio) termina inesperadamente.
Falhas reproduzíveis diretamente
Falhas reproduzíveis diretamente são casos que têm todas as seguintes características:
Pode ser observado seguindo um conjunto conhecido de etapas
Pode ser observado em vários computadores (se disponível)
Pode ser reproduzido no código de exemplo ou em um projeto que pode ser vinculado ou fornecido como parte dos comentários (se as etapas envolverem a abertura de um projeto ou documento)
Para esses problemas, siga as etapas em "Como relatar um problema" e não deixe de incluir:
As etapas para reproduzir o problema
Um projeto de reprodução autônoma, conforme descrito acima. Se a reprodução autônoma não for possível, inclua:
A linguagem dos projetos em aberto (C#, C++ etc.)
O tipo de projeto (Aplicativo de Console, ASP.NET etc.)
Observação
Comentários mais valiosos: nesse caso, os comentários mais valiosos são o conjunto de etapas para reproduzir o problema junto com o código-fonte de exemplo.
Falhas desconhecidas
Se você não tiver certeza do que está causando as falhas ou se elas parecerem aleatórias, você pode capturar os despejos localmente sempre que o Visual Studio falhar e anexá-los a itens de comentários separados. Para salvar os despejos localmente quando o Visual Studio falhar, execute os seguintes comandos em uma janela de comando do administrador:
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe" /v DumpType /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe" /v DumpCount /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe" /v DumpFolder /t REG_SZ /d "C:\CrashDumps"
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService32.exe" /v DumpType /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService32.exe" /v DumpCount /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService32.exe" /v DumpFolder /t REG_SZ /d "C:\CrashDumps"
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService.exe" /v DumpType /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService.exe" /v DumpCount /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService.exe" /v DumpFolder /t REG_SZ /d "C:\CrashDumps"
Personalize a contagem de despejos e a pasta de despejo conforme apropriado. Veja mais informações sobre estas configurações aqui.
Observação
Provavelmente, os despejos capturados usando o Gerenciador de Tarefas terão o número de bit errado, o que os torna menos utilizáveis. O procedimento descrito acima é a maneira preferencial de capturar um despejo de heap. Se você quiser usar o Gerenciador de Tarefas, feche o que está em execução no momento, inicie o Gerenciador de Tarefas de 32 bits (%windir%\syswow64\taskmgr.exe) e colete um despejo de heap.
Observação
Cada arquivo de despejo gerado com esse método terá até 4 GB. Defina o DumpFolder como um local com o espaço de unidade adequado ou ajuste o DumpCount corretamente.
Sempre que o Visual Studio falhar, ele criará um arquivo de despejo devenv.exe.[ arquivo number].dmp no local configurado.
Em seguida, use o recurso "Relatar um problema" do Visual Studio. Isso permitirá que você anexe o despejo adequado.
Localize o arquivo de despejo para a falha que você está relatando (procure um arquivo com o tempo de criação correto)
Se possível, compacte o arquivo (*.zip) para reduzir o tamanho antes de enviar comentários
Siga as etapas em "Como relatar um problema" e anexe o despejo de heap a um novo item de comentários.
Observação
Comentários mais valiosos: nesse caso, os comentários mais valiosos são o despejo de heap capturado no momento da falha.
Ausência de resposta
O VS não responde durante um longo período.
Ausência de resposta reproduzível diretamente
Conforme descrito na seção correspondente sobre falhas, para problemas que podem ser reproduzidos facilmente, observados em vários computadores e que podem ser demonstrados em um pequeno exemplo, os relatórios de comentários mais valiosos são os que incluem etapas para reproduzir o problema e o código-fonte de exemplo que demonstra o problema.
Ausência de resposta desconhecida
Se houver ausência de resposta de maneira imprevisível, na próxima ocorrência, inicie uma nova instância do Visual Studio e relate um problema nessa instância. Na tela "Gravar", selecione a sessão do Visual Studio que não responde. (Para obter mais informações sobre como gravar ações que podemos seguir para reproduzir o problema, confira a Etapa 8 na página Como relatar um problema.)
Se a instância do Visual Studio que não está respondendo tiver sido iniciada no modo Administrador, a segunda instância também precisará ser iniciada no modo Administrador.
Observação
Comentários mais valiosos: nesse caso, os comentários mais valiosos são o despejo de heap capturado no momento da ausência de resposta.
Problemas de lentidão e alta utilização da CPU
O que torna um problema de lentidão ou alta utilização da CPU mais acionável é um rastreamento de desempenho capturado enquanto a operação lenta ou o evento de alta utilização da CPU está em andamento.
Observação
Quando possível, isole cada cenário em um relatório de comentários separado e específico. Por exemplo, se a digitação e a navegação estiverem lentas, siga as etapas abaixo uma vez para cada problema. Isso ajuda a equipe do produto a isolar a causa de problemas específicos.
Para obter melhores resultados na captura do desempenho, siga estas etapas:
Se ainda não estiver em execução, abra uma cópia do Visual Studio em que você reproduzirá o problema
Configure tudo para reproduzir o problema. Por exemplo, se você precisar que um projeto específico seja carregado com um arquivo específico aberto, verifique se ambas as etapas foram concluídas antes de prosseguir.
Se você não estiver relatando um problema específico para carregar uma solução, tente aguardar de 5 a 10 minutos (ou mais, dependendo do tamanho da solução) depois de abrir a solução, para gravar o rastreamento de desempenho. O processo de carregamento da solução produz um grande volume de dados. Portanto, aguardar alguns minutos ajuda a se concentrar no problema específico que você está relatando.
Iniciar uma segunda cópia do Visual Studio sem uma solução em aberto
Na nova cópia do Visual Studio, abra a ferramenta Relatar um Problema
Siga as etapas em Como relatar um problema até chegar à etapa "Fornecer um despejo de heap e rastreamento (opcional)".
Escolha gravar a primeira cópia do Visual Studio (a que tem um problema de desempenho) e iniciar a gravação.
O aplicativo Gravador de Etapas será exibido e começará a gravar.
Durante a gravação, execute a ação problemática na primeira cópia do Visual Studio. É difícil corrigir problemas de desempenho específicos se eles não aparecerem no tempo de gravação.
Se a ação tiver menos de 30 segundos e puder ser repetida facilmente, repita a ação para demonstrar melhor o problema.
Na maioria dos casos, um rastreamento de 60 segundos é suficiente para demonstrar os problemas, especialmente se a ação problemática durou (ou foi repetida por) mais de 30 segundos. A duração pode ser ajustada conforme necessário para capturar o comportamento que você gostaria de corrigir.
Clique em "Parar Gravação" no Gravador de Etapas, após a conclusão da operação lenta ou do evento de alta utilização da CPU que você deseja relatar. Pode levar alguns minutos para processar o rastreamento de desempenho.
Após a conclusão, haverá vários anexos para seus comentários. Anexe arquivos adicionais que possam ajudar a reproduzir o problema (um projeto de exemplo, capturas de tela, vídeos etc.).
Envie os comentários.
Durante a gravação de um rastreamento de desempenho, se a operação lenta ou a alta utilização da CPU que você está relatando terminar, interrompa imediatamente a gravação. Se muitas informações forem coletadas, as informações mais antigas serão substituídas. Se o rastreamento não for interrompido em breve (dentro de alguns segundos) após a operação de interesse, os dados de rastreamento úteis serão substituídos.
Não anexe os rastreamentos de desempenho diretamente a itens de comentários existentes no site do Developer Community. Solicitar/fornecer informações adicionais é um fluxo de trabalho com suporte na ferramenta interna Relatar um Problema do Visual Studio. Se um rastreamento de desempenho for necessário para resolver um item de comentários anterior, definiremos o estado do item de comentários como "Precisa de mais informações", que pode ser respondido da mesma forma que relatar um novo problema. Para obter instruções detalhadas, confira a seção "Precisa de mais informações" no documento da ferramenta Relatar um Problema.
Observação
Comentários mais valiosos: para quase todos os problemas de lentidão/alta utilização da CPU, os comentários mais valiosos são uma descrição de alto nível do que você estava tentando fazer, juntamente com o rastreamento de desempenho (*.etl.zip) que captura o comportamento durante esse tempo.
Rastreamentos de Desempenho Avançado
Os recursos de coleta de rastreamento na ferramenta Relatar um problema são suficientes para a maioria dos cenários. Mas há momentos em que mais controle sobre a coleção de rastreamento é necessário (por exemplo, rastreamento com um buffer maior). Nesse caso, o PerfView é uma ótima ferramenta a ser usada. As etapas para gravar manualmente o rastreamento de desempenho usando a ferramenta PerfView podem ser encontradas na página Como gravar rastreamentos de desempenho com o PerfView.
Problemas fora do processo
Observação
A partir do Visual Studio 2019 versão 16.3, os logs fora do processo são anexados automaticamente aos comentários enviados usando a ferramenta Relatar um Problema. No entanto, se o problema for reproduzível diretamente, seguir as etapas abaixo ainda poderá ajudar a adicionar outras informações para ajudar a diagnosticar melhor o problema.
Há vários processos satélite que são executados paralelamente ao Visual Studio e fornecem vários recursos de fora do processo principal do Visual Studio. Se ocorrer um erro em um desses processos satélite, ele geralmente será observado no lado do Visual Studio como um 'StreamJsonRpc.RemoteInvocationException' ou um 'StreamJsonRpc.ConnectionLostException'.
O que torna esses tipos de problemas mais acionáveis é fornecer logs adicionais que podem ser coletados seguindo estas etapas:
Se esse for um problema reproduzível diretamente, comece excluindo a pasta %temp%/servicehub/logs. Se você não puder reproduzir esse problema, mantenha esta pasta intacta e ignore os seguintes marcadores:
- Definir a variável de ambiente global ServiceHubTraceLevel como All
- Reproduza o problema.
Baixe o Microsoft Visual Studio e a ferramenta de coleta de Log do .NET Framework aqui.
Execute a ferramenta. Isso gera um arquivo zip para %temp%/vslogs.zip. Anexe esse arquivo aos seus comentários.