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

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 : « Il n’existe aucune donnée dans l’ensemble actuel de filtres »

Lors de l’ouverture d’un fichier de diagnostic , certains filtres sont appliqués, tels que le masquage du code natif ou le masquage de code non utilisateur pour faciliter la compréhension de la trace. En outre, il existe d’autres filtres qui peuvent être appliqués, tels que la sélection de temps et le thread, qui réduisent davantage les données affichées. Si ces filtres sont appliqués de manière à ce qu’il n’y ait pas de données restantes à afficher, vous voyez cet avertissement.

Guide pratique pour corriger

Vérifiez que votre sélection temporelle contient des données. Si vous avez modifié votre sélection de temps dans le graphique au-dessus des données, sélectionnez Effacer la sélection pour la réinitialiser.
Ensuite, s’il n’existe toujours aucune donnée, assurez-vous que toutes les catégories et threads sont activés dans leurs listes déroulantes respectives.
Si l’application que vous profilez est du code natif, veillez à activer l’option Afficher le code natif dans la liste déroulante 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. Assurez-vous 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

Cela prend beaucoup de temps pour que les résultats soient achevés.

Si l’analyse du tas après la collecte semble lente à charger, consultez les solutions possibles suivantes qui peuvent aider à résoudre les problèmes de temps d’attente.

Guide pratique pour corriger Parfois, il peut prendre plus de temps lorsque vous essayez d’analyser des captures instantanées à partir d’applications nécessitant beaucoup de mémoire, mais la mise à niveau vers une version plus récente de Visual Studio doit réduire le temps d’attente d’analyse. Si ce problème est persistant après la mise à niveau, il peut y avoir un bogue de performances sur l’outil. Créez un ticket de commentaires et partagez le fichier diagsession qui a été créé. Avec le fichier, nous pouvons déterminer pourquoi les données sont lentes à analyser et à trouver où nous pouvons améliorer les performances.

Veillez à fournir un fichier de trace et des fichiers de vidage de la mémoire dans le ticket de feedback.

Voir aussi :

Erreur « Impossible de créer un fichier manifeste pour cette session de diagnostic » ou « erreur n’a pas pu créer de fichier manifeste pour diagsession, Visual Studio ne pourra pas rouvrir cette session ».

Ce problème signifie qu’il y a eu un problème lors de la préparation des données d’instantané de mémoire à analyser et à afficher après l’arrêt pour collecter des données. Il existe plusieurs causes potentielles pour que le problème apparaisse, d’un échec d’obtention des informations correctes des agents de collecte au traitement réel des données. Par conséquent, il n’est pas possible de diagnostiquer ce que le problème est sans journalisation supplémentaire.

Guide pratique pour corriger Répondez à votre ticket de commentaires avec des informations de journalisation supplémentaires afin que nous puissions 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, puis compressez votre répertoire de journaux DiagnosticsHub choisi et attachez-le à ce ticket. À partir de là, nous devrions être en mesure de mieux diagnostiquer ce qui se passe.

Après avoir ajouté le journal à votre ticket, exécutez ces commandes 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 : « Informations sources non disponibles ».

Pour afficher les informations sources, vous devez disposer de fichiers PDF disponibles à partir du moment de la collecte. Par exemple, si vous collectez un fichier diagsession d’utilisation du processeur, apportez des modifications à votre code, recompilez (ce qui remplace l’ancien PBD), puis ouvrez à nouveau le fichier .diagsession, vous ne pourrez probablement pas voir les informations sources pour les modules de votre code que vous avez mis à jour.

Guide pratique pour corriger La solution de contournement la plus simple pour 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 : « L’analyse de la mémoire a échoué en raison d’une erreur interne . »

Après une longue session de profilage de mémoire, toute tentative d’analyse du résultat se heurte à une erreur.

Il y avait une incompatibilité entre les informations d’instantané capturées par l’outil mémoire et celle de l’agent de collecte. Ce résultat signifie que l’outil mémoire n’a pas pu trouver le fichier d’état du tas pour un instantané natif. Cependant, l'outil mémoire n'a pas pu faire correspondre l'heure de début de GC de l'instantané avec celle inscrite dans le fichier diagsession pour récupérer les GCStats.

Guide pratique pour corriger Ce problème était dû à un bogue dans l’outil qui a été résolu dans Visual Studio 2022 version 17.3. La mise à niveau vers une version ultérieure doit résoudre le problème. Si le problème est toujours persistant après la mise à niveau, créez un ticket de commentaires et joignez-le au ticket :

Le fichier diagsession
Minidump de Visual Studio
Capture d’écran des captures instantanées de mémoire prises.

Il n’existe pas de solution de contournement pour ce problème et la session de profilage doit être redémarrée.

Erreur : « Les événements de diagnostic X supprimés, certaines informations du rapport peuvent être manquantes ou inexactes »

Parfois, pendant la capture de données, les événements peuvent être supprimés, ce qui peut entraîner l’imprécision ou l’inutilisable du rapport de profilage résultant. Les événements perdus peuvent se produire pour de nombreuses raisons différentes, mais cela se produit principalement lorsque le système ne parvient pas à transférer les événements sur le disque plus rapidement que le rythme d'arrivée.

Guide pratique pour corriger Pour réduire les événements supprimés, vous pouvez fermer d’autres opérations intensives sur disque et processeur lors du profilage. En fermant ces opérations, le système peut dédier davantage de ressources pour vider les é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 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 des événements pour Windows (ETW) pour collecter ses informations de performances. Il existe un nombre fini de sessions ETW disponibles pour une utilisation 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 profils et d’autres outils de diagnostic. Vous pouvez résoudre ce problème en procédant comme suit :

Fermeture des programmes qui utilisent les sessions pour libérer des ressources ou
En assignant davantage de ressources en exécutant la commande suivante à partir d’une invite de commandes avec élévation de privilèges, puis en redémarrant :
```
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 comprises entre 64 et 128 (256 est le nombre maximal de sessions autorisées sur un système).

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

Le profileur Visual Studio utilise le suivi des événements pour Windows (ETW) pour collecter ses informations de performances. Actuellement, la collecte d’exemples de profil à l’aide d’ETW n’est pas prise en charge sur Windows pour ARM64 lors de l’exécution dans une machine virtuelle. Pour contourner cette limitation, vous pouvez utiliser l’outil Utilisation du processeur 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 .NET 7 et .NET Runtime 8.0.0-8.0.1 avec le serveur GC activé

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

Guide pratique pour corriger

Pour contourner ce problème :

Désactivez la collecte des déchets pour le serveur en prenant un instantané ou en générant un vidage de votre application.
Utilisez une version non affectée du runtime .NET.

Voir aussi :

Rétroaction

Cette page a-t-elle été utile ?

Last updated on 2025-12-12