Umdhtools.exe : Comment utiliser Umdh.exe pour rechercher la mémoire des fuites

Traductions disponibles Traductions disponibles
Numéro d'article: 268343 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Sommaire

Résumé

L'utilitaire de segments de mémoire (UMDH) de vidage en mode utilisateur fonctionne avec les système d'exploitation pour analyser les allocations de tas Windows d'un processus spécifique. Cet utilitaire et les autres outils qui lui sont associées, sont principalement les pour Windows 2000 et Windows XP. Cliquez sur le Jouer bouton pour afficher cette démonstration multimédia en continu.

Remarque La vidéo est codée avec les codec ACELP ®, vous devez installer le codec ACELP ® libre disponible à l'adresse http://www.ACELP.NET/acelp_eval.PHP



Remarque Étant donné que le malloc fonction dans le module d'exécution C (CRT) utilise l'omission du pointeur frame (FPO) sur la version d'origine de Windows Server 2003, vous ne verrez peut-être les informations de la pile complète de la malloc fonction à l'aide de l'outil UMDH. Ce problème est résolu dans le module de CRT de Windows Server 2003 Service Pack 1 (SP1). Par conséquent, vous pouvez voir les informations de la pile complète de la fonction de malloc dans Windows Server 2003 SP1.

Plus d'informations

Avant d'utiliser UMDH

Si vous pensez que vous êtes confronté à une fuite de mémoire, vous devez savoir que les fuites ne soient pas ce qu'ils semblent être de la mémoire. Vous pouvez découvrir qu'un fuite de mémoire n'est pas une fuite de mémoire true, mais est une amélioration des performances. Pour exemple, le moteur de base de données Microsoft Jet peut consommer de grandes quantités de mémoire (jusqu'à 128 Mo sur un ordinateur 256 Mo), car il récupère des données et écrit met en cache. Le cache permet le moteur Jet pour obtenir rapidement et lecture et écriture anticipée mise en mémoire tampon.

Pour déterminer si un processus connaît mémoire fuites, utilisez l'Analyseur de performances Windows (Perfmon.exe) et surveiller privé Octets dans la catégorie de processus pour votre application. Octets privés sont le quantité totale de mémoire que le processus a alloué, mais n'est pas partager avec d'autres processus. Notez que cela est différent d'octets virtuels, qui est également intéressants à surveiller. Octets virtuels est la taille actuelle en octets de la espace d'adressage virtuel qui utilise le processus. Une application peut perdre virtuel mémoire, mais ne peut ne pas voir une différence dans les octets privés qui sont attribuées. Si vous ne voyez pas de mémoire augmente lorsque vous surveillez les octets privés, mais que vous que vous suspectez que vous exécutez encore plus de mémoire, octets virtuels de moniteur pour voir Si vous n'utilisez pas de mémoire virtuelle. Pour plus d'informations sur la détection des fuites de mémoire et de la vue d'ensemble de l'Analyseur de performances (Perfmon.exe) de Windows, reportez-vous au site Web de Microsoft à l'adresse suivante :
http://msdn.Microsoft.com/en-us/library/ms404355.aspx
Pour vous assurer que votre application est une fuite de mémoire, placez le pensez que le code dans une boucle avec un nombre d'itérations et puis surveiller privé et octets virtuels pour toute augmentation de la mémoire. Regarder pour vous assurer que le nombre octets privés et octets virtuels ne pas finalement reste la même et la nombre cesse d'augmenter. S'il existe un point cesse de la mémoire augmentation, (par exemple, il ne continue pas de grimper indéfiniment) vous faire pas une fuite de mémoire, mais plus probablement, vous consultez un cache qui se développe pour son taille maximale.

Si vous déterminez que vous voyez une fuite de mémoire avant de vous utilisation de UMDH, procédez comme suit :
  1. Installez l'utilitaire UMDH.
  2. Définissez la variable d'environnement de chemin d'accès système pour inclure le dossier où vous avez installé UMDH.
  3. Affectez à la variable d'environnement _NT_SYMBOL_PATH le Chemin d'accès au serveur de symboles Microsoft afin que les UMDH pouvez rechercher des symboles de débogage fichiers.
