Wie komme ich zur Grundursache für hohe verzögerte Prozeduraufrufe?

Ich habe einen Dual-Core-Prozessor und einer der beiden ist konstant auf 100%. Ein Blick in den ProcessExplorer zeigt mir, dass es sich um verzögerte Prozeduraufrufe handelt. Das Lesen im Internet scheint mir unzählige unterschiedliche Antworten zu geben.

Ist es möglich, ein paar Schritte festzulegen, um das Problem in meinem Fall einzugrenzen?

Update 1: FWIW, das Problem bleibt auch im abgesicherten Modus bestehen.

Update 2: Ich habe alles, was ich konnte, von der Rückseite des PCs ausgesteckt und dadurch 40% mehr kostenlosen Prozessor erhalten. Ich habe auch das RATTV3-Tool heruntergeladen , aber aus irgendeinem Grund gibt es auf meinem Computer keine Aufschlüsselung nach Treibern . Es gibt eine gute Beschreibung sowohl DPCLatencyChecker und RATTV3 hier .

Update 3: , LatencyMon (siehe meine Antwort unten) sagt mir , es ist nvstor32.sys- und das ist NVidia SATA Treiber - mit Zeiten von etwa 5300 us.

Update 4: Die Handlung verdickt sich, während ich überlege, ob ich versuchen soll, eine Wiederherstellungsdiskette zu booten (um zu sehen, ob es sich wirklich um Treiber und nicht um ein Hardwareproblem handelt) Tür, wenn ich den Knopf drücke). Angesichts der Tatsache, dass die Maschine gerade vom Austausch des Motherboards zurückgekommen ist, stellte ich mir vor, dass sie möglicherweise vergessen hatten, es anzuschließen. Ich öffnete die Box, alles schien in Ordnung, aber ich zog den Stecker heraus und steckte ihn wieder ein. Beim Neustart war alles in Ordnung - kein DPC mehr (höchste jetzt 300µs)!

Update 5: Am nächsten Tag, Problem zurück, CD-Player funktioniert nicht mehr, sogar der Cursor im Passwort-Textfeld blinkt in Zeitlupe ... Es wurde versucht, den Stecker aus der Steckdose zu ziehen, und beim zweiten Neustart funktionierte es wieder (wie bei Update 2) ). Das nächste Mal werde ich versuchen, den CD-Player vollständig abzuziehen ...

Update 6: Gerade bemerkt Das Systemereignisprotokoll nvstor32.sysgibt eine Fehlermeldung und Parity error detected in \Device\RaidPort0anschließend eine Warnung zum Senden einer Neuinitialisierung aus. Jetzt muss ich nur noch herausfinden, um welches es sich RaidPort0handelt ... (Beachten Sie, dass ich kein RAID-Setup habe, es ist nur ein Sumpfstandard von Acer). Oh, und mein Avast-Setup ist anscheinend beim Ausführen eines System-Rollbacks (oder wie auch immer es heißt) abgestürzt, weil es nicht gestartet werden kann (RPC-Fehler), nicht deinstalliert werden kann (Setiface-Fehler ist aufgetreten).

Update 7: Endlich Zeit für einen Neustart mit ausgesteckter DVD. Keine DPC-Probleme mehr! (Viele Seitenfehler, aber das ist für später). Nächster Schritt: Ermitteln Sie, ob es sich um das Kabel oder den DVD-Player handelt.

Update 8: Ein SATA-Kabel ausgeliehen, damit gebootet, keine Probleme. CD / DVD-Player funktioniert, keine DPC-Probleme nvstor32.sys, keine Prozessoren blockiert. Happy End ... fast: Ich habe immer noch Probleme mit Avast, offensichtliche DPC-Probleme storport.sysbeim Start (vielleicht normal für USB?) Und viele harte Seitenfehler. Aber diese werden Gegenstand anderer Fragen sein.

Postscript: Ich hatte kürzlich das gleiche Problem und konnte es mit der gleichen Methode auf einen USB-Stick (den, den ich für ReadyBoost verwendet habe) übertragen.

Hier ist die Geschichte, wie ich die Ursache für meine hohe DPC-Latenz gefunden habe.

Mein System hat während der Audiowiedergabe Klicks und Knackgeräusche festgestellt. Ich wusste, dass dies bedeutete, dass etwas im Kernel-Modus die CPU überlastete. Mein erster Gedanke war, in Process Explorer herumzustöbern und zu sehen, ob irgendetwas fehl am Platz war. Das einzige, was meine Aufmerksamkeit auf sich zog, war die übermäßige Zeit, die für die Ausführung von DPCs ( Deferred Procedure Calls) aufgewendet wurde:

Ich wusste, dass DPCs Code sind, der in einem Treiber ausgeführt wird. Die Herausforderung bestand darin, den Fahrer zu ermitteln. Ich wandte mich an DPC Latency Checker , der mir zeigte, wie schlimm die Latenz war:

