Débogage avec des symboles

Cet article fournit une vue d’ensemble de la façon d’utiliser au mieux les symboles dans votre processus de débogage. Il explique comment utiliser le serveur de symboles Microsoft, et comment configurer et utiliser votre propre serveur de symboles privé. Ces meilleures pratiques peuvent vous aider à augmenter votre efficacité et votre capacité à déboguer les problèmes, même dans les cas où tous les symboles et tous les fichiers exécutables liés à un problème ne se trouvent pas sur votre ordinateur.

• Symboles
• Utilisation de symboles pour le débogage
• Obtention des symboles dont vous avez besoin
  • Vérifier si une DLL ou un fichier .exe donné et un PDB situés dans le même dossier correspondent
  • Vérifier si toutes les DLL et tous les fichiers exécutables d’un ensemble de dossiers ont des PDB correspondants
  • Fonctionnement de symchk
• Serveurs de symboles
• Utilisation du serveur de symboles Microsoft
• Obtention manuelle des symboles
• Configuration d’un serveur de symboles
• Ajout de symboles à un serveur de symboles
• Meilleures pratiques

Symboles

Plusieurs types de symboles différents sont disponibles pour le débogage. Ils incluent les symboles CodeView, COFF, DBG, SYM, PDB et même les symboles d’exportation générés à partir d’une table d’exportation de fichiers binaires. Ce livre blanc traite uniquement de VS.NET et des symboles au format PDB, car il s’agit du format préféré le plus récent. Ils sont générés par défaut pour les projets compilés à l’aide de Visual Studio.

La génération de fichiers PDB pour les exécutables de version n’affecte pas les optimisations. Elle ne change pas non plus de manière significative la taille des fichiers générés. En règle générale, la seule différence réside dans le chemin. Le nom de fichier du fichier PDB est incorporé dans l’exécutable. C’est la raison pour laquelle vous devez toujours produire des fichiers PDB, même si vous ne souhaitez pas les fournir avec l’exécutable.

Les fichiers PDB sont générés si un projet est généré à l’aide du commutateur de compilateur /Zi ou /ZI (permet de produire des informations PDB) ainsi qu’avec le commutateur d’éditeur de liens /DEBUG (permet de générer des informations de débogage). Les fichiers PDB générés par le compilateur sont combinés et écrits dans un seul fichier PDB placé dans le même répertoire que l’exécutable.

Par défaut, les fichiers PDB contiennent les informations suivantes :

• Symboles publics (généralement toutes les fonctions ainsi que les variables statiques et globales)
• Liste de fichiers objets responsables des sections de code dans l’exécutable
• Informations FPO (optimisation des pointeurs de frame)
• Informations de nom et de type pour les variables locales et les structures de données
• Informations sur le fichier source et le numéro de ligne

Si vous craignez que des personnes utilisent les informations du fichier PDB pour effectuer de l’ingénierie à rebours sur votre exécutable, vous pouvez également générer des fichiers PDB réduits à l’aide de l’option d’éditeur de liens /PDBSTRIPPED:nom_fichier. Si vous disposez de fichiers PDB existants dont vous souhaitez supprimer les informations privées, vous pouvez utiliser un outil appelé pdbcopy, qui fait partie des outils de débogage pour Windows.

Par défaut, les fichiers PDB réduits contiennent les informations suivantes :

• Symboles publics (généralement uniquement les fonctions non statiques et les variables globales)
• Liste de fichiers objets responsables des sections de code dans l’exécutable
• Informations FPO (optimisation des pointeurs de frame)

Il s’agit des informations minimales nécessaires pour permettre un débogage fiable. Les informations minimales compliquent également l’obtention d’informations supplémentaires sur votre code source d’origine. Dans la mesure où un fichier PDB réduit et un fichier PDB classique sont générés, vous pouvez fournir la version réduite aux utilisateurs susceptibles d’avoir besoin de fonctionnalités de débogage limitées, tout en préservant la confidentialité des fichiers PDB complets. Notez que /PDBSTRIPPED génère un deuxième fichier PDB, plus petit. Veillez donc à utiliser le fichier PDB approprié quand vous générez des builds en vue d’une distribution à grande échelle. Pour un projet classique, un PDB normal peut avoir une taille de quelques mégaoctets, alors qu’une version réduite du PDB peut avoir une taille de quelques centaines de Ko seulement.

Utilisation de symboles pour le débogage

