Comment accéder à la cause fondamentale des appels de procédure différée importants?
J'ai un processeur Dual Core, et l'un des deux est constamment à 100%. Regarder dans ProcessExplorer me montre que ce sont des appels de procédure différés. Lire sur le net semble me donner des tonnes de réponses différentes.
Est-il possible de définir quelques étapes pour tenter de cerner le problème dans mon cas?
Mise à jour 1: FWIW, le problème persiste même en mode sans échec.
Mise à jour 2: J'ai débranché tout ce que je pouvais à l'arrière du PC, ce qui m'a permis d'acheter 40% de processeur supplémentaire en plus. J'ai également téléchargé le outil RATTV , mais pour une raison quelconque, ma machine ne me donne pas une panne par conducteur. Il existe une bonne description de DPCLatencyChecker et de RATTV3 ici .
Mise à jour 3: , LatencyMon (voir ma réponse ci-dessous) me dit que c'est nvstor32.sys - qui est le pilote SATA de NVidia - avec des temps de environ 5300 µs.
Mise à jour 4: L'intrigue s'épaissit, tout en réfléchissant à la possibilité d'essayer de démarrer un disque de récupération (pour voir s'il s'agit vraiment de pilotes, et non d'un problème matériel), J'ai remarqué que le lecteur DVD/CD ne fonctionnait pas (c.-à-d. Même pas ouvrir la porte quand j'appuie sur le bouton). Etant donné que la machine venait de rentrer du remplacement de la carte mère, j'ai pensé qu'ils avaient peut-être oublié de la brancher. J'ai ouvert la boîte, tout semblait aller pour le mieux, mais je l'ai débranché et rebranché. Au redémarrage, tout allait bien - pas plus de DPC (plus haut maintenant 300µs)!
Mise à jour 5: Le lendemain, problème de retour, lecteur CD ne fonctionne plus, même le curseur dans la zone de texte du mot de passe clignote au ralenti ... Essayé débrancher tout ce à quoi je pouvais penser, et au deuxième redémarrage, a fonctionné à nouveau (comme dans Update2). La prochaine fois que je vais essayer de débrancher complètement le lecteur CD ...
Mise à jour 6: Vient juste de noter que le journal des événements système contient nvstor32.sys en donnant une erreur disant Parity error detected in \Device\RaidPort0, puis un avertissement concernant l'envoi d'une réinitialisation. Maintenant, il ne reste plus qu’à déterminer lequel est le RaidPort0 qui est ... (remarque, je n’ai aucune configuration RAID, c’est juste un standard standard Acer). Oh, et ma configuration Avast a apparemment été mise à mort lorsque j'ai effectué une restauration du système (ou son nom), car elle ne démarre pas (erreur RPC), ne désinstalle pas (une erreur setiface s'est produite).
Update 7: Vous avez enfin le temps de redémarrer avec un DVD débranché. Pas plus de problèmes de DPC! (beaucoup de défauts de page cependant, mais c'est pour plus tard). Prochaine étape: déterminez s’il s’agit du câble ou du lecteur de DVD.
Mise à jour 8: Emprunté un câble SATA, démarré avec, aucun problème. Lecteur CD/DVD fonctionne, pas de problème DPC avec nvstor32.sys, pas de processeurs bloqués. Heureuse fin… ou presque: j'ai toujours des problèmes avec Avast, des problèmes apparents de DPC avec storport.sys au démarrage (peut-être normal pour une clé USB?) Et de nombreux défauts de page. Mais ceux-ci feront l'objet d'autres questions.
Postscript: J'ai récemment commencé à avoir le même problème et, en utilisant la même méthode, j'ai réussi à le localiser sur une clé USB (celle que j'utilisais depuis ReadyBoost) en cours de tournage.
Voici l’histoire de la façon dont j’ai trouvé la cause de ma latence DPC élevée.
Mon système enregistrait des clics et des bruits pendant la lecture du son. Je savais que cela signifiait que quelque chose en mode noyau monopolisait le processeur. Ma première pensée a été de fouiller Process Explorer , et de voir si quelque chose avait l'air déplacé. La seule chose qui a attiré mon attention est le temps excessif passé à effectuer des appels de procédure différée (DPC):
Je savais que les DPC sont du code exécuté dans un pilote; le défi consistait à déterminer quel pilote . Je me suis tourné vers DPC Latency Checker , qui m'a montré à quel point la latence était mauvaise:
Le vérificateur de latence DPC suggère de passer par les périphériques de Gestionnaire de périphériques, et de désactiver un à un les matériels non essentiels (par exemple, une carte réseau, une carte son), espérant isoler le pilote buggy. (Si vous désactivez un périphérique et que la latence DPC diminue soudainement: vous avez trouvé le coupable!)
Malheureusement, après avoir désactivé tout ce que je pouvais (tout en pouvant ) utiliser l'ordinateur, ne désactivez pas votre disque dur, votre carte vidéo, votre souris ou votre hub USB si la souris est branchée dans!), la latence était encore élevée. Ensuite, je me suis tourné vers le Windows Performance Toolkit (une partie du SDK Windows ), ainsi qu’un excellent article de Peter Weiland, "Measuring DPC Time" . Après avoir installé Windows Performance Toolkit:
J'ai ouvert une invite de commande élevée et j'ai exécuté:
>xperf -on Latency
Note: Le groupe
Latencyest un ensemble prédéfini d'événements pouvant être suivis à partir du groupe de noyaux . fournisseur:>xperf -providers kg Base : PROC_THREAD+LOADER+DISK_IO+HARD_FAULTS+PROFILE+MEMINFO Diag : PROC_THREAD+LOADER+DISK_IO+HARD_FAULTS+DPC+INTERRUPT+CSWITCH+PERF_COUNTER+COMPACT_CSWITCH DiagEasy : PROC_THREAD+LOADER+DISK_IO+HARD_FAULTS+DPC+INTERRUPT+CSWITCH+PERF_COUNTER Latency : PROC_THREAD+LOADER+DISK_IO+HARD_FAULTS+DPC+INTERRUPT+CSWITCH+PROFILE ...Dans ce cas,
Latencycorrespond aux drapeaux du noyau:
- PROC_THREAD Processus et thread créer/supprimer
- LOADER Evénements de chargement/déchargement du noyau et en mode utilisateur
- PROFILE Profil de la CPU
- CSWITCH Changement de contexte
- DPC Événements DPC
- INTERRUPTION événements d'interruption
- DISK_IO Disque E/S
- HARD_FAULTS Défauts de page difficiles
Après l'avoir laissé fonctionner pendant une minute, j'ai arrêté la trace et je l'ai sauvegardée dans un fichier:
C:\Users\Ian\Desktop\xperf -d thingy1.etl
Et puis j'ai visualisé les résultats de la trace avec la commande:
C:\Users\Ian\Desktop\xperf thingy1.etl
Ceci charge le graphique Windows Performance Analyzer. En cliquant avec le bouton droit de la souris sur le graphique tilisation de l'UC DPC, j'ai sélectionné Tableau récapitulatif. Ceci montre une répartition du temps passé dans les DPC par pilote:
Je peux tout de suite voir un pilote (tsvp.sys) prendre en moyenne 2,8 ms par exécution DPC, ce qui est un ordre de grandeur plus lent que tout autre pilote:
Googling tsvp.sys m'a donné la réponse suivante: CommView , que j'avais récemment installée.
La question est maintenant de savoir comment désactiver ce pilote. En utilisant AutoRuns , je peux voir qu'il est installé en tant que service de pilote:
À l'aide du Gestionnaire de périphériques, je peux désactiver le service qui héberge ce pilote. Vous devez d’abord Afficher les périphériques cachés, puis développez le noeud Non-Plug and Play Drivers:
Enfin, je pouvais arrêter le service de pilote, et j'ai changé son mode de démarrage de System (signifiant que le pilote est une partie essentielle de Windows et Windows ne peut pas démarrer sans lui), à Demand (ce qui signifie que je peux démarrer le pilote quand je le souhaite):
L'arrêt du service de conducteur a immédiatement corrigé ma latence DPC:
Je peux ou non désinstaller complètement CommView, mais pour l’instant, j’ai résolu le cas de la latence DPC élevée.
Mise à jour: à partir de Windows 8 vous ne pouvez plus voir Pilotes non Plug-and-Play dans le Gestionnaire de périphériques :
Remarque À partir de Windows 8 et de Windows Server 2012, le gestionnaire Plug-and-Play ne crée plus de représentations de périphérique pour les périphériques non PnP (hérités). Il n'y a donc aucun périphérique de ce type à afficher dans le Gestionnaire de périphériques. Pour inclure des périphériques cachés dans l'affichage du Gestionnaire de périphériques, cliquez sur Afficher et sélectionnez Afficher les périphériques cachés.
Microsoft a supprimé cette fonctionnalité et ne la remplace plus par rien. Bon travail.
Dans la rage typique du nerd, quelques réponses inutiles :
- Le gestionnaire de périphériques n'a jamais montré de pilotes non pnp
- Pourquoi avez-vous besoin de cela?
Heureusement, NirSoft a créé un remplaçant. ServiWin vous permet de voir, d'arrêter et de démarrer tous les services (même ceux que Microsoft a décidé d'autoriser les administrateurs à voir):
RAPPORT D'ÉTAPE
Le meilleur outil que j'ai trouvé jusqu'à présent est LatencyMon , qui fait essentiellement tout ce que font les deux outils précédents, sans vous faire réfléchir. La page de téléchargement vous demande de vous inscrire par courrier électronique - mais rien ne m'est arrivé lorsque j'ai fait cela - mais vous pouvez quand même faire défiler l'écran jusqu'en bas de la page pour télécharger.
Dans mon cas, j'ai utilisé LatencyMon (d'après la réponse de Benjol) et constaté que le pilote gelait la vie, l'univers et tout (également) storport.sys, qui est un pilote Microsoft pour " bus haute performance ". Cela a confirmé mes soupçons que le problème était lié à IO.
Je suis aussi allé de l'avant et ai regardé mon Observateur d'événements de Windows 7 , dossier Journaux Windows -> Application , et j'ai trouvé plusieurs lots de les erreurs de volume Shadow Copy (VSS) se produisent toutes les 30 minutes à 2 heures. Ils sont les détails étaient comme ça:
Volume Shadow Copy Service error: Error calling a routine on the Shadow Copy Provider {b5946137-7b9f-4925-af80-51abd60b20d5}. Routine returned E_INVALIDARG. Routine details GetSnapshot({00000000-0000-0000-0000-000000000000},000000000023C850).
Operation:
Get Shadow Copy Properties
Context:
Execution Context: Coordinator
J'ai ensuite commencé à enquêter ce que le diable est VSS et à quoi il sert. Je suis allé sur plusieurs - pages - environ - dépannage VSS . En parcourant tous ceux-ci, j'avais un gros suspect: mon logiciel de sauvegarde CrashPlan .
À la suite de cette piste, j'ai rapidement trouvé ne page le rapportant avec des erreurs VSS . En suivant les instructions pour désactiver la sauvegarde des fichiers ouverts, qui utilise VSS, les blocages, l’utilisation élevée du processeur du noyau, etc. étaient complètement éteints. Et ne vous méprenez pas: CrashPlan est génial! Cette fonctionnalité ne fonctionnait pas sur ma machine.
BTW, cette page ici était celle qui m'a donné la première piste qui m'a aidé à trouver la cause profonde de mes problèmes. Merci beaucoup @Benjol et tous les autres qui ont répondu auparavant! J'espère que ma réponse aidera également les autres ...
Il y a probablement un pilote de périphérique qui garde votre système occupé. Une façon d’analyser cela consiste à exécuter vérificateur de latence DPC . Désactivez ensuite un pilote à la fois et voyez si la charge du DPC diminue. (Process Explorer fonctionne également.)
Vous pouvez désactiver les pilotes de périphérique dans Gestion de l'ordinateur -> Gestionnaire de périphériques.
Je pense que je devrais ajouter ma réponse ici car ce problème est difficile à résoudre et n’est pas toujours lié à de mauvais pilotes ou à des conflits IRQ.
J'avais une latence RPC élevée qui provoquait des éclats/craquements dans ma carte son USB pro-consommateur. Les outils décrits dans la réponse acceptée ne permettaient pas d'identifier un pilote en particulier à l'origine d'un problème. La latence se produisait sur plusieurs processus: HAL, USBPORT.SYS et le noyau Windows. En approfondissant ces processus, nous n'avons pas révélé de coupable évident.
Dans mon cas, il s’est avéré que le problème était de niveau inférieur et spécifique aux cartes mères GigaByte avec certains jeux de puces et révisions du BIOS. La solution consistait à désactiver Intel SpeedStep et toutes les autres fonctionnalités spécifiques de la carte mère qui ajustaient la vitesse et la tension du processeur à la volée. Une fois ces options désactivées, ma latence RPC a été immédiatement corrigée.
J'ai commencé à voir cette erreur après avoir résolu une erreur IRQ avec mon contrôleur Ethernet nVidia 10/100/1000 apparue lors de la mise à niveau de ma carte graphique vers la GeForce GTX 550 Ti.
Il semble qu'après la mise à niveau des nouveaux pilotes 295.73 de GeForce et la résolution du conflit d'interruption, j'avais supprimé, endommagé ou désinstallé les pilotes de contrôleur nForce SATA/RAID existants. Je n'utilise pas de RAID, l'erreur persiste toujours et verrouille de temps en temps Vista Ultimate 64 bits.
Après avoir essayé toutes les suggestions de dépannage trouvées sur le Web, une solution simple s’est présentée. Je suis passé au contrôleur nForce SATA/RAID 15.58, mais les autres pilotes nForce ont été laissés seuls.
Cela a résolu le problème pour moi et j'ai maintenant résolu tous les conflits de pilotes. J'espère que cela vous aidera aussi.