Wie komme ich zur Hauptursache für Aufrufe von verzögerten Verfahren?

Hier ist die Geschichte, wie ich die Ursache meiner hohen DPC-Latenz gefunden habe.

Mein System hat während der Tonwiedergabe Klicks und Knicke erlebt. Ich wusste, dass dies bedeutete, dass etwas im Kernelmodus die CPU belastet. Mein erster Gedanke war, im Process Explorer herumzublättern und zu sehen, ob etwas nicht in Ordnung war. Das einzige, was meine Aufmerksamkeit auf sich zog, war eine übermäßig lange Zeit, die für die Durchführung von Aufforderungen zum verzögerten Verfahren (DPCs) aufgewendet wurde:

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

Der DPC Latency Checker empfiehlt, Geräte im Geräte-Manager durchzugehen und nicht unbedingt benötigte Hardware (z. B. Netzwerkkarte, Soundkarte) einzeln zu deaktivieren, um den fehlerhaften Treiber zu isolieren. (Wenn Sie ein Gerät deaktivieren und die DPC-Latenz plötzlich sinkt, haben Sie Ihren Täter gefunden!)

Leider nach alles, was ich zu deaktivieren könnte (während noch in der Lage zu verwenden den Computer - nicht deaktivieren Festplatte, Grafikkarte, Maus oder USB - Hub mit der Maus eingesteckt ist), war die Latenzzeit immer noch hoch. Als nächstes wandte ich mich dem Windows Performance Toolkit (Teil des Windows SDK ) und einem hervorragenden Blogbeitrag von Peter Weiland zu "Measuring DPC Time" an . Nach der Installation des Windows Performance Toolkit:

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

>xperf -on Latency 

Hinweis : Bei der Latency Gruppe handelt es sich um eine vordefinierte Gruppe von Ereignissen, die vom Kernel-Gruppenanbieter verfolgt werden kann:

>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 Load / Unload-Ereignisse
• PROFILE CPU Beispielprofil
• CSWITCH Context Switch
• DPC DPC-Ereignisse
• INTERRUPT Interrupt-Ereignisse
• DISK_IO Disk E / A
• HARD_FAULTS Harte Seitenfehler

Nachdem ich das eine Minute laufen ließ, stoppte ich die Ablaufverfolgung und ließ sie in einer Datei speichern:

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

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

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

Dadurch wird das grafische Windows Performance Analyzer geladen . Wenn Sie mit der rechten Maustaste auf die DPC-CPU-Verwendungskurve klicken, habe ich die Übersichtstabelle ausgewählt . Dies zeigt eine Aufteilung der Zeit in DPCs nach Treiber:

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

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

Die Frage ist nun, wie Sie diesen Treiber deaktivieren können. Mit AutoRuns kann ich sehen, dass es als Treiberdienst installiert ist:

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

Schließlich konnte ich den Treiberdienst beenden und seinen Startmodus geändert haben System(dh der Treiber ist ein wesentlicher Bestandteil von Windows, und Windows kann ohne ihn nicht booten), bis Demand(das heißt, ich kann den Treiber starten, wenn ich möchte):

Durch das Stoppen des Treiberservice wurde meine DPC-Latenz sofort behoben:

Ich kann CommView möglicherweise nicht vollständig deinstallieren, aber jetzt habe ich den Fall der hohen DPC-Latenzzeit gelöst.

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

Hinweis Ab Windows 8 und Windows Server 2012 erstellt der Plug-and-Play-Manager keine Gerätedaten mehr für Nicht-PnP-Geräte (Legacy-Geräte). Daher gibt es keine solchen Geräte, die im Geräte-Manager angezeigt werden können. Um ausgeblendete Geräte in die Geräte-Manager-Anzeige aufzunehmen, klicken Sie auf Anzeigen und wählen Sie Ausgeblendete Geräte anzeigen aus.

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

In der typischen Nerd-Wut einige nicht hilfreiche Antworten :

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

Glücklicherweise hat NirSoft einen Ersatz geschaffen. Mit ServiWin können Sie alle Dienste anzeigen, stoppen und starten (auch die von Microsoft befugten Administratoren sollten sehen dürfen):

FORTSCHRITTSBERICHT

Das beste Werkzeug, das ich bisher gefunden habe, ist LatencyMon, das grundsätzlich alles tut, was die beiden vorhergehenden Tools tun, ohne dass Sie darüber nachdenken müssen. Die Download-Seite fordert Sie auf, sich per E-Mail zu registrieren - aber als ich das getan habe, ist nichts passiert - aber Sie können trotzdem zum Ende der Seite blättern, um den Download zu starten.

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

Ich ging auch weiter und schaute in meine Windows 7-Ereignisanzeige, Ordner Windows Logs -> Application, und stellte fest, dass mehrere Fehler von Volume Shadow Copy (VSS) alle 30 Minuten bis 2 Stunden auftraten. Das sind Details, die so waren:

Volume Shadow Copy Service error: Error calling a routine on the Shadow Copy Provider . Routine returned E_INVALIDARG. Routine details GetSnapshot(,000000000023C850).   Operation: Get Shadow Copy Properties  Context: Execution Context: Coordinator 

Ich begann dann zu untersuchen, was zum Teufel VSS ist und wofür es verwendet wird. Ich ging über mehrere - Seiten - über - VSS Fehlerbehebung . Bei all dem hatte ich einen großen Verdächtigen: meine Sicherungssoftware CrashPlan .

Nach diesem Hinweis fand ich schnell eine Seite mit VSS-Fehlern . Durch Befolgen der dortigen Anweisungen zum Deaktivieren der Sicherung offener Dateien, die VSS verwendet, waren das Einfrieren, die hohe CPU-Auslastung des Kernel usw. vollständig ausgelöscht. Und verstehen Sie mich nicht falsch: CrashPlan ist großartig! Nur diese Funktion funktionierte nicht auf meiner Maschine.

Übrigens, diese Seite hier war DIE EINS, 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 wird auch anderen helfen ...

Wahrscheinlich gibt es einen Gerätetreiber, der Ihr System beschäftigt hält. Eine Möglichkeit, dies zu analysieren, besteht darin, den DPC-Latenzprüfer 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 in Computerverwaltung -> Geräte-Manager deaktivieren.

Ich denke, ich sollte meine Antwort hier 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-Latenzzeit, die zu Knacksern in meiner Pro-USB-Soundkarte führte. Die in der akzeptierten Antwort beschriebenen Tools waren nicht hilfreich, um einen bestimmten Treiber zu identifizieren, der ein Problem verursacht hat. Die Latenzzeit trat für eine Reihe von Prozessen auf: HAL, USBPORT.SYS und den 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-Versionen spezifisch war. Die Lösung bestand darin, Intel SpeedStep und alle anderen Motherboard-spezifischen Funktionen zu deaktivieren, mit denen die CPU-Geschwindigkeit und die Spannung im laufenden Betrieb angepasst wurden. Sobald diese Optionen deaktiviert waren, wurde meine RPC-Latenz sofort behoben.

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

Nach dem Upgrade auf die neuen GeForce-Treiber 295.73 und der Behebung des Interrupt-Konflikts schien es, dass ich vorhandene nForce SATA / RAID-Controller-Treiber entfernt, beschädigt oder deinstalliert hatte. Ich verwende kein RAID, der Fehler blieb weiterhin bestehen und sperrte gelegentlich Vista Ultimate 64-Bit.

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

Das hat es für mich behoben, und ich habe jetzt alle meine Treiberkonflikte gelöst. Ich hoffe es hilft dir auch.