Quand vous déboguez une application qui s’est bloquée à la suite d’un incident, le débogueur tente de vous montrer les fonctions de la pile qui ont conduit au plantage. Sans fichier PDB, le débogueur ne peut pas résoudre les noms de fonctions, leurs paramètres ou les variables locales stockées dans la pile. Si vous déboguez des exécutables 32 bits, il existe des situations où vous ne pouvez même pas obtenir d’arborescences des appels de procédure fiables sans symboles. Il est parfois possible d’examiner les valeurs brutes dans la pile et de déterminer quelles sont celles qui peuvent être des adresses de retour, mais celles-ci peuvent être facilement confondues avec des références de fonctions ou des données.

Si les fonctions de la pile actuelle ont été compilées à l’aide de l’optimisation par omission des pointeurs de frame (/Oy), et si les symboles ne sont pas présents, le débogueur ne peut pas identifier de manière fiable la fonction qui a appelé la fonction actuelle. En effet, sans les informations FPO (optimisation des pointeurs de frame) contenues dans les PDB, le débogueur ne peut pas compter sur le registre de pointeur de frame (EBP) pour pointer vers le pointeur de frame précédent enregistré ni vers l’adresse de retour de la fonction parente. À la place, il effectue des suppositions. Parfois, elles sont justes. Toutefois, il se trompe souvent, ce qui peut être source de confusion. Si vous voyez un avertissement indiquant que des symboles sont manquants ou qu’aucun symbole n’a été chargé, comme dans l’exemple suivant, n’approuvez pas la pile à partir de ce point.

SWPerfTest.exe!TextFunction(... ...)    Line 59    C++
d3dx9d.dll!008829b5()
[Frames below may be incorrect and/or missing, no symbols loaded for d3dx9d.dll]
SWPerfTest.exe!main(int argc=, const char * * argv=)  Line 328 + 0x12 bytes     C++
SWPerfTest.exe!__mainCRTStartup() Line 716 + 0x17 bytes    C
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
ntdll.dll!__RtlUserThreadStart@8() + 0x27 bytes

Dans de nombreux cas, il est possible de continuer le débogage sans symboles, car le problème se produit à un emplacement qui comporte des symboles précis, et vous n’avez pas besoin d’examiner les fonctions plus loin dans la pile des appels. Même si une bibliothèque qui se trouve dans votre pile des appels n’a pas de PDB disponibles, du moment que les bibliothèques ont été compilées avec des pointeurs de frame, le débogueur doit pouvoir deviner correctement les fonctions parentes. À partir de Windows XP Service Pack 2, toutes les DLL et tous les fichiers exécutables Windows sont compilés avec l’optimisation FPO désactivée, car cela rend le débogage plus précis. La désactivation de l’optimisation FPO permet également aux profileurs d’échantillonnage de parcourir la pile à l’exécution, avec un impact minimal sur les performances. Sur les versions de Windows antérieures à Windows XP SP2, tous les fichiers binaires du système d’exploitation nécessitent des fichiers de symboles correspondants qui contiennent des informations FPO pour permettre un débogage et un profilage précis.

Si vous déboguez des exécutables natifs 64 bits, vous n’avez pas besoin des fichiers de symboles pour produire des arborescences des appels de procédure valides, car les systèmes d’exploitation et les compilateurs x64 sont conçus pour ne pas en avoir besoin. Toutefois, vous avez toujours besoin des fichiers de symboles pour récupérer les noms de fonctions, les paramètres d’appel et les variables locales.

Certains cas, cependant, sont particulièrement difficiles à déboguer sans symboles. Par exemple, si vous déboguez un programme pour lequel vous avez généré un fichier PDB, et si un incident se produit durant un rappel de fonction dans une DLL pour laquelle vous n’avez pas de symboles, vous ne pourrez pas voir quelle fonction a provoqué le rappel, car vous ne pourrez pas décoder la pile. Cela se produit fréquemment dans les bibliothèques tierces, si les PDB ne sont pas fournis, ou dans les composants d’anciens systèmes d’exploitation, si les PDB ne sont pas disponibles. Les rappels se produisent souvent durant le passage de messages, l’énumération, l’allocation de mémoire ou la gestion des exceptions. Le débogage de ces fonctions sans pile précise peut être frustrant.

Pour déboguer de manière fiable les minidumps générés sur un autre ordinateur, ou qui sont bloqués dans du code qui ne vous appartient pas, il est important de pouvoir accéder à tous les symboles et fichiers binaires des exécutables référencés dans le minidump. Si les symboles et les fichiers binaires sont disponibles sur un serveur de symboles, ils sont automatiquement obtenus par le débogueur. Pour plus d’informations sur les minidumps, consultez le livre blanc Analyse du vidage sur incident.