L'utilitaire UMDH est fourni avec les outils de débogage pour Produits de Windows sur le site Web de Microsoft à l'adresse suivante :
http://www.Microsoft.com/whdc/devtools/DDK/default.mspx
Télécharger et installer l'utilitaire et ensuite définir le système de chemin d'accès variable d'environnement pour le chemin d'accès où sont installés les outils de débogage.

Avant d'utiliser UMDH, vous devez installer les symboles de débogage correct les composants de votre application et votre système d'exploitation. Utiliser Microsoft Serveur de symboles pour acquérir des symboles de débogage pour les composants de Microsoft. Pour plus d'informations à propos de Microsoft Symbol Server, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
311503Utiliser Microsoft Symbol Server pour obtenir des fichiers de symboles de débogage
UMDH essaie de trouver les fichiers de symboles à l'aide de la Variable d'environnement _NT_SYMBOL_PATH. La commande pour définir le chemin d'accès à partir d'un invite de commande peut être semblable au suivant :
Set _NT_SYMBOL_PATH = SRV * c:\LocalSymbolCache
Pour plus d'informations sur la configuration de débogage symbolique informations, consultez la section « Symboles de débogage » plus loin dans cet article.

Après avoir effectué ces étapes, vous êtes prêt à utiliser l'utilitaire UMDH.

Capture de tas Dumps avec UMDH

UMDH est un utilitaire qui exporte les informations sur le tas allocations d'un processus. Cette information comprend la pile des appels pour chaque allocation, le nombre d'allocations effectuées par le biais de cette pile des appels, et le nombre d'octets qui sont consommés par le biais de cette pile des appels. Par exemple :
00005320 bytes in 0x14 allocations (@ 0x00000428) by: BackTrace00053
           ntdll!RtlDebugAllocateHeap+0x000000FD
           ntdll!RtlAllocateHeapSlowly+0x0000005A
           ntdll!RtlAllocateHeap+0x00000808
           MyApp!_heap_alloc_base+0x00000069
           MyApp!_heap_alloc_dbg+0x000001A2
           MyApp!_nh_malloc_dbg+0x00000023
           MyApp!_nh_malloc+0x00000016
           MyApp!operator new+0x0000000E
           MyApp!LeakyFunc+0x0000001E
           MyApp!main+0x0000002C
           MyApp!mainCRTStartup+0x000000FC
           KERNEL32!BaseProcessStart+0x0000003D
				
Cette sortie UMDH indique qu'il y avait des 21280 (0x5320) octets alloués total à partir de la pile des appels. Les octets 21280 ont été allouées à partir de 20 (0 x 14) Séparez les allocations d'octets 1064 (0x428). La pile des appels sont donnée une identificateur de BackTrace00053.

Pour générer un fichier dump du tas allocations, vous devez utiliser l'utilitaire Gflags.exe, qui est également inclus avec les produits des outils de débogage pour Windows, pour informer le système d'exploitation qui vous souhaitez que le noyau pour suivre les allocations.

Supposez que vous voulez Pour vider le contenu de heap(s) de Notepad.exe. Vous devez d'abord activer trace de pile acquisition de l'application que vous souhaitez tester. Par défaut, cette fonctionnalité n'est pas activé. La commande pour activer cette fonctionnalité est la suivante :
Gflags -i notepad.exe + ustcréation
La commande ne permet pas de trace de pile pour les processus qui sont en cours d'exécution, mais elle active le suivi de pile pour toutes les exécutions ultérieures de Notepad.exe. vous pouvez également définir l'indicateur par le biais de l'utilisateur GFLAGS interface (exécutez Gflags.exe sans arguments pour obtenir de l'interface utilisateur). Utilisation le -ustcréation option de gflags désactiver le suivi de pile lorsque vous êtes après le débogage.

Lorsque vous définissez les indicateurs de l'image par le biais de Gflags.exe, et vous configurez les symboles de débogage, vous êtes prêt à démarrer le bloc-notes (le application à l'aide de UMDH). Une fois que le programme est démarré, vous devez : déterminer l'ID de processus (PID) du processus Notepad qui vient de démarrer. La commande est la suivante :
tlist
Vous pouvez trouver le PID de la sortie de l'application TLIST. Les informations de PID peuvent également être obtenues à partir du Gestionnaire de tâches. Supposons que le PID de le processus du bloc-notes que vous venez de démarrer est 124. Vous pouvez utiliser UMDH pour obtenir un dump du tas avec la commande suivante :
Umdh - p: 124 - f:notepad124.log
Résultats: Vous disposez d'un dump de tas complet du processus Notepad dans la Fichier Notepad124.log. Ce fichier répertorie tous les allocations qui ont été apportées et les piles d'appels où les allocations ont été effectuées.