DPC Latency Checker schlägt vor, Geräte im Geräte-Manager zu durchsuchen und nicht benötigte Hardware einzeln zu deaktivieren (z. B. Netzwerkkarte, Soundkarte), um den fehlerhaften Treiber zu isolieren. (Wenn Sie ein Gerät deaktivieren und die DPC-Latenz plötzlich abnimmt: Sie haben Ihren Schuldigen gefunden!)

Leider war die Latenz nach dem Deaktivieren von allem, was ich konnte (während ich den Computer noch benutzen konnte - deaktivieren Sie nicht die Festplatte, die Grafikkarte, die Maus oder den USB-Hub, an den die Maus angeschlossen ist!) Immer noch hoch. Als nächstes wandte ich mich dem Windows Performance Toolkit (Teil des Windows SDK ) und einem ausgezeichneten Blog-Beitrag von Peter Weiland "Measuring DPC Time" zu . Nach der Installation des Windows Performance Toolkit:

Ich öffnete eine Eingabeaufforderung mit erhöhten Rechten und lief:

>xperf -on Latency

Hinweis : Die Latency Gruppe ist eine vordefinierte Gruppe von Ereignissen, die vom Kernel-Gruppenanbieter verfolgt werden können:

>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
   ...

In diesem Fall Latencyentspricht das den Kernel Flags:

• PROC_THREAD Prozess und Thread erstellen / löschen
• LOADER Kernel und Benutzermodus Image Lade / Entlade-Ereignisse
• PROFIL CPU Beispielprofil
• CSWITCH Context Switch
• DPC DPC-Ereignisse
• INTERRUPT Ereignisse unterbrechen
• DISK_IO Disk I / O
• HARD_FAULTS Hard Page-Fehler

Nachdem ich das eine Minute lang laufen ließ, stoppte ich den Trace und ließ ihn in einer Datei speichern:

C:\Users\Ian\Desktop\xperf -d thingy1.etl

Und dann habe ich mir die Ergebnisse des Traces mit dem Befehl angesehen:

C:\Users\Ian\Desktop\xperf thingy1.etl

Dadurch wird der grafische Windows Performance Analyzer geladen . Klicken Sie mit der rechten Maustaste auf das DPC-CPU-Nutzungsdiagramm , und wählen Sie Übersichtstabelle aus . Dies zeigt eine Aufschlüsselung der in DPC verbrachten Zeit nach Fahrer:

Auf Anhieb kann ich sehen, dass ein Treiber ( tsvp.sys) durchschnittlich 2,8 ms pro DPC-Ausführung benötigt. Dies ist eine Größenordnung langsamer als jeder andere Treiber:

Googeln tsvp.sysgab mir die Antwort: CommView , das ich kürzlich installiert hatte.

Die Frage ist nun, wie dieser Treiber deaktiviert werden kann. Mit AutoRuns kann ich feststellen, dass es als Treiberdienst installiert ist:

Mit dem Geräte-Manager kann ich den Dienst deaktivieren, der diesen Treiber hostet. Zuerst müssen Sie versteckte Geräte anzeigen und dann den Non-Plug and Play DriversKnoten erweitern:

Schließlich konnte ich den Treiberdienst stoppen und den Startmodus von System(dh der Treiber ist ein wesentlicher Bestandteil von Windows, und Windows kann ohne ihn nicht Demandgestartet werden ) auf (dh ich kann den Treiber starten, wenn ich möchte) ändern :

Durch sofortiges Beenden des Treiberdienstes wurde meine DPC-Latenz behoben:

Ich kann CommView vollständig deinstallieren oder nicht, aber jetzt habe ich den Fall der hohen DPC-Latenz behoben.

Update : Ab Windows 8 werden im Geräte-Manager keine Non-Plug-and-Play-Treiber mehr angezeigt :

Hinweis Ab Windows 8 und Windows Server 2012 erstellt der Plug-and-Play-Manager keine Gerätewiederherstellungen mehr für Nicht-PnP-Geräte (Legacy-Geräte). Daher sind im Geräte-Manager keine derartigen Geräte zur Anzeige verfügbar. Um ausgeblendete Geräte in die Anzeige des Geräte-Managers aufzunehmen, klicken Sie auf Anzeigen und wählen Sie Ausgeblendete Geräte anzeigen.

Microsoft hat die Funktion entfernt und durch nichts ersetzt. Gut gemacht.

In typischer Nerd-Wut einige nicht hilfreiche Antworten :

• Der Geräte-Manager hat niemals Nicht-PNP-Treiber angezeigt
• Warum brauchst du das?

Zum Glück hat NirSoft einen Ersatz geschaffen. Mit ServiWin können Sie alle Dienste anzeigen , stoppen und starten (auch die, die Microsoft-Administratoren sehen sollten):

FORTSCHRITTSBERICHT

