👨🏾‍🚒 👎🏾 🚞 Untersuchung: Was ist höher als die Thread-Prioritäten in Windows? ✨ 🍝 🐅

Diese Untersuchung begann, wie viele andere, mit der Tatsache, dass ich mein eigenes Geschäft machte und nicht versuchte, nach Problemen für mich selbst zu suchen. Dieses Mal habe ich nur den Deckel des Laptops geöffnet und versucht, mich beim System anzumelden.

Zum ersten Mal, als dies zu einer Verzögerung von zwanzig Sekunden führte, ignorierte ich das Problem in der Hoffnung, dass es sich von selbst lösen würde. Die nächsten Male habe ich über die Untersuchung nachgedacht, aber Leistungsprobleme, die auftreten, noch bevor Sie sich angemeldet haben, sind schwieriger zu lösen, und ich war faul.

Als ich bemerkte, dass ich das Schließen des Laptops vermeiden wollte, weil ich Angst vor diesen zu häufigen Verzögerungen hatte, wurde mir klar, dass es Zeit war, dies ernsthaft zu tun.

Glücklicherweise habe ich kürzlich den UIforETW- Ringpuffer- Trace behobenUm es zuverlässig zu machen, habe ich es gestartet und auf das nächste Verzögerungsereignis gewartet. Ich musste nicht lange warten.

Ich habe mehrere Male gebraucht , um die ETW-Spur für mich vollständig in Ordnung zu bringen . Und da mir dieses Gebiet unbekannt war, dauerte es einige Zeit, um herauszufinden, was geschah. Ich habe das Problem immer noch nicht vollständig verstanden, aber 90% haben die Gründe für sein Auftreten verstanden. Ich habe viel gelernt, einschließlich einiger neuer Details zum Windows-Scheduler, und ich habe auch eine absolut effektive Lösung gefunden.

Die ideale Ablaufverfolgung, die ich beim Laden in Microsoft Windows Performance Analyzer (WPA) aufgezeichnet habe, sieht folgendermaßen aus:

Standardereignisse, Fokusfenster und CPU-Auslastung.

Diese Tabelle und zwei Diagramme enthalten eine Menge Informationen. Die obere Tabelle ( Allgemeine Ereignisse ) zeigt die aufgezeichneten Tastenanschläge für UIforETW. Ich habe versucht, einmal pro Sekunde eine Taste (virtueller Schlüsselcode 162) zu drücken, bis ein Passworteingabefeld angezeigt wird. Da diese 17 Tastenanschläge ausgewählt sind, werden sie in der folgenden Grafik mit vertikalen blauen Linien angezeigt, um die Ausführungszeit kritischer Ereignisse zu vereinfachen. Die x-Achse repräsentiert die Zeit in Sekunden.

Die horizontalen Balken im oberen Diagramm ( Fenster im Fokus ) zeigen, welcher Prozess während dieser Zeit fokussiert ist. Insgesamt gibt es sechs verschiedene Prozesse. Die Rückverfolgungsperiode ist die kurze Zeit, in der der Laptop geschlossen wurde.

Das untere Diagramm zeigt die CPU-Auslastung . Informationen werden aus Kontextwechseldaten erhalten, daher müssen sie vollständig genau und vollständig sein. In dieser Ablaufverfolgung gibt ein Wert von 100% den Moment an, in dem alle acht logischen Prozessoren meines Vier-Kern-Acht-Thread-Notebooks verwendet wurden.

Nachdem ich die Trace-Daten erhalten hatte, musste ich herausfinden, was mein Laptop heimlich tut, wenn die Abdeckung geschlossen ist und bis ich zum System zurückkehre.

Sturm vor der Flaute