Utiliser Umdh.exe pour comparer les journaux UMDH

Alors que le fichier journal UMDH contient des informations précieuses sur le état actuel, les segments de mémoire pour un processus, si vous êtes soucieux de trouver un fuite de mémoire, il peut s'avérer plus intéressant de comparer les sorties de deux journaux et Découvrez de quelle pile d'appels a connu la croissance la plus grande entre les fichiers de vidage de deux. L'utilitaire Umdh.exe permet de comparer deux journaux UMDH pour fournir une analyse de la différence entre les deux. Une fois que deux journaux capturées à différents intervalles, vous pouvez ensuite utiliser la commande suivante :
UMDH dh1.log dh2.log > cmp12.txt
- ou -
UMDH -d dh1.log dh2.log > cmp12.txt
Le -d option de ligne de commande indique à UMDH pour afficher au format décimal au lieu de hexadécimal. La sortie de la commande compare les différences de la allocations entre ces deux journaux et fournit des informations qui sont similaires à les éléments suivants :
+ 5320 (f110 - 9df0) 3 a allocations BackTrace00053 Nombre total d'augmentation == 5320
Pour chaque suivi dans les fichiers journaux UMDH, il existe une comparaison faite entre les fichiers journaux des deux. Ce cas montre que le dernier fichier journal est spécifié dans la UMDH ligne de commande était 0xF110 d'octets alloués lors de la première journal dans la ligne de commande UMDH avait 0x9DF0 d'octets alloués pour le suivi de même (callstack). Le « 5320 » est la différence entre le nombre d'octets alloués. Dans le cas présent, il existait des octets alloués entre les heures de 0x5320 que le deux journaux ont été capturées. Les octets provient de la pile des appels qui sont identifiée par « BackTrace00053 ».

L'étape suivante consiste à découvrir les nouveautés dans la mesure où backtrace. Si vous ouvrez le deuxième fichier journal et recherchez BackTrace00053, vous pouvez trouver quelque chose semblable au suivant :
00005320 bytes in 0x14 allocations (@ 0x00000428) by: BackTrace00053
           ntdll!RtlDebugAllocateHeap+0x000000FD
           ntdll!RtlAllocateHeapSlowly+0x0000005A
           ntdll!RtlAllocateHeap+0x00000808
           MyApp!_heap_alloc_base+0x00000069
           MyApp!_heap_alloc_dbg+0x000001A2
           MyApp!_nh_malloc_dbg+0x00000023
           MyApp!_nh_malloc+0x00000016
           MyApp!operator new+0x0000000E
           MyApp!LeakyFunc+0x0000001E
           MyApp!main+0x0000002C
           MyApp!mainCRTStartup+0x000000FC
           KERNEL32!BaseProcessStart+0x0000003D
				
Lorsque vous affichez la pile des appels, vous pouvez voir que le LeakyFunc fonction alloue la mémoire par l'intermédiaire de la bibliothèque Runtime Visual C++ fonction de nouvel opérateur. Si vous trouvez que le nombre d'allocations augmente en tant que vous prendre davantage de fichiers de vidage, vous pouvez conclure que la mémoire n'est pas libéré.

Activation des Traces de pile

Les informations les plus importantes dans les journaux UMDH sont les traces de pile des allocations de tas. Vous pouvez les analyser pour vérifier si un processus de fuites de tas mémoire. Par défaut, ces traces de pile ne sont pas acquis. Vous pouvez activer cette fonctionnalité par processus ou à l'échelle du système. Utilisez la commande suivante pour activer la pile le suivi du système :
Gflags - r + ustcréation
Redémarrez l'ordinateur après cette commande. Pour chaque processus l'activation, la commande est la suivante :
Gflags -i APPNAME + ustcréation
APPNAME est le nom de fichier du fichier exécutable, y compris l'extension (pour exemple Services.exe, Lsass.exe). La commande n'active pas le suivi de pile pour un processus en cours d'exécution. Par conséquent, pour les processus que vous ne pouvez pas Redémarrez (par exemple, services, lsass, winlogon), vous devez redémarrer votre test ordinateur.

