Share via

Augmenter les chances de correction d’un problème de performance

  • Article

L’outil « Signaler un problème » est largement utilisé par les utilisateurs de Visual Studio pour signaler une grande variété de problèmes. L’équipe Visual Studio détecte les tendances d’incident et de lenteur dans les commentaires des utilisateurs et résout les problèmes qui impactent un large éventail d’utilisateurs. Plus un ticket de commentaire spécifique est actionnable, plus il est diagnostiqué et résolu rapidement par l’équipe produit. Ce document décrit les bonnes pratiques de signalement des problèmes d’incident ou de lenteur pour qu’ils soient plus actionnables.

Bonnes pratiques générales

Visual Studio est une grande plateforme complexe qui prend en charge une multitude de langages, de types de projets, de plateformes, etc. Ses performances dépendent des composants installés et actifs dans une session, des extensions installées, des paramètres Visual Studio, de la configuration de la machine et enfin de la forme du code que vous modifiez. Compte tenu du nombre de variables, il est difficile de dire si le problème signalé par un utilisateur est le même que celui signalé par un autre utilisateur, même si le symptôme visible est le même. De ce fait, voici quelques bonnes pratiques pour que le problème spécifique que vous signalez ait plus de chances d’être diagnostiqué.

Fournir un titre aussi spécifique que possible

Recherchez des signatures distinctes du problème que vous signalez et indiquez le plus d’informations possibles dans le titre. Si le titre est descriptif, les utilisateurs qui rencontrent des problèmes non liés (mais avec le même symptôme superficiel) ont moins de chances de voter ou de commenter votre ticket, ce qui rend plus difficile le diagnostic de votre problème.

En cas de doute, journaliser un nouveau rapport de problème

De nombreux problèmes peuvent ne pas avoir d’étapes ou de signature distinctives à reproduire. Dans ce cas, il vaut mieux envoyer un nouveau rapport plutôt que de voter ou commenter un rapport existant, qui signale un symptôme extérieur similaire. En fonction du type de rapport, ajoutez des fichiers de diagnostic supplémentaires à votre rapport, comme décrit plus loin dans ce document.

Bonnes pratiques liées aux problèmes

Voici une description des problèmes difficiles à diagnostiquer sans bons fichiers de diagnostic. Une fois que vous avez identifié le cas qui décrit le mieux votre problème, suivez les étapes de commentaire pour ce cas.

Crashes

Un incident (blocage) se produit quand le processus (Visual Studio) se termine de manière inattendue.

Incidents directement reproductibles

Les incidents directement reproductibles sont des cas qui ont toutes les caractéristiques suivantes :

  • Peut être observé en suivant un ensemble connu d’étapes

  • Peut être observé sur plusieurs ordinateurs (si disponible)

  • Peut être reproduit dans un exemple de code ou un projet pouvant être lié ou fourni dans le cadre du commentaire (si les étapes impliquent l’ouverture d’un projet ou d’un document)

