2008-11-27 6 views
0

Je compile un projet C++ vc8 dans une session WinXp VmWare. C'est beaucoup plus lent que gcc3.2 dans une session RedHat VmWare, donc je regarde Task Manager. C'est dire qu'un très grand pourcentage de mon processus de compilation est passé dans le noyau. Cela ne me semble pas juste.Découvrir pourquoi un processus passe du temps dans le noyau dans win32

Existe-t-il un équivalent de strace pour Win32? Au moins quelque chose qui me donnera un aperçu des fonctions du noyau qui sont appelées. Il pourrait y avoir quelque chose qui ressort comme étant le coupable.

Répondre

2

Pas exactement, mais il existe un moyen d'obtenir une visibilité dans la pile des appels du noyau, et en l'échantillonnant lors d'une utilisation élevée du processeur, vous pouvez généralement estimer ce qui est utilisé tout le temps.

Installez Process Explorer et assurez-vous de le configurer avec la prise en charge du serveur de symboles. Vous pouvez le faire par:

  1. Installation WinDebug pour obtenir une mise à jour dbghelp.dll
  2. Set Process Explorer pour utiliser cette version de dbghelp.dll en définissant le chemin dans les Options | Configurez le menu Symbols de Process Explorer.
  3. Toujours dans la même boîte de dialogue, définissez le chemin des symboles de manière à inclure le serveur de symboles MS et un cache local.

Voici un exemple de valeur pour le chemin de symbole:

SRV*C:\symbolcache*http://msdl.microsoft.com/download/symbols 

(. Vous pouvez définir la variable d'environnement _NT_SYMBOL_PATH à la même valeur pour les outils de débogage utilisent le même serveur de symbole et le chemin cache) Ce chemin provoquera dbghelp.dll à télécharger des symboles sur le disque local lorsqu'on lui demande des symboles pour un module qui n'a pas de symboles localement. Après avoir configuré Process Explorer comme ceci, vous pouvez alors obtenir les propriétés d'un processus, aller à l'onglet des threads et double-cliquer sur le thread le plus occupé. Cause Process Explorer pour temporairement se connecter au processus et analyser la pile du thread, puis rechercher les symboles pour les différentes adresses de retour sur la pile. Les symboles des adresses de retour et les noms des modules (pour les pilotes tiers non-MS) devraient vous donner une idée claire de l'endroit où votre temps CPU est passé.

3

Le Kit de ressources Windows contient un outil appelé kernrate. C'est un profileur d'échantillonnage. Il peut profiler tout le système ou un processus particulier. Par défaut, sa résolution est au niveau du module, mais peut être réduite à plusieurs octets. Vous devriez être bien avec la résolution par défaut car vous verrez quels modules/pilotes consomment la plupart du temps.

Here est quelques informations concernant son utilisation.

+0

Une version plus récente de kernrate se trouve dans le Kit de pilotes Windows. – bk1e

0

La prise en charge de VmWare doit répondre à cette question. C'est probablement quelque part dans l'implémentation de VmWare.

Vous pouvez utiliser par exemple IrpTracker qui vous donne une idée de ce qui se passe dans le noyau. Une autre option consiste à utiliser le débogueur de noyau i.e WinDbg. Si la charge du processeur est très élevée, elle se déclenche de manière aléatoire dans le débogueur et la recherche de la pile d'appels peut vous donner une idée de qui est le pilote derrière la charge du processeur. Mais comme je l'ai dit, je vais deviner que ce sera un composant VmWare. Cela vaut la peine de vérifier si le problème persiste sur le même ordinateur sous WinXP sans émulation.

+0

Je ne suggère pas d'utiliser WinDbg. Process Explorer vide automatiquement la pile d'applications * en cours d'exécution. Il a simplement besoin de dbghelp.dll de WinDbg; il n'utilise rien d'autre. –

+0

Mis à jour. Inclura-t-il également la pile du noyau? – Ilya

Questions connexes