Utilisez les commandes suivantes pour vérifier que les paramètres été défini au niveau du système ou d'un processus spécifique: à l'échelle du système :
Gflags - r
Processus spécifiques :
Gflags -i nom de l'application
Par défaut, la profondeur de trace de pile maximale est 16. Si vous souhaitez consultez les piles d'appels plus profond, vous pouvez l'augmenter en exécutant GFLAGS. Cliquez pour sélectionner Registre système, puis tapez une nouvelle profondeur dans le Max. Profondeur de Capture de Trace de pile contrôle d'édition. Cliquez sur Appliquer, puis redémarrez l'ordinateur.
IMPORTANT: Si vous utilisez Windows NT 4.0 Service Pack 6, vous devez utiliser Umdh_nt4.exe, au lieu de Umdh.exe et vous devez utiliser le Gflags -r commande définir la trace de pile de l'échelle du système. Assurez-vous que vous Redémarrez votre ordinateur. Suivi de pile Umdh_nt4 ne fonctionne pas sur un processus base sous Windows NT version 4. Elle doit être définie pour l'ensemble du système.

Symboles de débogage

Une des étapes plus importantes à l'aide de UMDH est de s'assurer que les fichiers de symboles bonne (fichiers .dbg ou .pdb) pour obtenir une trace de pile bonne. Vous devez au minimum, les fichiers de symboles Kernel32.dbg et Ntdll.dbg. Vous pouvez acquérir des symboles de débogage supplémentaires que vous devrez peut-être que vous en savoir plus Quels composants une fuite de mémoire. Pour plus d'informations Comment faire obtenir les fichiers de symboles de débogage pour Microsoft composants, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
311503Utiliser Microsoft Symbol Server pour obtenir des fichiers de symboles de débogage
Pour plus d'informations sur l'utilisation de la Microsoft Symbol Server et obtenir les packages de symboles de Windows, visitez le site Web de Microsoft suivant :
http://www.Microsoft.com/whdc/devtools/DDK/default.mspx
Lorsque vous générez des composants avec Visual C++, il est important que n'avez pas de base de données de programme pour modifier et continuer sélectionné pour le C++ options du compilateur. Au lieu de cela, sélectionnez base de données du programme. Pour définir le chemin de symbole Initialisez la variable d'environnement _NT_SYMBOL_PATH au chemin d'accès à utiliser. Vous pouvez utiliser Microsoft Symbol Server pour obtenir des symboles pour Microsoft composants.
311503 Utiliser Microsoft Symbol Server pour obtenir des fichiers de symboles de débogage
Suivez ces étapes pour définir les variables _NT_SYMBOL_PATH variable d'environnement :
  1. Dans le panneau de configuration, double-cliquez sur Système.
  2. Cliquez sur le Avancée onglet, puis cliquez sur Variables d'environnement.
Ou vous pouvez définir la variable d'environnement _NT_SYMBOL_PATH dans un fenêtre de commande avant l'exécution de UMDH.

REMARQUE: Également inclure le chemin d'accès pour les fichiers PDB pour les composants de votre application. Par exemple, définir le chemin d'accès _NT_SYMBOL_PATH au suivant :
SRV*c:\Symbols*http://msdl.Microsoft.com/download/symbols;c:\myapplicationssymbols
La première partie de ce chemin d'accès pointant vers le serveur de symboles Microsoft et états que les symboles utilisés seront téléchargés dans le c:\symbols dossier. La partie qui suit le point-virgule est le chemin d'accès aux fichiers PDB (les fichiers de symboles) spécifiquement pour l'application de fuite.

L'appel de UMDH

Le seul paramètre de ligne de commande requis pour UMDH est le -p option, qui spécifie le PID du processus à partir de laquelle un segment de mémoire vidage sera obtenue. Le PID peut être obtenu à l'aide du Gestionnaire des tâches ou de la Programme tlist.exe. Pour une commande semblable à celui-ci, le journal sera exportée vers la sortie standard :
Umdh - p: PID
UMDH affiche également les divers messages d'information standard erreur, et par conséquent, si vous le redirige pas, il est mélangé avec le journal réel. Pour collecter les messages d'information UMDH dans un fichier, utilisez la commande suivante :
Umdh - p: PID 2>umdh.msg
Si vous souhaitez collecter le journal est exportée par UMDH dans un fichier, Utilisez l'une des commandes suivantes :
Umdh - p: PID > umdh.log
- ou -
Umdh - p: PID-f:umdh.log
Ces commandes sont équivalentes.

