Partager via

Résoudre les erreurs de profilage et résoudre les problèmes

  • Article

Cet article fournit des solutions pour certaines des erreurs les plus courantes qui peuvent empêcher l’utilisation ou l’obtention de données suffisantes à partir du Profileur de performances dans Visual Studio.

Aucun résultat

Erreur : « There is no data in the current set of filters » (Aucune donnée dans l'ensemble actuel de filtres)

Lors de l’ouverture d’un fichier diagsession, certains filtres sont appliqués, notamment le masquage du code natif ou le masquage de code non utilisateur pour faciliter la compréhension de la trace. En outre, d’autres filtres peuvent être appliqués, par exemple sélection d’heure et thread, qui réduisent encore davantage les données affichées. Si ces filtres sont appliqués de manière à n’afficher plus aucune autre donnée, cet avertissement apparaît.

Procédure de résolution

  • Vérifiez que votre sélection d’heure temps contient des données. Si vous avez modifié votre sélection d’heure dans le graphique au-dessus des données, sélectionnez Effacer la sélection pour la réinitialiser.
  • S'il n'y a toujours pas de données, assurez-vous que toutes les catégories et tous les threads sont activés dans leurs menus déroulants respectifs.
  • Si l’application pour laquelle vous créez un profil représente du code natif, assurez-vous d’activer l’option Afficher le code natif dans le menu déroulant Paramètres.
  • Si vous n’avez toujours aucune donnée, la trace que vous avez collectée était probablement trop courte pour que toutes les données soient présentes. Vérifiez que le programme pour lequel vous collectez des données ne se termine pas trop rapidement (moins d’une seconde).

Voir aussi : Afficher le code externe

Les résultats sont longs à obtenir

Si le chargement de l'analyse du tas après la collecte semble lent, les solutions suivantes peuvent aider à résoudre les problèmes de temps d'attente.

Solution L'analyse des instantanés d'applications nécessitant beaucoup de mémoire peut parfois prendre plus de temps, mais la mise à niveau vers une version plus récente de Visual Studio devrait permettre de réduire le temps d'attente de l'analyse. Si ce problème persiste après la mise à niveau, il se peut que l'outil présente un problème de performance. Créez un ticket de commentaires et partagez le fichier diagsession qui a été créé. Ce fichier nous aidera à rechercher les causes de la lenteur de chargement des données à analyser et à identifier les endroits où nous pouvons améliorer les performances.

Veillez à fournir une trace et des fichiers de vidage du tas dans le ticket de commentaires.

Voir aussi :

Erreur « Could not create a manifest file for this diagsession » (Impossible de créer un fichier manifeste pour cette session de diagnostic) ou « Could not create manifest file for diagsession, Visual Studio will not able to reopen this session » (Impossible de créer le fichier manifeste pour la session de diagnostic, Visual Studio ne pourra pas rouvrir cette session).

Ce message indique qu’un problème est survenu lors de la préparation des données de l'instantané de mémoire à analyser et à afficher après l'arrêt de la collecte des données. Les causes potentielles de ce problème sont multiples, de l'impossibilité d'obtenir les informations correctes de la part des agents de collecte jusqu'au traitement des données. Par conséquent, il ne sera pas possible de diagnostiquer le problème sans une journalisation supplémentaire.

Solution Répondez à votre ticket de commentaires en fournissant des informations de journalisation supplémentaires pour nous permettre de diagnostiquer le problème. Vous pouvez obtenir les informations du journal en exécutant les commandes suivantes à partir d'une invite de commande avec élévation de privilèges :

reg add HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /v LogLevel /t REG_SZ /d All /reg:32
reg add HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /v LogDirectory /t REG_SZ /d [directory of your choice] /reg:32

Après avoir exécuté ces commandes, démarrez Visual Studio, reproduisez votre scénario, fermez Visual Studio, compressez le répertoire de journaux DiagnosticsHub que vous avez choisi, puis joignez-le à ce ticket. À partir de là, nous devrions être en mesure de mieux diagnostiquer le problème.

Après avoir ajouté le journal à votre ticket, exécutez les commandes suivantes pour désactiver la journalisation :

reg delete HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /f /v LogLevel /reg:32
reg delete HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /f /v LogDirectory /reg:32

Erreur : « Source information not available » (Informations sur la source non disponibles).

Pour afficher les informations de la source, vous devez disposer de fichiers PDF disponibles au moment de la collecte. Si vous collectez, par exemple, un fichier diagsession sur l’utilisation du processeur, que vous modifiez votre code, recompilez (remplace l’ancien PBD), puis ouvrez à nouveau le fichier .diagsession, vous ne serez probablement pas en mesure de voir les informations de la source pour les modules de votre code mis à jour.

Solution La solution la plus simple à ce problème consiste à collecter une nouvelle session de diagnostic après avoir apporté des modifications. De cette façon, vous pouvez être sûr que vos PDB sont à jour.

Erreur : « Memory analysis failed due to an internal error » (L'analyse de la mémoire a échoué en raison d'une erreur interne).

Après une longue session de profilage de la mémoire, toute tentative d'analyse du résultat génère cette erreur.

Les informations de l’instantané saisies par l'outil Utilisation de la mémoire ne correspondent pas à celles de l'agent de collecte. Ce résultat signifie que l'outil Utilisation de la mémoire n'a pas pu trouver le fichier d'état du tas pour un instantané natif. Ou ce résultat est dû au fait que l'outil Utilisation de la mémoire n'a pas pu faire correspondre l'heure de début GC de l'instantané à celle enregistrée dans le fichier diagsession pour récupérer les données GCStats.

Solution Ce problème était dû à un bogue dans l’outil, qui a été résolu dans la version 17.3. La mise à niveau vers une version ultérieure devrait résoudre le problème. Si le problème persiste après la mise à niveau, créez un ticket de commentaires et joignez les éléments suivants au ticket :

  • Le fichier diagsession
  • Un minidump de Visual Studio
  • Une capture d’écran des instantanés de mémoire.

Il n'y a pas de solution à ce problème et la session de profilage devra être redémarrée.

Erreur : « X événements de diagnostic supprimés. Certaines informations du rapport peuvent être absentes ou incorrectes »

Parfois, pendant la capture de données, des événements peuvent être supprimés, ce qui peut donner un rapport de profilage résultant inexact ou inutilisable. Des événements supprimés peuvent se produire pour différentes raisons, mais ils se produisent principalement lorsque le système ne parvient pas à vider les événements sur le disque plus rapidement que le débit entrant.

Comment résoudre le problème Pour réduire les événements supprimés, vous pouvez fermer les autres opérations gourmandes en disque et en processeur lors du profilage. En fermant ces opérations, le système peut dédier plus de ressources au vidage des événements entrants. Vous pouvez également essayer de réduire les fréquences d’échantillonnage sur les outils qui prennent en charge ces paramètres de configuration, tels que l’outil d’utilisation du processeur et l’outil d’allocation .NET, et ainsi réduire la surcharge.

Erreur : les ressources ETW ont été épuisées

Le profileur Visual Studio utilise le suivi d’événements pour Windows (ETW) pour collecter ses informations de performances. Il existe un nombre limité de sessions ETW disponibles sur un système et si toutes les sessions sont déjà utilisées, vous obtenez l’erreur suivante : ETW resources have been exhausted. Ces sessions sont utilisées par d’autres programmes tels que la suite d’outils SysInternals, d’autres profileurs et d’autres outils de diagnostic. Vous pouvez résoudre ce problème en procédant comme suit :

  • Fermer des programmes qui utilisent les sessions pour libérer des ressources ou

  • Mettre de côté d’autres ressources en exécutant ce qui suit à partir d’une invite de commandes avec élévation de privilèges, puis redémarrer :

    reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI" /v EtwMaxLoggers /t REG_DWORD /d 128

    L’exécution de cette commande augmente le nombre par défaut de sessions de 64 à 128 (256 est le nombre maximal de sessions autorisées sur un système).

Erreur : l’outil Utilisation du processeur ne fonctionne pas sur une machine virtuelle ARM64

Le profileur Visual Studio utilise le suivi d’événements pour Windows (ETW) pour collecter ses informations de performances. Actuellement, la collecte d’exemples de profils en utilisant ETW n’est pas prise en charge sur Windows pour ARM64 lors de l’exécution sur une machine virtuelle. Pour contourner cette limitation, vous pouvez utiliser l’outil Utilisation de l’UC sur un appareil ARM64 réel ou utiliser l’outil Instrumentation pour capturer des informations de minutage.

Erreur : l’outil d’utilisation de la mémoire ne fonctionne pas sur les runtimes .NET 7 et .NET 8.0.0-8.0.1 avec le GC de serveur activé

En raison d’un problème introduit avec le runtime .NET 7 et propagé au runtime .NET 8 versions 8.0.0 et 8.0.1, il n’est pas possible d’énumérer des objets lors de l’utilisation du garbage collection de serveur. Le garbage collection de serveur est activé par défaut pour les applications ASP.NET Core.

Procédure de résolution

Pour contourner ce problème :

  • Désactivez le garbage collection de serveur lorsque vous prenez un instantané ou collectez un vidage de votre application.
  • Utilisez une version non affectée du runtime .NET.

Voir aussi :

Contenu connexe