Wie wir sehen können, ist der Laptop am Anfang der Spur des Laptops relativ einfach, wie es sein sollte. Dann schloss ich den Deckel. Dies scheint zu einem Anstieg der CPU-Aktivität und einer Änderung des Fokus von Windows geführt zu haben. Das Fenster im Fokus wurde von UIforETW in Idle, dann in csrss, zurück in Idle, in LogonUI und dann zurück in Idle geändert. Wer hätte das gedacht?

Während dieses Intervalls führte der Laptop ungefähr 17 Sekunden CPU-Verarbeitung verschiedener Typen durch. Ein Teil davon ist die Arbeit, die zum Abschalten benötigt wird. Teil - Dies sind Programme (einschließlich interner Google-Tools), die im Taskplaner für die Ausführung von "Wenn ein Benutzer eine Workstation sperrt" registriert sind. Dies ist sinnvoll. Mir ist sogar aufgefallen, dass daran gearbeitet wird, UI-Elemente für die Anmeldung zu erstellen, wenn der Benutzer weiter arbeitet - Sie müssen im Voraus vorbereitet sein, oder?

17 Sekunden CPU - ziemlich lange, bis der Laptop in den Ruhezustand wechselt. Selbst auf meinem Laptop mit vier Kernen und acht Threads dauert der Vorgang mehr als vier Sekunden. Auf meinem Heim-Laptop dauert es mehr als 13 Sekunden CPU-Zeit, um einzuschlafen, und fast alle gehen zu Windows-Code. Muss der Diagnoserichtliniendienst wirklich einige SruDbTableSearches ausführen, bevor der Laptop ruhen kann?

Ich denke, diese übermäßige Arbeit beim Schlafengehen ist auch ein Problem, aber das ist nicht genau das Problem, das ich suche. Also habe ich beschlossen, ihr den Rücken zu kehren.

Und erst viel später wurde mir klar, dass in dieser Zeit die Körner der Zerstörung meines Käfers geworfen wurden ...

Schlaf

Nach dem Blockieren des Laptops erfolgt keine CPU-Aktivität. In diesem speziellen Test wurde der Laptop für ungefähr 16 Sekunden gesperrt.

Krampfhaftes Erwachen

Die Aktivität der CPU beim Übergang in den Ruhezustand ist nicht mit der Aktivität zu vergleichen, als sie zu erwachen begann. Während dieser Zeit benötigte mein überlasteter Laptop 22,6 Sekunden lang ungefähr 172 Sekunden CPU-Zeit (!!!). Das ist viel Arbeit.

Eines der Rätsel dieses Prozesses ist, dass die CPU-Auslastung etwa eine Sekunde nach dem ersten Aktivitätsausbruch auf nahezu Null sinkt. Diese kurze Ausfallzeit erscheint angesichts des Chaos eher ungewöhnlich. Aber ich denke, dass diese Funktion nicht mit dem Problem zusammenhängt, deshalb habe ich nicht darauf geachtet.

Ein weiteres Rätsel ist, warum so vieleProgramme werden nach dieser kurzen Pause zum Leben erweckt. Es ist lustig, dass der schwerwiegendste Eindringling, der für 31,6 von 172 Sekunden der CPU verantwortlich war, Windows Performance Analyzer (WPA) war - genau das Programm, mit dem ich Spuren analysiere. Die drei Kopien, die ich noch laufen ließ, arbeiten hart daran, meine Benutzeroberfläche zu rendern, obwohl sie noch nicht sichtbar ist.

Außerdem treten beim Initialisieren von Laptop-Geräten dunkle Muster auf. KeStallExecutionProcessor ist eine Warteschleife, und es war seltsam zu sehen, dass dies die ausführbarste Funktion des gesamten Systems ist. Ist ein zweiter ungerader Wartezyklus der einzige Weg, um die Ausrüstung zu starten? Ist es wirklich notwendig, 700 ms CPU-Zeit für die Initialisierung von Maus und Tastatur aufzuwenden ? Sollten Microsoft und Intel die Empfehlung von Microsoft ignorieren?maximal 50 Mikrosekunden ?