Le journal par défaut qui est obtenu par UMDH contient une énumération des consommateurs de tas sont triés par nombre d'allocations. Si, pour le débogage, vous devez également un fichier de vidage de tous les des blocs alloués avec leurs traces de pile correspondante, le -d option peut être utilisée :
Umdh - p: PID -d
Si vous utilisez cette commande, vous verrez les éléments suivants dans la UMDH fichier journal :
Allocations de trace BackTrace00046 : 005F69A0 005F6150
Ce sont des allocations pour que les adresses de mémoire pile des appels. Si votre débogueur est attaché au processus, vous pouvez vider le contenu de la mémoire à ces adresses pour voir ce qui a été alloué.

Si le journal contient trop d'informations, il peut être limité uniquement à comptent les gros utilisateurs qui disposent de l'allocation dépasse le seuil. Utiliser le commande suivante :
Umdh - p: PID - t: seuil
Toutes les options de ligne de commande (par exemple, -p, -f, -t, -d) peuvent être spécifiées simultanément dans n'importe quel ordre. Voici un exemple de ligne de commande plus difficile :
Umdh - p: 123 - t: 1000 - f:umdh.log -d
Cette commande exporte les tas du processus avec PID 123 dans le fichier Umdh.log. Elle exporte uniquement les traces de pile ce compte pour plus de 1000 allocations et elle vide également les adresses des blocs de tas sont allouée par le biais de chaque trace de la pile.

L'option UMDH un autre le -l option. Cela entraîne des numéros de fichier et la ligne à imprimer dans le pile des appels dès que possible.

Expliqué des résultats UMDH

Si vous redirigé le journal à un fichier ()Umdh - p: PID-f:umdh.log), le contenu est similaire à la suivante, qui a été obtenue à partir d'un processus Notepad en cours d'exécution :
UMDH: Logtime 2000-06-28 10:54 - Machine=MYMachine - PID=704
   *********** Heap 00270000 Information ********************
       Flags: 58000062
       Number Of Entries: 87
       Number Of Tags: <unknown>
       Bytes Allocated: 00008DF0
       Bytes Committed: 0000A000
       Total FreeSpace: 00001210
       Number of Virtual Address chunks used: 1
       Address Space Used: <unknown>
       Entry Overhead: 8
       Creator:  (Backtrace00007)
           ntdll!RtlDebugCreateHeap+0x00000196
           ntdll!RtlCreateHeap+0x0000023F
           ntdll!LdrpInitializeProcess+0x00000369
           ntdll!LdrpInitialize+0x0000028D
           ntdll!KiUserApcDispatcher+0x00000007
   *********** Heap 00270000 Hogs ********************
   000001A0 bytes in 0x4 allocations (@ 0x00000068) by: BackTrace00031
           ntdll!RtlDebugAllocateHeap+0x000000FB
           ntdll!RtlAllocateHeapSlowly+0x0000005B
           ntdll!RtlAllocateHeap+0x00000D81
           ntdll!LdrpAllocateDataTableEntry+0x00000039
           ntdll!LdrpMapDll+0x000002A4
           ntdll!LdrpLoadImportModule+0x0000010D
           ntdll!LdrpWalkImportDescriptor+0x0000008B
           ntdll!LdrpLoadImportModule+0x0000011D
           ntdll!LdrpWalkImportDescriptor+0x0000008B
           ntdll!LdrpLoadImportModule+0x0000011D
           ntdll!LdrpWalkImportDescriptor+0x0000008B
           ntdll!LdrpInitializeProcess+0x000009DC
           ntdll!LdrpInitialize+0x0000028D
           ntdll!KiUserApcDispatcher+0x00000007

   000001A0 bytes in 0x4 allocations (@ 0x00000068) by: BackTrace00034
           ntdll!RtlDebugAllocateHeap+0x000000FB
           ntdll!RtlAllocateHeapSlowly+0x0000005B
           ntdll!RtlAllocateHeap+0x00000D81
           ntdll!LdrpAllocateDataTableEntry+0x00000039
           ntdll!LdrpMapDll+0x000002A4
           ntdll!LdrpLoadImportModule+0x0000010D
           ntdll!LdrpWalkImportDescriptor+0x0000008B
           ntdll!LdrpLoadImportModule+0x0000011D
           ntdll!LdrpWalkImportDescriptor+0x0000008B
           ntdll!LdrpLoadImportModule+0x0000011D
           ntdll!LdrpWalkImportDescriptor+0x0000008B
           ntdll!LdrpLoadImportModule+0x0000011D
           ntdll!LdrpWalkImportDescriptor+0x0000008B
           ntdll!LdrpInitializeProcess+0x000009DC
           ntdll!LdrpInitialize+0x0000028D
           ntdll!KiUserApcDispatcher+0x00000007
				