Obtention des symboles dont vous avez besoin

Visual Studio et les autres débogueurs Microsoft, par exemple WinDbg, sont généralement configurés pour fonctionner uniquement si vous générez une application et la déboguez sur votre propre ordinateur. Si vous devez donner votre exécutable à quelqu’un d’autre, si vous avez plusieurs versions d’une DLL ou d’un fichier.exe sur votre ordinateur, ou si vous souhaitez déboguer avec précision une application qui utilise Windows ou d’autres bibliothèques, par exemple DirectX, vous devez pour comprendre comment les débogueurs trouvent et chargent les symboles. Le débogueur utilise le chemin de recherche de symboles spécifié par l’utilisateur, qui se trouve dans Options\Débogage\Symboles dans Visual Studio, ou la variable d’environnement _NT_SYMBOL_PATH. En règle générale, le débogueur recherche les fichiers PDB correspondants aux emplacements suivants :

• Emplacement spécifié à l'intérieur de la DLL ou du fichier exécutable.

  Si vous avez généré une DLL ou un fichier exécutable sur votre ordinateur, par défaut l’éditeur de liens place le chemin complet et le nom de fichier du fichier PDB associé dans la DLL ou le fichier exécutable. Quand vous déboguez, le débogueur vérifie d’abord si le fichier de symboles existe à l’emplacement spécifié dans la DLL ou le fichier exécutable. Cela est utile, car vous avez toujours des symboles disponibles pour le code que vous avez compilé sur votre ordinateur.

• PDB qui peuvent être présents dans le même dossier que la DLL ou le fichier exécutable.

• Tout dossier de cache de symboles local.

• Tous les serveurs de symboles des partages de fichiers du réseau local.

• Tous les serveurs de symboles Internet, par exemple le serveur de symboles Microsoft.

Pour vérifier que vous disposez de tous les PDB nécessaires à un débogage précis, installez les outils de débogage pour Windows. Vous trouverez les versions 32 bits et 64 bits sur Outils de débogage pour Windows.

symchk.exe est un outil utile installé avec ce package. Il permet d’identifier les symboles manquants ou incorrects. Cet outil dispose d’un grand nombre d’options de ligne de commande potentielles. Voici deux des plus utiles et des plus couramment utilisées.

Vérifier si une DLL ou un fichier .exe donné et un PDB situés dans le même dossier correspondent

"c:\Program Files\Debugging Tools for Windows\symchk" testing.dll /s .

SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1

L’option /s indique à symchk de rechercher les symboles uniquement dans le dossier actif, et de ne pas effectuer de recherches dans les serveurs de symboles.

Vérifier si toutes les DLL et tous les fichiers exécutables d’un ensemble de dossiers ont des PDB correspondants

"c:\Program Files\Debugging Tools for Windows\symchk" *.* /r

L’option /r indique à symchk de parcourir les dossiers de manière récursive pour vérifier que tous les fichiers exécutables ont des PDB correspondants. Sans l’option /s, symchk utilise la variable _NT_SYMBOL_PATH active pour rechercher les symboles sur un serveur privé ou un serveur local, ou sur les serveurs de symboles Microsoft. L’outil symchk recherche uniquement les symboles pour les fichiers exécutables (.exe, .dll et similaires). Vous ne pouvez pas utiliser de caractères génériques pour la recherche de symboles pour les fichiers non exécutables.

Fonctionnement de symchk

Quand l’éditeur de liens génère des fichiers .dll, des exécutables et des PDB, il stocke les GUID identiques dans chaque fichier. Le GUID est utilisé par les outils pour déterminer si un fichier PDB donné correspond à une DLL ou à un fichier exécutable. Si vous modifiez une DLL ou un fichier exécutable, en utilisant un éditeur de ressources, en ajoutant un codage de protection contre la copie, ou en modifiant ses informations de version, le GUID est mis à jour, ce qui empêche le débogueur de charger le fichier PDB correspondant. C’est la raison pour laquelle il est très important d’éviter de manipuler la DLL ou le fichier exécutable après sa création par l’éditeur de liens.

Vous pouvez également utiliser l’utilitaire DUMPBIN fourni avec VS.NET pour afficher les chemins de symboles recherchés, et voir s’il existe des fichiers de symboles qui correspondent à une DLL ou un fichier exécutable donné. Par exemple :

DUMPBIN /PDBPATH:VERBOSE filename.exe