Treiber eines Wartezyklus. i8042prt.sys wurde von Microsoft geschrieben. Die folgenden beiden wurden von Intel erstellt.

Letztendlich laufen in dieser Zeit viele Programme aktiv . Die meisten von ihnen scheinen mit dem gleichen Problem wie WPA konfrontiert zu sein - sie möchten unbedingt Pixel auf einem versteckten Bildschirm zeichnen, was auf einen Windows-Fehler hinweist. Aber auch ohne diesen Fehler suchen explorer.exe und andere Programme aktiv nach etwas zu tun. Obwohl diese übermäßige CPU-Auslastung ein notwendiger Teil des Problems ist, ist sie letztendlich nicht das eigentliche Problem. Also hörte ich wieder auf, auf sie zu achten.

Fokus

Bei der Analyse von Spuren ist es wichtig herauszufinden, wann wichtige Aktionen ausgeführt werden. Der Hauptbeweis waren Eingabeereignisse, da ich auf das Steuerelement geklickt habe, nachdem das Kennworteingabeformular angezeigt wurde. Hier sind die letzten drei Tastenanschläge der Steuertaste in ungefährer Form im Fenster "Fenster im Fokus " :

Es scheint, dass die kritischen Ereignisse den Fokus von LockApp.exe erhalten, wonach der Fokus fast sofort LogonUI.exe erhält. Vermutlich habe ich das Passwort in LogonUI.exe eingegeben (es ist praktisch, dass der Trace keine Tastaturereignisse abfing), wonach der Fokus kurz auf Explorer und dann auf UIforETW umgeschaltet wurde, von dem aus ich gestartet bin.

Es sieht auch so aus, als ob LogonUI.exe vor LockApp.exe nicht fokussiert werden kann - dieses Muster wiederholt sich in allen von mir untersuchten Spuren.

Nach mehr als tausend Worten zur Lösung dieses Rätsels haben wir endlich eine klare Frage, die wir untersuchen können: Warum wird LockApp.exe nach Beendigung der Ausfallzeit fokussiert, es dauert zwanzig Sekunden?

Wir haben eine Frage? Großartig, lass es uns beantworten

Unter Verwendung von Daten zur CPU-Auslastung (Präzision) , die beim Wechseln von Inhalten erhalten wurden, stellte ich schnell fest, dass LockApp.exe innerhalb von 20 Sekunden nach dem Aufwecken weniger als eine Millisekunde CPU-Zeit erhielt und länger als 14 Sekunden (von 35,158 s bis 49,827 s) nicht funktionierte allgemein:

LockApp funktioniert lange Zeit überhaupt nicht

Die Dokumentation zur Bedeutung der Spalten in den Tabellen zur CPU-Auslastung (Präzise) finden Sie hier .

Wenn ein Prozess oder Thread seit einiger Zeit nicht mehr ausgeführt wird und Sie herausfinden möchten, warum, finden Sie in der Regel wichtige Hinweise beim ersten Kontextwechsel nach einer langen Pause, nämlich beim Umschalten auf 49,827 Sekunden Ablaufverfolgung. Ich habe die Spalten neu angeordnet, um mehr Daten von diesem Kontextwechsel anzuzeigen:

LockApp wird vorbereitet, aber nicht ausgeführt. Seltsam ...

Anzahl gleich 1 bedeutet, dass wir die Daten für einen einzelnen Kontextwechsel betrachten.

Time Since Last (38,2 Millionen Mikrosekunden) bedeutet, dass dieser Thread nicht innerhalb von 38,2 Sekunden ausgeführt wird. Das an sich ist weder gut noch schlecht. Leerlaufströme sparen Energie, und am Ende war der Laptop für einige Zeit in einem Traum.

Die Einschaltzeit sagt uns einfach, wann genau der Thread in die CPU passt - wann der Kontext zu diesem Thread wechselt.