Le journal contient un vidage de chaque segment de mémoire dans le processus. Dans cet exemple, le journal commence par un segment de mémoire à l'adresse 270000. Après quelques compteurs globaux de le tas, le journal contient un vidage de l'ordre de tri décroissant des traces de pile qui sont responsables de la plupart des allocations. Lorsque vous comparez la dynamique de mémoire qui sont utilisés à des moments différents, vous pouvez déduire de ce qui s'est produite dans le processus et si l'utilisation du tas est semblable à une fuite.

Problèmes que vous pouvez rencontrer lorsque vous utilisez UMDH

Les erreurs les plus courantes lorsque vous utilisez UMDH dû pile suivi n'est pas activé. En outre, des symboles incorrects Ntdll.dll empêchent UMDH à partir de en cours d'exécution. Pour les autres fichiers de symboles, UMDH s'exécute, mais le fichier journal contient la pile traces qui n'ont pas de noms de fonction mais plutôt que par des adresses relatives à l'intérieur de modules. Une erreur de troisième lointains consiste à spécifier un PID erroné. Les éléments suivants résultats de message d'erreur lorsque vous essayez d'exécuter UMDH pour un processus qui n'a pas suivi de pile activé :
C:\>Umdh - p: UMDH de 1140 : temps de journalisation 2000-06-28 12 : 43 - Machine = MyMachine - PID = 1140 connexion.....Module énumération complète. SymGetSymFromName (processus, ntdll !RtlpStackTraceDataBase, xxx) a échoué, LastError = 126 UmdhGetAddrFromName Impossible de trouver la base de données de Trace de pile pointeur (ntdll !RtlpStackTraceDataBase). les symboles de Ntdll.dll sont incorrectes ; Nous doit être en mesure de voir les symboles à l'importation.
Utilisez la commande suivante pour Vérifiez les paramètres pour le processus que vous recherchez :
Gflags -i APPNAME
Utilisez la commande suivante lorsque vous fier à l'échelle du système de pile suivi :
Gflags - r
Ces commandes afficher la liste des indicateurs définis pour l'application. Notez que dans le cas de suivi de pile de l'échelle du système, la fonction peut apparaître en tant que Active, mais si vous n'avez pas redémarré l'ordinateur après avoir exécuté le Gflags - r + ustcréation la commande, il n'est pas réellement activé. Si vous souhaitez connaître chaque application qui a suivi de pile activé, vous pouvez afficher la clé USTEnabled sous la clé de Registre suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image fichier Options d'exécution
Si vous exécutez UMDH sur un processus de suivi de pile activé, mais vous n'avez pas redémarré l'application étant donné que vous définissez les indicateurs, vous pouvez recevoir le message suivant dans vos journaux :
Une trace de pile a été non enregistré pour cette allocation (Index == 0)
Si vous exécutez ne définissez pas la correct dans le chemin d'accès des symboles ou les symboles sont incorrectes, et que vous exécutez UMDH, vous pouvez recevoir un message d'erreur dans le journal. Toutefois, vous pouvez recevoir uniquement incorrecte ou piles d'appels à confusion. Pour vérifier que les symboles appropriés, démarrez le Débogueur de système NTSD pour un processus, par exemple :
ntsd bloc-notes
Ensuite, à partir de la console du débogueur, exécutez la %LD commande pour charger les informations de symbole pour le module et le LM commande pour répertorier les modules qui ont leurs symboles chargés. Si le sortie de la LM commande affiche les symboles d'exportation chargés, les symboles ne sont pas bonnes. If vous avez chargé des symboles PDB, les symboles sont bonnes. Vous pouvez recevoir le message d'erreur suivant si vous avez spécifié le PID erroné :
C:\>Umdh - p: UMDH de 1000 : temps de journalisation 2000-06-28 09 : 45 - Machine = MyMachine - PID = 1000 connexion... Échec de OpenProcess, dernière erreur = 0 x