Serveurs de symboles

Un serveur de symboles est un dépôt pour plusieurs versions de fichiers exécutables et de fichiers de symboles. Il contient soit les fichiers de symboles eux-mêmes, soit des pointeurs vers les fichiers de symboles associés. Les débogueurs savent comment utiliser les serveurs de symboles, et peuvent s’en servir pour rechercher les symboles manquants ou inconnus.

Les DLL et les fichiers exécutables sont également disponibles auprès du serveur de symboles Microsoft. Cela permet de déboguer les incidents, et d’examiner le code de fichiers de système d’exploitation qui n’existent peut-être pas sur votre machine. Si un débogueur rencontre un fichier exécutable ou une DLL qui n’existe pas sur le système que vous utilisez pour le débogage, il demande automatiquement les symboles et une copie du fichier binaire aux serveurs de symboles Microsoft. Cela est utile si vous déboguez un composant qui a de nombreuses versions, par exemple msvcrt.dll, et si vous devez examiner le code d’une version qui n’existe pas sur votre ordinateur. Cela permet également de déboguer les minidumps générés sur un système d’exploitation différent du système que vous utilisez pour le débogage.

Microsoft publie tous les fichiers PDB pour tous les systèmes d’exploitation et autres composants redistribués, par exemple le kit SDK DirectX, sur son serveur de symboles accessible de manière externe. Cela facilite le débogage d’une application qui utilise ces DLL ou ces fichiers exécutables. Vous pouvez utiliser le serveur de symboles Microsoft pour résoudre les symboles ainsi que les symboles locaux des composants générés sur votre ordinateur.

Vous pouvez configurer votre ordinateur pour utiliser le serveur de symboles Microsoft, qui vous donne accès à tous les fichiers de symboles Microsoft. Vous pouvez également configurer un serveur de symboles privé pour votre entreprise, votre équipe ou votre réseau. Vous pouvez l’utiliser pour stocker plusieurs anciennes versions d’un projet sur lequel vous travaillez, ou pour servir de cache local des symboles que vous utilisez à partir du serveur de symboles Microsoft.

Pour utiliser un serveur de symboles, spécifiez le chemin de recherche dans une variable d’environnement appelée _NT_SYMBOL_PATH. Les débogueurs et les outils modernes, par exemple WinDbg, NTSD ou Visual Studio, utilisent automatiquement ce chemin pour rechercher des symboles.

Quand un débogueur recherche des symboles, il effectue d’abord la recherche localement. Il effectue ensuite ses recherches sur les serveurs de symboles. Quand il trouve un symbole correspondant, il transfère le fichier de symboles vers votre cache local. Les symboles d’une DLL ou d’un fichier exécutable classique ont une taille comprise entre 1 et 100 Mo. Ainsi, si vous déboguez un processus qui inclut de nombreuses DLL, la résolution de tous les symboles et leur transfert vers un cache local peut prendre un certain temps.

Utilisation du serveur de symboles Microsoft

Le serveur de symboles Microsoft vous permet d’obtenir tous les derniers symboles, notamment les symboles des fichiers corrigés ou mis à jour. Le serveur de symboles Microsoft est disponible à l’adresse https://msdl.microsoft.com/download/symbols.

Vous pouvez accéder au serveur de symboles de l’une des manières suivantes :

• Entrez directement l’adresse du serveur. Dans Visual Studio, dans le menu Outils, choisissez Options, Débogage, puis Symboles.

• Utilisez la variable d’environnement _NT_SYMBOL_PATH. Nous recommandons cette méthode.

  Elle est utilisée par tous les outils de débogage. Elle est également utilisée par Visual Studio. Elle est lue et décodée à l’ouverture de Visual Studio. Aussi, si vous la changez, vous devrez redémarrer Visual Studio.

  Cette variable d’environnement vous permet de spécifier plusieurs serveurs de symboles, par exemple un serveur de symboles privé interne. Elle vous permet également de spécifier un répertoire de cache local pour stocker les PDB de tous les symboles que vous recherchez à partir de serveurs de symboles, à la fois de manière interne et sur Internet.

La syntaxe de la variable _NT_SYMBOL_PATH est la suivante :

srv*[local cache]*[private symbol server]*https://msdl.microsoft.com/download/symbols

Remplacez [local cache] (cache local) par le nom d’un répertoire de votre ordinateur où vous souhaitez stocker un cache de tous les symboles utilisés, par exemple %SYSTEMROOT%\Symbols ou c:\symbols.