Und jetzt gehen wir zur Spalte Bereit. Er sagt uns, wie lange der Thread zur Ausführung bereit war , aber nicht ausgeführt wurde. Mit anderen Worten, dieser Thread hat auf etwas gewartet (Schloss, Griff) und das ist etwaswurde freigegeben oder initiiert, aber der Thread wurde 19.493 Sekunden lang immer noch nicht ausgeführt .

Um die Spalte Bereit (uns) besser zu verstehen , können Sie sich die Spalte Bereitschaftszeit (en) ansehen . Er sagt uns, wann der Stream vorbereitet ist. Wir sehen, dass dieser Thread für 30,333 Sekunden Ablaufverfolgung für die Ausführung vorbereitet wurde, aber erst 49,827 Sekunden ausgeführt wurde. Dies scheint wichtig zu sein.

Diese Anordnung der Spalten zeigt uns ansonsten den gleichen Kontextwechsel:

Neuer Thread-Stapel und fertiger Thread-Stapel

Dieser Thread (von dem der neue Thread-Stapel NtWaitForWorkViaWorkerFactory erwartete) musste kurz nach dem Öffnen des Notebook-Deckels für 30,333 Sekunden nachverfolgt werden (der Systemprozess, der KeSetEvent aufruft). Aber es begann nicht dann (was "gut" wäre), sondern nach 19.494 s, und das ist schlecht.

Wenn ich eine solche Analyse der Erwartungen durchführe, verbringe ich normalerweise viel Zeit damit, herauszufinden, warum der Stream wartet und warum er nicht bereit ist. Dies war jedoch das erste Mal, dass ich eine Analyse der Erwartungen durchführte, bei der dies nicht wichtig war, und die Frage war, warum dieser vorgefertigte Thread nicht ausgeführt wird.

Fälle ...

Die meisten Menschen verbringen nicht so viel Zeit damit, ETW-Spuren zu studieren, daher ist hier eine Erklärung erforderlich. Das ist sehr seltsam. Wenn der Thread fertig ist, startet er normalerweise sofort oder nach einigen Millisekunden. Die Bereitschaft des Streams bedeutet, wie der Name schon sagt , dass der Stream zur Ausführung bereit ist und fast nichts ihn stören kann. Aber lassen Sie uns herausfinden, was die Ausführung eines fertigen Threads verhindern kann.

Thread-Priorität

Zuerst schlug ich vor, dass dies ein einfacher Fall von CPU-Hunger ist. Dutzende von Prozessen erfordern CPU-Zeit, und aus diesem Grund erhält LockApp erst dann die richtige, wenn die Last abnimmt. Diese Theorie entspricht jedoch nicht ganz den Symptomen, da der LockApp-Prozess auch ohne CPU-Zeit etwa 18 Sekunden dauern kann.

Die CPU-Hungertheorie ist gut, weil sie überprüfbar ist. Es ist mir gelungen, die Priorität des LockApp-Prozesses mithilfe des Task-Managers zu erhöhen (während einer der kurzen Zeiträume, in denen er nicht vom UWP-System angehalten wurde). Daher wurde LockApp in der letzten Ablaufverfolgung, die ich für diesen Beitrag verwendet habe, mit hoher Priorität ausgeführt. Ein normaler Windows-Thread wird mit einer Priorität von ca. 8-10 ausgeführt. Die höchste Priorität, mit der ein regulärer Windows-Thread (nicht in Echtzeit) ausgeführt werden kann, ist 15. Meine ETW-Traces zeigten, dass LockApp immer mit Priorität 13 oder höher arbeitete.

Hier ist eine CPU-Zeitleiste für kritische 19,494 Sekunden, gruppiert und gefärbt nach Priorität des Threads ( New In Pri, die aktuelle Priorität, die dem Thread zugewiesen wurde). Wir sehen, dass Threads mit den Prioritäten 4, 8, 9 und 10 den größten Teil der CPU-Zeit beanspruchen, insbesondere am Ende:

Verwenden der CPU nach Priorität

Hier ist ein weiteres Bild mit ausgeblendeten Threads mit den Prioritäten 0-12. Jedes Mal, wenn das Diagramm unter 12,5% fällt (was einen logischen Prozessor der CPU-Zeit meines Acht-Thread-Notebooks bedeutet), muss LockApp gestartet werden, und es wird absolut unglaublich, dass die Priorität verhindert, dass es so oft ausgeführt wird, wenn viele Threads mit niedrigerer oder gleicher Priorität ausgeführt werden Holen Sie sich eine Menge Zeit.

CPU-Auslastung mit Priorität, nur Threads mit hoher Priorität

Beseitigen Sie die Prioritätsinversion

Es wird spekuliert, dass Windows-Prioritätsinversionsalgorithmen anderen Threads so förderlich sind, dass LockApp.exe blockiert wird. Da die oben gezeigten Grafiken jedoch zeigen, dass bei Planungsentscheidungen echte Prioritäten verwendet werden, muss diese (immer nicht überzeugende) Annahme aufgegeben werden.

Entladen des Stapelkerns

Als ich auf Twitter über dieses Rätsel sprach, schlug einer der Kommentatoren vor, dass der Thread-Core-Stack entladen wurde . Ich war mit dieser Situation nicht vertraut, aber nach John Werths Erklärungen (er versteht auf seinem Gebiet) habe ich das Austauschen des Kernel-Stacks ausgeschaltet und den Computer neu gestartet. Nichts hat sich geändert. Tatsächlich dachte ich nicht, dass dies helfen würde, da ich 32 GB Speicher habe und das Problem wiederholt und häufig auftritt. aber es war besser, sich dessen sicher zu sein.

Prozess anhalten

Da LockApp eine moderne UWP-Anwendung ist, unterliegt sie ähnlichen Einschränkungen wie Smartphone-Apps. Dies bedeutet unter anderem, dass es angehalten werden kann, wenn es nicht im Vordergrund steht, und dann „wieder eingefroren“ werden kann, wenn es wieder in den Vordergrund zurückkehrt. James Forshaw schlug vor , Microsoft-Windows-Kernel-Process ETW aufzuzeichnen , um Daten dazu zu erhalten.

Ereignisse sollen maximale Verwirrung stiften. Der Name der Aufgabe " Prozess einfrieren" wird sowohl für "Auftauen" als auch für "Einfrieren" verwendet. Die Version des Ereignisses " win: Stop" bedeutet, dass der Prozess gestartet wird (er hat das Einfrieren gestoppt), und die Version von " win: Start"bedeutet, dass der Prozess stoppt (beginnt einzufrieren). All dies ist äußerst logisch, aber sehr verwirrend. Wenn die Ereignisnamen in Einfrieren und Auftauen unterteilt wären, würde es weniger Verwirrung geben.

Es gibt keine Dokumentation für diese Ereignisse, aber dank der Analyse habe ich festgestellt, dass diese Ereignisse immer vom Hintergrundaufgaben- / Broker-Infrastrukturdienst erstellt werden . Der Name und die Prozess-ID des entsprechenden Prozesses werden im Feld FrozenProcessID angegeben.

ProcessFreeze-Ereignisse (auch zum Abtauen verwendet) Es

war interessant, diesen Anbieter zu untersuchen - er hat viele vielversprechende Ereignisse -, aber am Ende stellte sich heraus, dass LockApp während der Ablaufverfolgung nicht pausierte oder abtaute. Dieser Anbieter schien jedoch sehr nützlich zu sein, daher habe ich UIforETW so geändert , dass zukünftige Versionen ihn immer aufschrieben.

Wir haben bereits alles ausgeschlossen