Appelez UMDH à partir de Visual Basic

Il peut être utile parfois faire un dump d'un certain nombre de journaux dans le temps Étant donné que la fuite de mémoire peut ne pas être évidente au premier abord. Par exemple, si vous pensez que votre application Web ASP (Active Server Pages) est une fuite de mémoire, Il peut être utile écrire un composant COM dans Visual Basic qui coques out pour UMDH. Vous pouvez ensuite appeler ce composant à partir de votre page ASP.

Le Voici un code Visual Basic qui appelle UMDH et crée un fichier journal qui est basée sur l'heure actuelle :
Private Declare Function GetCurrentProcessId Lib "kernel32" () As Long
      Public Function GetProcessID()
      GetProcessID = GetCurrentProcessId()
      End Function  
   .
   .
   .
      Dim strTime As String

      Dim sProcID As String
      sProcID = GetProcessID()
      strTime = "MYLOG_" & Format(Now(), "hhmm")
     
      Shell ("C:\UMDH\umdh -p:" & sProcID & " -f:d:\logs\" & strTime & ".txt")
				

Utilisez UMDH avec Windows NT 4.0 Service Pack 6 a (SP6a)

L'utilitaire UMDH qui est fourni avec les outils de débogage pour Produits Windows ne fonctionne pas sur Windows NT 4.0. Un fichier exécutable auto-extractible (Umdhnt4tools.exe) est inclus dans cet article et contient les éléments suivants outils à utiliser avec NT 4.0 :
  • Umdh_nt4.exe et Dbghelp.dll
    C'est l'ordinateur Windows NT 4.0 Version SP6 de l'utilitaire UMDH.
  • Dhcmp.exe
    Cet utilitaire est utilisé pour comparer deux UMDH dumps pour déterminer où un module de mémoire possible une fuite se produit lorsque.
Le fichier suivant n'est disponible pour téléchargement à partir du téléchargement de Microsoft Centre :
Réduire cette imageAgrandir cette image
Télécharger
Télécharger Umdhnt4tools.exe maintenant
Date de publication : 28 août 2002.

Pour plus d'informations sur la façon de télécharger des fichiers de prise en charge de Microsoft, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
119591 Comment faire pour obtenir des fichiers de support technique Microsoft auprès des services en ligne
Microsoft a analysé ce fichier de virus. Microsoft a utilisé les logiciels de détection de virus les plus récents qui était disponible à la date à laquelle le fichier a été validé. Le fichier est stocké sur des serveurs sécurisés qui permettent d'éviter toute modification non autorisée dans le fichier. Placez les Umdh_nt4.exe et Dbghelp.dll dans un dossier, puis placer tout d'abord dans votre variable d'environnement PATH. Utilisez Umdh_nt4.exe au lieu de UMDH.

Sur un ordinateur qui exécute Windows NT 4.0, vous devez utiliser Gflags.exe définir la trace de pile de l'échelle du système. Par exemple :
Gflags - r
Assurez-vous que vous redémarrez votre ordinateur. Suivi de pile Umdh_nt4 ne fonctionne pas sur une base par processus sous Windows NT version 4.0. Elle est définie pour l'ensemble du système.

UMDH_NT4 est à la différence de UMDH dans la mesure où ce n'est pas le cas comparer les fichiers journaux. Par exemple, vous ne pouvez pas faire les éléments suivants :
UMDH_NT4 dh1.log dh2.log > cmp12.txt
Au lieu de cela, vous devez utiliser l'utilitaire de Dhcmp.exe est fourni avec Cet article. La commande est similaire au suivant :
DHCMP dh1.log dh2.log > cmp12.txt

Propriétés

Numéro d'article: 268343 - Dernière mise à jour: mercredi 18 mai 2011 - Version: 1.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Professionnel
  • Microsoft Windows NT Server 4.0 Standard Edition
  • Microsoft Windows NT Workstation 4.0 Édition Développeur
Mots-clés : 
kbdownload kbarttypeshowme kbfile kbgraphxlinkcritical kbhowto kbsample kbmt KB268343 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 268343
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com