[private symbol server] (serveur de symboles privé) est facultatif. Elle peut pointer vers un serveur de symboles situé sur votre réseau, ou vers un serveur de symboles partagé par votre équipe, la division Produits ou votre entreprise.

Pour utiliser uniquement le serveur de symboles Microsoft avec un cache local de symboles, et accélérer l’accès via Internet, utilisez le paramètre suivant pour _NT_SYMBOL_PATH :

srv*c:\symbols*https://msdl.microsoft.com/download/symbols

Vous trouverez d’autres options pour _NT_SYMBOL_PATH dans le fichier d’aide installé avec le package Outils de débogage Microsoft pour Windows.

Les exécutables sans symboles peuvent rallonger le temps nécessaire au lancement d’un débogueur si vous utilisez un serveur de symboles. En effet, le débogueur interroge le serveur de symboles chaque fois qu’il tente de charger l’exécutable. C’est la raison pour laquelle il est préférable de toujours demander des symboles pour tous les composants.

Parfois, il n’est pas possible de demander des symboles pour chaque composant. Par exemple, les pilotes vidéo peuvent avoir des DLL dans votre espace de processus, mais les fichiers PDB nécessaires sont disponibles sur le serveur de symboles Microsoft. Dans ce cas, il existe un petit délai quand vous démarrez une session de débogage.

Pour éviter ce petit délai, vous pouvez exécuter le débogueur une seule fois, afin de mettre en cache tous les symboles localement à partir du serveur de symboles Microsoft. Modifiez ensuite votre variable _NT_SYMBOL_PATH pour supprimer le serveur de symboles Microsoft. À moins que les fichiers exécutables changent, les recherches de fichiers exécutables qui n’ont pas de symboles ne nécessitent pas de requête via Internet, car vous disposez de copies dans le cache local de tous les symboles dont vous avez besoin à partir du serveur de symboles Microsoft.

Obtention manuelle des symboles

Si vous avez correctement configuré votre débogueur, il charge automatiquement tous les symboles nécessaires à partir de votre cache local ou d’un serveur de symboles. Si vous souhaitez obtenir les symboles d’un seul exécutable ou d’un dossier d’exécutables, vous pouvez utiliser symchk. Par exemple, si vous souhaitez télécharger les symboles du fichier d3dx9_30.dll situé dans le dossier système de Windows vers le répertoire actif, vous pouvez utiliser la commande suivante :

"c:\Program Files\Debugging Tools for Windows\symchk" c:\Windows\System32\d3dx9_30.dll /oc \.

L’outil symchk a de nombreuses autres utilisations. Pour plus d’informations, consultez symchk /? ou la documentation des Outils de débogage Microsoft pour Windows.

Configuration d’un serveur de symboles

La configuration d’un serveur de symboles est très simple. Elle est utile pour les raisons suivantes :

• Pour économiser de la bande passante, ou pour accélérer la résolution des symboles pour votre entreprise, votre équipe ou votre produit. Un serveur de symboles interne sur un partage de fichiers local de votre réseau met en cache toutes les références aux serveurs de symboles externes, par exemple le serveur de symboles Microsoft. Un serveur de symboles local ou interne est accessible rapidement à de nombreuses personnes en même temps. Ainsi, il permet d’économiser de la bande passante et d’éviter la latence que les demandes de symboles en double peuvent créer.
• Pour stocker les symboles d’anciennes builds, versions ou versions externes de votre application. En stockant les symboles de ces builds sur un serveur de symboles auquel vous pouvez facilement accéder, vous pouvez déboguer les incidents et les problèmes liés à ces builds sur tout ordinateur disposant d’un débogueur et d’une connexion au serveur de symboles local. Cela est particulièrement utile si vous déboguez des minidumps générés par des exécutables que vous n’avez pas générés vous-même, c’est-à-dire des builds générées par un autre programmeur ou par une machine de build. Si les symboles de ces builds sont stockés sur votre serveur de symboles, vous disposerez d’un débogage fiable et précis.
• Pour garder les symboles à jour. Quand des composants sont mis à jour, par exemple les composants de système d’exploitation modifiés par Windows Update ou par le kit SDK DirectX, vous pouvez tout de même déboguer à l’aide de tous les derniers symboles.

La configuration d’un serveur de symboles sur votre propre réseau local revient à créer un partage de fichiers sur un serveur, et à octroyer aux utilisateurs les autorisations complètes pour accéder au partage ainsi que pour créer des fichiers et des dossiers. Ce partage doit être créé sur un système d’exploitation serveur, par exemple Windows Server 2003, pour que le nombre de personnes pouvant accéder simultanément au partage ne soit pas limité.

