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 de l'arrière du PC, ce qui m'a permis d'acheter 40% de processeur en plus. J'ai également téléchargé l' outil RATTV3 , mais pour une raison quelconque, ma machine ne me fournit pas une panne pilote par pilote. 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- ce qui est le pilote SATA NVidia - avec des temps d'environ 5300 ms.

Mise à jour 4: L’intrigue s’épaissit, je me suis rendu compte que le lecteur de DVD / CD ne fonctionnait pas (c’est-à-dire qu’il ne s’agissait pas de problèmes de matériel). 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, le lecteur de CD ne fonctionne plus, même le curseur dans la zone de texte du mot de passe clignote au ralenti ... J'ai essayé de débrancher tout ce à quoi je pouvais penser et, lors du deuxième redémarrage, de fonctionner à nouveau (comme dans Update2 ) La prochaine fois que je vais essayer de débrancher complètement le lecteur CD ...

Mise à jour 6: Je viens de remarquer que le journal des événements système a nvstor32.sysgénéré une erreur Parity error detected in \Device\RaidPort0, puis un avertissement concernant l'envoi d'une réinitialisation. Maintenant, il suffit de déterminer lequel RaidPort0est ... (remarque, je n’ai aucune configuration RAID, c’est juste un standard Acer standard). 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).

Mise à jour 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. Le lecteur CD / DVD fonctionne, aucun problème de DPC nvstor32.sys, aucun processeur bloqué. Happy end ... ou presque: j'ai toujours des problèmes avec Avast, des problèmes apparents de DPC storport.sysau démarrage (peut-être normal pour l'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 pour ReadyBoost).

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 dans Process Explorer et de voir si quelque chose semblait hors de propos. La seule chose qui a attiré mon attention était le temps excessif passé à exécuter 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 était de savoir quel pilote. Je me suis tourné vers DPC Latency Checker , qui m'a montré à quel point la latence était mauvaise:

DPC Latency Checker suggère de passer par des périphériques dans le Gestionnaire de périphériques et de désactiver un à un les matériels non essentiels (par exemple, une carte réseau ou une carte son) dans l'espoir d'isoler le pilote défectueux. (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 le concentrateur USB auquel la souris est branchée!), Le temps de latence était toujours élevé. Ensuite, je me suis tourné vers le Windows Performance Toolkit (composant du kit de développement logiciel (SDK ) de Windows ) et un excellent article de Peter Weiland sur le blog, intitulé "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

Remarque : le Latency groupe est un ensemble prédéfini d'événements pouvant être suivis à partir du fournisseur de groupe de noyaux :

>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 threads créer / supprimer
• CHARGEUR Noyau et mode utilisateur
• PROFIL Exemple de CPU
• Commutateur de contexte CSWITCH
• DPC DPC Events
• INTERRUPT Interrupt événements
• DISK_IO Disque I / O
• 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

Cela charge le graphique Windows Performance Analyzer . En cliquant avec le bouton droit de la souris sur le graphique d' utilisation du processeur DPC , j'ai sélectionné Tableau de synthèse . Ceci montre une répartition du temps passé dans les DPC par pilote:

Tout de suite, je peux 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.sysm'a donné la réponse: CommView , que j'avais récemment installé.

La question est maintenant de savoir comment désactiver ce pilote. À l'aide d' 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évelopper le Non-Plug and Play Driversnœud:

Enfin, je pouvais arrêter le service de pilote, et j’ai changé son mode de démarrage System(ce qui signifie que le pilote est une partie essentielle de Windows, et Windows ne peut pas démarrer sans lui), et donc Demand(cela 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 les 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, certaines 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é de permettre aux administrateurs de 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 enregistrer 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'au bas de la page pour télécharger.

Dans mon cas, j'ai utilisé LatencyMon (d'après la réponse de Benjol) et découvert que le pilote gelait la vie, l'univers et tout ce qui était (également) storport.sysun pilote Microsoft pour les " bus hautes performances ". Cela a confirmé mes soupçons que le problème était lié à IO.

Je suis également allé de l'avant et j'ai consulté l' observateur d'événements de Windows 7 , le dossier Journaux Windows -> Application , et découvert plusieurs lots d'erreurs provenant du cliché instantané de volume (VSS) se produisant 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é à chercher à quoi sert VSS et à quoi il sert. Je suis allé plusieurs - pages - sur - dépannage VSS . En parcourant tous ceux-ci, j'avais un gros suspect: mon logiciel de sauvegarde CrashPlan .

Suite à cette piste, j'ai rapidement trouvé une page la 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 le vérificateur de latence DPC . Désactivez ensuite un pilote à la fois et voyez si la charge du DPC diminue. (L'explorateur de processus 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.

Après la mise à niveau des nouveaux pilotes 295.73 de GeForce, puis la résolution du conflit d’interruptions, 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.