Pour ces problèmes, suivez les étapes de « Comment signaler un problème » et veillez à ajouter :

  • Les étapes pour reproduire le problème

  • Un projet de reproduction autonome, comme décrit ci-dessus. Si la reproduction autonome n’est pas possible, indiquez :

    • Le langage des projets ouverts (C#, C++, etc.)

    • Le type de projet (application console, ASP.NET, etc.)

Notes

Commentaires à plus forte valeur ajoutée : dans ce cas, le commentaire le plus utile est celui qui indique l’ensemble des étapes permettant de reproduire le problème et fournit un exemple de code source.

Incidents inconnus

Si vous ne connaissez pas la cause de vos incidents ou qu’ils semblent aléatoires, vous pouvez capturer des images mémoire localement chaque fois que Visual Studio se bloque et les attacher à des commentaires séparés. Pour enregistrer les images mémoire localement quand Visual Studio se bloque, exécutez les commandes suivantes dans une fenêtre de commande d’administrateur :

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"

Personnalisez le nombre d’images mémoire et le dossier d’images mémoire en fonction de votre cas. Plus d’informations sur ces paramètres sont disponibles ici.

Notes

Les images mémoire capturées en utilisant le Gestionnaire des tâches sont susceptibles de ne pas avoir le bon nombre de bits, ce qui les rend moins utilisables. La procédure décrite ci-dessus est la méthode recommandée pour capturer une image mémoire du tas. Si vous souhaitez utiliser le Gestionnaire des tâches, fermez celui qui est en cours d’exécution, lancez le Gestionnaire de tâches 32 bits (%windir%\syswow64\taskmgr.exe) et collectez une image mémoire de tas à partir de là.

Notes

Chaque fichier d’image mémoire produit par cette méthode a une taille maximale de 4 Go. Veillez à définir DumpFolder sur un emplacement avec un espace disque suffisant ou ajustez le DumpCount de manière appropriée.

Chaque fois que Visual Studio se bloque, il crée un fichier d’image mémoire devenv.exe.[number].dmp à l’emplacement configuré.

Ensuite, utilisez la fonctionnalité « Signaler un problème... » de Visual Studio. Elle vous permet de joindre l’image mémoire appropriée.

  1. Recherchez le fichier d’image mémoire correspondant à l’incident que vous signalez (recherchez un fichier avec l’heure de création appropriée)

  2. Si possible, compressez le fichier (*.zip) pour réduire sa taille avant d’envoyer le commentaire

  3. Suivez les étapes de « Comment signaler un problème », puis joignez l’image mémoire du tas à un nouveau commentaire.

Notes

Commentaires à plus forte valeur ajoutée : dans ce cas, le commentaire le plus utile est celui qui fournit l’image mémoire du tas capturée au moment de l’incident.

Absence de réponse

VS ne répond plus pendant une longue période.

Absence de réponse directement reproductible

Comme décrit dans la section correspondante sur les incidents, pour les problèmes qui peuvent être facilement reproduits, vus sur plusieurs ordinateurs et qui peuvent être démontrés dans un petit échantillon, les rapports de commentaire les plus utiles sont ceux qui montrent les étapes pour reproduire le problème et fournissent un exemple de code source pour illustrer le problème.

Absence de réponse de cause inconnue

Si une absence de réponse se manifeste de manière imprévisible, à l’occurrence suivante, lancez une nouvelle instance de Visual Studio et signalez le problème à partir de cette instance. Dans l’écran « Enregistrer », veillez à sélectionner la session Visual Studio qui ne répond pas. (Pour plus d’informations sur l’enregistrement des actions qui nous permettent de reproduire le problème, consultez l’Étape 8 de la page Comment signaler un problème.)

Si l’instance Visual Studio qui ne répond pas a été lancée en mode Administrateur, la deuxième instance doit également être lancée en mode Administrateur.

Notes

Commentaires à plus forte valeur ajoutée : dans ce cas, le commentaire le plus utile est celui qui fournit l’image mémoire du tas capturée au moment de l’absence de réponse.

Problèmes de lenteur et d’utilisation élevée du processeur

Ce qui permet d’exploiter au mieux un problème de lenteur ou d’utilisation élevée du processeur est une trace des performances capturée pendant l’opération lente ou l’événement d’utilisation élevée du processeur.

Notes

Si possible, isolez chaque scénario dans un rapport de commentaire distinct et spécifique. Par exemple, si la saisie et la navigation sont toutes les deux lentes, suivez les étapes ci-dessous une fois par problème. Cela permet à l’équipe produit d’isoler la cause des problèmes spécifiques.

Pour obtenir de meilleurs résultats de capture des performances, suivez ces étapes :

  1. S’il n’est pas déjà en cours d’exécution, ouvrez une copie de Visual Studio pour reproduire le problème

    • Configurez tout ce qu’il faut pour reproduire le problème. Par exemple, si vous avez besoin qu’un projet particulier soit chargé avec un fichier spécifique ouvert, exécutez ces deux étapes avant de continuer.

    • Si vous ne signalez pas un problème propre au chargement d’une solution, essayez d’attendre 5 à 10 minutes (ou plus, selon la taille de la solution) après l’ouverture de la solution pour enregistrer la trace des performances. Le processus de chargement de la solution produit une grande quantité de données. Par conséquent, le fait d’attendre quelques minutes nous aide à nous concentrer sur le problème spécifique que vous signalez.

  2. Démarrez une deuxième copie de Visual Studio sans solution ouverte

  3. Dans la nouvelle copie de Visual Studio, ouvrez l’outil Signaler un problème

  4. Suivez les étapes de Comment signaler un problème jusqu’à l’étape « Fournir une trace et une image mémoire du tas (facultatif) ».

  5. Choisissez d’enregistrer la première copie de Visual Studio (celle qui rencontre le problème de performances) et démarrez l’enregistrement.

    • L’application Enregistreur d’étapes s’affiche et commence l’enregistrement.

    • Pendant l’enregistrement, effectuez l’action problématique dans la première copie de Visual Studio. Il est difficile pour nous de corriger des problèmes de performances spécifiques s’ils n’apparaissent pas dans la période enregistrée.

    • Si l’action dure moins de 30 secondes et est facilement reproduite, répétez l’action pour mieux illustrer le problème.

    • Dans la plupart des cas, une trace de 60 secondes suffit pour montrer le problème, en particulier si l’action problématique a duré (ou a été répétée) pendant plus de 30 secondes. La durée peut être ajustée si nécessaire pour capturer le comportement que vous souhaitez corriger.

  6. Cliquez sur « Arrêter l’enregistrement » dans l’Enregistreur d’étapes dès que l’opération lente ou l’événement d’utilisation élevée du processeur que vous souhaitez signaler est terminé. Le traitement de la trace de performances peut prendre quelques minutes.

  7. Une fois terminé, vous avez plusieurs pièces jointes à envoyer avec votre commentaire. Joignez tous les fichiers supplémentaires qui peuvent aider à reproduire le problème (un échantillon de projet, des captures d’écran, des vidéos, etc.).

  8. Envoyez le commentaire.

Pendant l’enregistrement d’une trace de performances, si l’opération lente ou l’événement d’utilisation élevée du processeur que vous signalez prend fin, arrêtez immédiatement l’enregistrement. Si trop d’informations sont collectées, les informations les plus anciennes sont remplacées. Si la trace n’est pas arrêtée rapidement (quelques secondes) après l’opération qui nous intéresse, les données de trace utiles sont remplacées.

Ne joignez pas directement les traces de performances aux commentaires existants du site web de la communauté des développeurs. La demande/la fourniture d’informations supplémentaires est un workflow pris en charge dans l’outil intégré Signaler un problème de Visual Studio. Si une trace de performances est nécessaire pour résoudre un commentaire précédent, nous définissons l’état du commentaire sur « Besoin d’informations supplémentaires », auquel vous pouvez répondre de la même façon que pour signaler un nouveau problème. Pour obtenir des instructions détaillées, consultez la section « Besoin d’informations supplémentaires » dans le document de l’outil Signaler un problème.

Notes

Commentaires à plus forte valeur ajoutée : pour presque tous les problèmes de lenteur/utilisation élevée du processeur, le commentaire le plus utile est la description générale de ce que vous essayez de faire, ainsi que la trace des performances (*.etl.zip) qui capture le comportement pendant cette période.

Traces de performances avancées

Les fonctionnalités de collecte de traces de l’outil Signaler un problème sont suffisantes dans la plupart des scénarios. Toutefois, vous pouvez avoir besoin d’un contrôle supplémentaire sur la collecte de traces (par exemple, pour les traces avec une plus grande taille de mémoire tampon), auquel cas vous pouvez utiliser PerfView. Les étapes d’enregistrement manuel de la trace des performances avec l’outil PerfView sont décrites dans la page Enregistrement des traces de performances avec PerfView.

Problèmes hors processus

Notes

À compter de Visual Studio 2019 version 16.3, les journaux hors processus sont automatiquement joints aux commentaires envoyés avec l’outil Signaler un problème. Toutefois, si le problème est directement reproductible, les étapes ci-dessous peuvent quand même vous aider à ajouter des informations supplémentaires pour mieux diagnostiquer le problème.

Il existe un certain nombre de processus satellites qui s’exécutent parallèlement à Visual Studio et fournissent diverses fonctionnalités en dehors du processus Visual Studio principal. Si une erreur se produit dans l’un de ces processus satellites, elle est généralement vue côté Visual Studio sous forme d’exception « StreamJsonRpc.RemoteInvocationException » ou « StreamJsonRpc.ConnectionLostException ».

Ce type de problèmes est plus actionnable si vous fournissez des journaux supplémentaires pouvant être collectés en suivant ces étapes :

  1. S’il s’agit d’un problème directement reproductible, commencez par supprimer le dossier %temp%/servicehub/logs. Si vous ne pouvez pas reproduire le problème, gardez ce dossier intact et ignorez les points suivants :

    • Définissez la variable d’environnement globale ServiceHubTraceLevel sur All
    • Reproduisez le problème.

  2. Téléchargez Microsoft Visual Studio and .NET Framework Log Collection Tool ici.

  3. Exécutez l’outil. Cela génère un fichier zip dans %temp%/vslogs.zip. Joignez ce fichier à votre commentaire.

Contenu connexe