Par exemple, si vous configurez un partage de fichiers sur \\mainserver\symbols, les membres de votre équipe affectent ce qui suit à _NT_SYMBOL_PATH :

Srv*c:\symbols*\\mainserver\symbols*https://msdl.microsoft.com/download/symbols

Au fur et à mesure de la récupération des symboles, les fichiers et les dossiers apparaissent dans le répertoire partagé \\mainserver\symbols ainsi que dans les caches individuels, au sein du répertoire c:\symbols.

Il s’agit généralement de tout ce qui est impliqué dans la configuration et l’utilisation de votre propre serveur de symboles ou du serveur de symboles Microsoft.

Ajout de symboles à un serveur de symboles

Pour ajouter, supprimer ou modifier des fichiers sur un partage de serveur de symboles, utilisez l’outil symstore.exe. Cet outil fait partie du package Outils de débogage Microsoft pour Windows. Une documentation complète sur les serveurs de symboles, l’outil Symstore et l’indexation des symboles est incluse dans le package Outils de débogage pour Windows.

Vous pouvez ajouter des symboles directement à votre propre serveur de symboles, dans le cadre d’un processus de génération, ou mettre les symboles à la disposition de toute votre équipe pour les bibliothèques ou outils tiers. Le processus d’ajout d’un symbole à un partage de fichiers de serveur de symboles s’appelle l’indexation des symboles. Il existe deux façons courantes d’indexer les symboles. Vous pouvez copier un fichier de symboles sur le serveur de symboles. Vous pouvez également copier un pointeur vers l’emplacement du symbole sur le serveur de symboles. Si vous disposez d’un dossier d’archivage qui contient vos anciennes builds, vous pouvez indexer les pointeurs vers les fichiers PDB déjà présents sur le partage, au lieu de dupliquer les symboles. Dans la mesure où les symboles peuvent parfois atteindre des dizaines de mégaoctets, il est recommandé de planifier à l’avance l’espace dont vous avez besoin pour archiver toutes les builds de votre projet tout au long du développement. Si vous indexez uniquement des pointeurs vers des symboles, vous pouvez rencontrer des problèmes quand vous supprimez d’anciennes builds, ou quand vous changez le nom d’un partage de fichiers.

Par exemple, pour indexer de manière récursive tous les symboles dans c:\dxsym\Extras\Symbols, que vous avez obtenus à partir du kit SDK DirectX d’octobre 2006 sur un partage de fichiers de serveur de symboles appelé \\mainserver\symbols, vous pouvez utiliser la commande suivante :

"c:\Program Files\Debugging Tools for Windows\symstore" add /f "C:\dxsym\Extras\Symbols\*.pdb"
/s \\mainserver\symbols /t "October 2006 DirectX SDK " /r

Le paramètre /t "commentaire" permet d’ajouter une description à la transaction qui a ajouté les symboles. Cela peut être utile quand vous effectuez des tâches d’administration sur les symboles.

Meilleures pratiques

• Configurez votre propre partage de fichiers de serveur de symboles pour votre équipe, votre entreprise ou votre produit.
• Configurez la variable _NT_SYMBOL_PATH pour qu’elle pointe vers un cache local, un serveur de symboles privé et le serveur de symboles Microsoft.
• Si un débogueur ne peut pas charger les symboles d’un composant que vous déboguez, contactez le propriétaire du composant pour demander les symboles, ou au moins un PDB réduit.
• Configurez un système de build automatisée pour indexer les symboles sur votre serveur de symboles privé pour chaque build produite. Vérifiez que les builds que vous distribuez sont celles générées par ce processus. Cela permet de garantir que les symboles sont toujours disponibles pour déboguer les problèmes.
• Configurez un serveur de symboles pour permettre aux débogueurs d’accéder au code source d’un module spécifique directement à partir d’un système de contrôle de code source basé sur Visual Source Safe ou Perforce. Si les informations et les symboles des fichiers sources d’une version publiée d’un jeu sont indexés, les développeurs qui ont accès à votre serveur de symboles peuvent effectuer un débogage complet au niveau du code source pour les problèmes signalés, sans conserver les environnements de build ou les anciennes versions des fichiers sources sur leurs ordinateurs de développement. Pour configurer votre serveur de symboles afin d’autoriser l’indexation des informations relatives aux fichiers sources, consultez la documentation du serveur source.