Das beste Tool, das ich bisher gefunden habe, ist LatencyMon , das im Grunde alles macht, was die beiden vorhergehenden Tools tun, ohne dass Sie darüber nachdenken müssen. Auf der Downloadseite werden Sie aufgefordert, sich per E-Mail zu registrieren. Dabei ist mir jedoch nichts passiert. Sie können jedoch zum Herunterladen zum Ende der Seite scrollen.

In meinem Fall habe ich LatencyMon (aus Benjols Antwort) verwendet und festgestellt, dass der Fahrer das Leben einfriert, das Universum und (auch) alles, storport.syswas ein Microsoft-Treiber für " Hochleistungsbusse " ist. Das bestätigte meinen Verdacht, dass das Problem mit IO zusammenhängt.

Ich habe mir auch die Windows 7-Ereignisanzeige und den Ordner Windows-Protokolle -> Anwendung angesehen und festgestellt, dass alle 30 Minuten bis 2 Stunden mehrere Fehler durch Volume Shadow Copy (VSS) aufgetreten sind. Die Details waren wie folgt:

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

Dann begann ich zu untersuchen, was zum Teufel VSS ist und wofür es verwendet wird. Ich ging über mehrere - Seiten - über - VSS Fehlerbehebung . Als ich all die durchgesehen habe, hatte ich einen großen Verdacht: meine Backup-Software CrashPlan .

Nach diesem Hinweis fand ich schnell eine Seite mit VSS-Fehlern . Wenn Sie die dortigen Anweisungen zum Deaktivieren der Sicherung geöffneter Dateien befolgen, die VSS verwenden, sind die Einfrierungen, die hohe CPU-Auslastung des Kernels usw. vollständig ausgestorben. Und versteh mich nicht falsch: CrashPlan ist großartig! Nur diese Funktion funktionierte nicht auf meinem Computer.

Übrigens, diese Seite hier war DIE, die mir den ersten Anhaltspunkt gab, der mir half, die Ursache meiner Probleme zu finden. Vielen Dank @Benjol und allen anderen, die zuvor geantwortet haben! Ich hoffe meine Antwort hilft auch anderen ...

Es gibt wahrscheinlich einen Gerätetreiber, der Ihr System beschäftigt. Eine Möglichkeit, dies zu analysieren, besteht darin, die DPC-Latenzprüfung auszuführen . Deaktivieren Sie dann jeweils einen Treiber und prüfen Sie, ob die DPC-Last abnimmt. (Process Explorer funktioniert auch.)

Sie können Gerätetreiber unter Computerverwaltung -> Geräte-Manager deaktivieren.

Ich denke, ich sollte hier meine Antwort hinzufügen, da dieses Problem schwer zu lösen ist und nicht immer auf schlechte Treiber oder IRQ-Konflikte zurückzuführen ist.

Ich hatte eine hohe RPC-Latenz, die bei meiner Pro-Sumer-USB-Soundkarte zu Knistern führte. Die in der akzeptierten Antwort beschriebenen Tools waren bei der Identifizierung eines bestimmten Treibers, der ein Problem verursachte, nicht hilfreich. Die Latenz trat in mehreren Prozessen auf: HAL, USBPORT.SYS und der Windows-Kernel. Ein tieferer Einblick in diese Prozesse ergab keinen offensichtlichen Schuldigen.

In meinem Fall stellte sich heraus, dass es sich um ein niedrigeres Problem handelte, das für GigaByte-Motherboards mit bestimmten Chipsätzen und BIOS-Revisionen spezifisch war. Die Lösung bestand darin, Intel SpeedStep und alle anderen Motherboard-spezifischen Funktionen zu deaktivieren, mit denen die CPU-Geschwindigkeit und -Spannung im Handumdrehen angepasst wurden. Sobald diese Optionen deaktiviert waren, wurde meine RPC-Latenz sofort behoben.

Ich habe diesen Fehler festgestellt, nachdem ein IRQ-Fehler mit meinem nVidia 10/100/1000 Ethernet-Controller behoben wurde, der beim Upgrade meiner Grafikkarte auf die GeForce GTX 550 Ti aufgetreten ist.

Es scheint, als hätte ich nach dem Upgrade auf die neuen GeForce-Treiber 295.73 und der Lösung des Interrupt-Konflikts vorhandene nForce SATA / RAID-Controller-Treiber entfernt, beschädigt oder deinstalliert. Ich verwende kein RAID, der Fehler ist weiterhin aufgetreten und Vista Ultimate 64-Bit ist von Zeit zu Zeit gesperrt.

Nachdem ich alle Vorschläge zur Fehlerbehebung aus dem Internet ausprobiert hatte, stellte sich eine einfache Lösung vor ... Ich habe ein Upgrade auf nForce SATA / RAID-Controller 15.58 durchgeführt, aber andere nForce-Treiber in Ruhe gelassen.

Das hat es für mich behoben und ich habe jetzt alle meine Fahrerkonflikte gelöst. Hoffe es hilft dir auch.