Keine der oben beschriebenen Theorien schien mir sehr wahrscheinlich, und jetzt haben wir sie alle ausgeschlossen. Ich begann nach Hilfe zu suchen und bat mich, mir Ideen von einem Microsoft-Freund zu geben. In diesem Moment stellte ich fest, dass die in Windows so bekannte Flusspriorität 0-31 nur fünf Bits mit niedriger Priorität eines Systems mit voller Priorität sind.

Verwendung der offiziellen Position

Es stellte sich heraus, dass meine Unwissenheit meine eigene Schuld war. Wenn ich alle 108 Seiten des Abschnitts " Threads " von Windows Internals, 7. Ausgabe, Teil 1 , sorgfältig lesen würde, würde ich verstehen, was passiert. Wenn Sie weiterspringen möchten, finden Sie dieses Thema auf den Seiten 287 bis 295 .

Dieses Feld mit hoher Priorität, von dem ich nichts wusste, heißt Rang . Es wird in WPA als versteckte Standardspalte (um es zu finden, müssen Sie den Ansichtseditor öffnen) mit dem Namen NewThreadRank angezeigt . Bei der Planung von Threads hat der Thread-Rang Vorrang vor der Priorität. Fast alle Streams haben Rang 0, und ein Stream mit Rang 0 hat immer eine höhere Priorität als ein Stream mit Rang 2. Durch Einfügen einer SpalteNewThreadRank und wenn wir auf die linke Seite der Tabelle schauen, können wir das Problem sofort erkennen:

Der Rang ist wichtiger als die Priorität

. LockApp.exe-Streams haben Rang 2, was bedeutet, dass sie trotz Priorität 14 die niedrigste Priorität im System haben.

Eine fast vollständige Erklärung

Da sich herausstellte, dass LockApp.exe-Threads Rang 2 haben, können sie nur ausgeführt werden, wenn keiner der Threads mit Rang 0 ausgeführt werden soll. Da viele Anwendungen (aus unbekannten Gründen) ihre unsichtbaren Bildschirme aktiv rendern, kämpfen sie um jede Menge CPU-Zeit und lassen nichts für höhere Ränge übrig. Sobald LockApp.exe einen winzigen Bruchteil der CPU-Zeit erhält, wechselt es schnell auf Rang 0 (und die CPU-Last sinkt). Danach wird der Anmeldevorgang auf die übliche Weise ausgeführt.

Nachdem ich diese Informationen erfahren hatte, begann ich zu untersuchen, wie sich der Rang von LockApp im Laufe der Zeit ändert. In den letzten Sekunden wechselte LockApp plötzlich von Rang 0 auf Rang 2, bevor es in den Ruhezustand ging. Der Rang soll verhindern, dass die CPU zu viel Zeit in Anspruch nimmt, z. B. wenn Windows Photos zu sehr auf unerwünschte Hintergrundverarbeitung bedacht ist und den Übergang vornimmt von Rang 2 bis 19:

Microsoft.Photos geht den Rang runter

Aus der Dokumentation geht hervor, dass der Hauptzweck des Stream-Ranges die gerechte Aufteilung der CPU-Zeit zwischen Sitzungen auf dem Computer ist, damit die Prozesse eines Benutzers anderen nicht schaden. Beide Optionen für die Verwendung des Rangs machen deutlich, dass der Rang des Streams nur erhöht werden sollte, wenn viel CPU-Zeit verbraucht wird. Wenn der Laptop in den Ruhezustand versetzt wurde, verwendete LockApp.exe nur 79,3 ms CPU-Zeit und der Rest des Systems - 17 von der CPU-Zeit . Trotzdem hat das Betriebssystem aus irgendeinem Grund beschlossen, LockApp im Ruhezustand auf 2 herunterzustufen.

Das Betriebssystem ändert den Rang des Streams nur, wenn er zur „Planungsgruppe“ ( KSCHEDULING_GROUP) gehört) und die meisten Threads in einer typischen Windows-Installation sind keine Mitglieder. Folglich unterliegen die meisten Threads keiner Rangänderung, sodass sie die CPU-Zeit so verbringen können, wie sie möchten.

Verbleibende Rätsel

Leider ist immer noch unklar, warum LockApp.exe vor dem Einschalten des Ruhezustands auf Rang 2 fällt. Ich gehe davon aus, dass LockApp in der Planungsgruppe ist und sich wahrscheinlich einer der Algorithmen falsch verhält. Aber ich konnte keine API finden, um dies zu untersuchen, und die Zeit lief davon. Wenn Sie Details kennen, schreiben Sie in die Kommentare zum Originalartikel. Das Prinzip, Rang als wichtigste Komponente bei Planungsentscheidungen zu verwenden, sollte meines Erachtens unvermeidlich zusammenbrechen, wenn die meisten Prozesse im System nicht daran beteiligt sind - Threads in Planungsgruppen laufen immer Gefahr, ohne die erforderlichen Ressourcen zu bleiben. Dynamic Resource Allocation Planning ( DFSS ) ist zum Scheitern verurteilt, wenn die meisten Threads nicht beteiligt sind.

Ich weiß auch nicht, warum so viele Anwendungen nach dem Schlafengehen aktiv bleiben. Dies wird normalerweise durch die Tatsache erklärt, dass „viele Timer enden, wenn sich der Laptop mehrere Stunden im Ruhemodus befindet“. Diese Erklärung ist jedoch nicht geeignet, wenn der Laptop nur einige Sekunden im Traum war und das WPA-Rendering-Verhalten anzeigt, dass im Fenstersystem etwas passiert etwas stimmt nicht. Fügen Sie dazu Anwendungen mit schlechtem Verhalten und Wartezyklus-Treiber hinzu, und alles wird im Laufe der Zeit von der CPU gestapelt.

Die Tatsache, dass CPU-Stürme nachlassen und LockApp gleichzeitig gestartet wird, führt zu einer offensichtlichen Erklärung: LockApp kann nur funktionieren, wenn die CPU-Nachfrage sinkt. Es gibt jedoch eine ebenso überzeugende Erklärung: Sobald LockApp die Fähigkeit zum Ausführen erhält (oder möglicherweise von LogonUI), sinkt die CPU-Nachfrage. Beide Erklärungen funktionieren, aber ich denke, die zweite ist plausibler, weil wir sonst nicht erklären können, warum das scheinbar endlose Rendern von WPA plötzlich aufhört.

Lösung

Sobald ich feststellte, dass LockApp.exe eine separate Anwendung ist, die Probleme beim Starten hat und das Erhöhen der Priorität nicht hilft, habe ich sie deaktiviert. Die Datei DisableLockScreen.reg hat mir dabei geholfen:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Personalization]
“NoLockScreen”=dword:00000001

Durch Ausschalten des Sperrbildschirms wird der Laptop sofort nach dem Öffnen der Abdeckung aktiviert. Ich habe weder Bremsen noch Stürme der CPU bemerkt, und jetzt dauert es einen Schritt weniger, um einzutreten.

Der erste Twitter-Beitrag, den ich gepostet habe, als ich zum ersten Mal auf das Problem gestoßen bin, enthält eine Zeitleiste für eine Untersuchung, die für jemanden nützlich sein kann. Außerdem kamen dank ihnen viele kluge Leute von Twitter zu dem Beitrag.

Als ich zu dem Artikel zurückkehrte, stellte ich fest, dass das Problem nach dem erneuten Einschalten des Sperrbildschirms verschwand. Ein einfacher Neustart hat das Problem nicht behoben. Im Februar habe ich viele Male neu gestartet, aber wir wissen wahrscheinlich nicht, warum es verloren gegangen ist.

Untersuchung: Was ist höher als die Thread-Prioritäten in Windows?