[English]Ein Administrator hat mich die Tage auf eine sehr unschöne Erkenntnis hingewiesen. Die von Microsoft propagierte Virtualisierungslösung Hyper-V lässt sich in bestimmten Szenarien (auf AMD-Systemen) kaum einsetzen, um mehrere virtuelle Maschinen unter Windows 11 24H2 oder Windows Server 2025 zu betreiben. Hintergrund ist, dass das Betriebssystem keine Leistungsdaten liefert und der Scheduler dann die Ressourcen nicht vernünftig auf die VMs verteilen kann.
Admin-Passwörter schützen mit Windows LAPS. eBook jetzt herunterladen » (Anzeige)
Ein Hinweis auf ein Hyper-V-Problem
Blog-Leser Stephan ist als Administrator in einer mir bekannten Organisation unterwegs. Dort werden Maschinen mit Windows 11 24H2 sowie Windows Server 2025 eingesetzt oder zumindest getestet.
In diesem Zusammenhang ist dem Leser ein größeres Problem mit Hyper-V auf Systemen mit AMD-CPUs aufgefallen – es betrifft zumindest CPUs der Zen-Reihe, wobei die Zen-Version nicht relevant zu sein scheint. Unter Windows 11 24H2 sowie Windows Server 2025 "werde unter Hyper-V die Regulierung deaktiviert" schrieb er, so dass die CPU-Auslastung für einen VM immer auf Null steht.
Das hat zur Folge, dass der Scheduler nicht mehr funktioniert und die VMs gegeneinander arbeiten. Es ist keine Gewichtung zur Ressourcen-Zuteilung für die VMs mehr einstellbar (siehe auch nachfolgende Erläuterungen). Das macht es laut seiner Aussage ziemlich schwer mehrere VMs auf einem Host zu betreiben.
Der Blog-Leser hat das hier im Beitrag skizzierte Verhalten bisher auf Systemen mit Ryzen 5000 und 9000 CPUs (Asus AM4 x570 ACE und ein Asus AM5) beobachten können. Ich selbst habe Hyper-V seit geraumer Zeit nicht mehr auf meinen Windows 10-Clients aktiviert und könnte mangels AMD-Hardware auch nichts testen. Auf meine Nachfrage an Blog-Leser Stephan nach mehr Informationen hat er sich nochmals zurückgemeldet (danke dafür) und das Folgeproblem näher ausgeführt.
Warum das relevant ist
Bei Hyper-V kann man angeben, wie stark eine VM gewichtet ist, um auf diese Weise die Ressourcen zwischen den VMs zu balancieren. Je höher die Gewichtung, je mehr Ressourcen erhält die VM ( eine VM mit 2200 erhält mehr CPU und IO-Zeit als eine VM mit der Wichtung 1100). Der Scheduler kümmert sich dann darum, dass alles bestmöglich läuft.
Obiges Bild zeigt einen Screenshot mit den Hyper-V-Einstellungen (Vordergrund) und die CPU-Auslastung mit dem Wert 0% (Hintergrund). Das sei vorher nicht so gewesen, schrieb der Leser (gemeint ist wohl auf Windows 11 23H2, Windows Server 2022 etc.).
Die Konsequenz aus den fehlenden Leistungsindikator-Werten ist, dass die VMs "laggy" laufen, schreibt der Leser. Der Hintergrund sei, dass die VMs permanent um Ressourcen konkurrieren und der "Dirigent schläft" (der Scheduler zur Ressourcen-Zuteilung funktioniert nicht mehr). Für Stefan fühlt es sich so an, dass die VM, "die zuerst anfängt, so lange Ressourcen bekommt, bis sie fertig ist".
Die Folge ist drastisch, da die eine VM läuft, aber eine weitere VM (oder mehrere) mehr oder weniger "hängt/hängen", da der Scheduler die virtuellen Maschinen nicht ordentlich über die Cores verteilt und nicht mehr regeln kann, "welche VM wie lange CPU-Ressourcen erhält und arbeiten darf". Stefan hat festgestellt, dass sich das gleiche Bild auch für die IO-Last auf den Disks ergibt.
Gleichzeitig stimmt die Anzeige nicht, schreibt der Blog-Leser. Er könnte eine VM, mit allen Cores die auf der HW des Hosts verfügbar sind, mit dem Testprogramm Cinebench voll auslasten. Aber im Manager würde 0% CPU-Auslastung angezeigt. Auch im Windows Task-Manager wird nur der IO-Wert für DISK0 angezeigt, alle weiteren Werte stehen auf 0% (unabhängig von Hyper-V).
In seiner Antwort bestätigt der Leser, dass er das Problem auch unter Windows 11 24H2 vorgefunden hat. Diese Client-Plattform betrifft aber nur Nutzer, die etwas Desktop-Virtualisierung für Hyper-V machen wollen und ggf. mit dem Bug leben können. Aber wie oben ausgeführt, tritt das Problem auch unter Windows Server 2025 auf. So ist natürlich keine Virtualisierung in einer Umgebung mit Windows Server 2025 möglich. Eigentlich wollte der Leser einen neuen Server mit Server 2025 bestellen, aber so wie das aussieht wäre das keine gute Idee.
Eine Problembeschreibung auf reddit.com
An dieser Stelle stellt sich die Frage, ob die obigen Ausführungen Einzelfall sind. Stephan hat mich dann auf den reddit.com-Thread Hyper-V CPU Usage Always 0% on Windows Server 2025 hingewiesen, wo das Problem vom Thread-Starter in allgemeinerer Form für Windows Server 2025 beschrieben wird. Der Betroffene gibt an, dass es sich beim System um eine Neuinstallation von Windows Server 2025 handelt, wo es ein Problem mit Hyper-V gebe. Es sollte also keine "verhunzte Konfiguration" als Ursache sein.
Auf dem System ist die Ressourcenmessung (für Hyper-V) aktiviert und der Betroffene gibt an, alle relevanten Einstellungen überprüft zu haben. Aber ihm wird die CPU-Auslastung für die virtuellen Maschinen sowohl im Hyper-V-Manager als auch im Leistungsmonitor durchgängig mit 0 % angezeigt.
Der Thread-Starter listet auf, was er alles bereits unternommen habe (selbst die Performance Counter hat er mit lodctr /r wiederhergestellt, die VM-Integrationsdienste sind vorhanden etc.). Nichts hilft, er bekommt nach dem Aktivieren der Ressourcenmessung über PowerShell (Enable-VMResourceMetering und Measure-VM) keine Werte für den Leistungsmonitor. Die Überprüfung der Hyper-V-Protokolle auf Fehler oder Warnungen war ergebnislos.
Im betreffenden Thread bestätigen mehrere Teilnehmer, dass sie ebenfalls vor dem Problem stehen, dass unter Hyper-V keine Ressourcenwerte verfügbar sind. Dort gibt es auch die Bestätigung, dass der Fehler neben Windows Server 2025 auch unter Windows 11 24H2 auftritt. Bereits im Dezember 2024 hat sich dann jemand gemeldet, der angibt, dass bei ihm der Fehler auf AMD-CPUs auftrete.
Bisher haben die von Microsoft ausgerollten Updates für Dezember 2024 und Januar 2025 nichts am berichteten Problem geändert. Hyper-V ist bei mehreren virtuellen Maschinen nicht wirklich einsetzbar. Kann jemand aus der Leserschaft dieses Verhalten ebenfalls bestätigen? Sind das Lösungen bekannt, oder gibt es ggf. bereits Tickets beim Microsoft-Support?
MVP: 2013 – 2016
was passiert denn wenn die relative Gewichtung mal bei allen auf 100 gestellt wird? Bei den drei VMs da oben sollte eine relative Gewichtung eigentlich auch nicht eingestellt werden.
Diese Methode ist besonders nützlich, wenn mehrere VMs "identische" Einstellungen im Ressourcenbereich haben und eine Differenzierung erforderlich ist. Es ist auch wichtig zu beachten, dass die relative Gewichtung nur dann zum Tragen kommt, wenn tatsächlich eine Ressourcenknappheit besteht und VMs um CPU-Zeit konkurrieren. In Situationen, in denen genügend Ressourcen verfügbar sind, hat die Gewichtung keinen direkten Einfluss auf die Leistung der einzelnen VMs.
Danke für den Einwurf – aber obiger Screenshot ist jetzt eine Momentaufnahme. Ich denke nicht, dass die Leute, die bisher in diesen Fehler gelaufen sind, bei Tests nicht sehr viel (auch in der Gewichtung) probiert haben. Wenn der Wert 0 für Ressourcen zurück kommt, ist der Scheduler machtlos.
Hi
Die VMs haben immer eine auslatung von 0%, was inkorrekt ist. Wenn man als User an einder der VMs arbeitet und eine ander VM ist "beschäftigt" dann läuft es "hackelig", man wartet, es ruckerlt und das obwohl auf dem Host absolut keine Ressourcenknappheit besteht, weder IO noch CPU.
Die Sever 2019 und 2022 laufen tadellos und bei dem einen Windows 11 PC den wir als Host betreiben ist das neu – unter Win10 war alles gut (auch die CPU Anzeige war funtkional), ggf auch noch initial mit Win11, aber seit Dezember stimmt da was nicht.
Zum Test habe ich mal Server 2025 installiert, da ist das Problem auch bestehend.
Keine Ahnung ob das unter 2025 auch noch möglich ist, aber bis 2022 konnte man Microsoft "kaputten" "NEW-Scheduler" wieder abschalten. Der hat noch nie richtig gut funktioniert. Mit dem CLASSIC und ein paar Anpassungen läuft HyperV um einiges "runder". Ganz besonders unter hoher Last.
https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/manage-hyper-v-scheduler-types
Hab ich schon mal auf Classic umgestellt, es wurde nicht besser. Mit dem "new", also STD Scheduler haben wir aus Server 2019 und 22 keine Prbleme, das läuft soweit "ok".
Nun… wenn man teils 25% Leistung einfach so verschenken will, kann man mit dem Scheduler Einstellungen natürlich gut leben… ich für mein Teil kann mir das aber nicht erlauben in unserem Datacenter so viel Leistung zu verschenken… Ich bau da ja keine AMD -F CPUs ein um die Mehrleistung dann durch ineffizientes Scheduling wieder verpuffen zu lassen….
Wie genau äußert sich das schlechte Verhalten des neuen Schedulers bei euch? Wir verwenden den mit einer Vielzahl von Datev Server Instanzen und können eigentlich nichts Negatives in der Hinsicht feststellen. Er verteilt die Last eigentlich sogar recht gut bei hoher Last, die in einem Datev Umfeld keineswegs selten ist.
Es kann da schon deutlcihe Unterschiede geben, anbei ein thread dazu mit Benchmarks in einer VM:
https://community.spiceworks.com/t/hyperv-2019-vms-2x-slower-than-hv-2012-host-vms/808956/11
Ich werde es auch nochmal testen, hat aber mit dem Problem im Blogartikel nix zu tun.
Ich werde mal ein wenig mit rumtesten. Danke jedenfalls für den Hinweis!
Hier werkelt ein Ryzen 9 PRO 7980. Ich habe permanent 2-3 Maschinen mitlaufen (DC + Workstation oder DC + Member + Wks, das ist meine Workshop Demo Umgebung), selten 4.
Ich habe nicht das Gefühl, das etwas bremst. Vielleicht, weil die Maschinen nicht viel zu tun haben. Ist ja Demo und kein produktives AD mit 1000en Clients.
Ich werde es mal beobachten.
Das ist kein AMD Problem. Unsere Testsysteme haben Intel CPUs und das gleiche Problem.
danke für die Ergänzung
Danke, also kein isoliertes Problme bei mir :-)
Ärgerlich, da werde ich dann doch nochmal Server 2022 bei dem neuen System nehmen müssen, so ist das Mist…
Habt ihr schon alle SR-IOV aktiv und VT-D und VT-X?
Und ASPM L1.2?
(nach BIOS updates musste ich das auch wieder anschalten, weil es rausgeflogen ist)
ASPM macht durchreichen von Energiemanagement in virtualiserten Umgebungen.
Also auf den "richtigen" Servern haben wir das.
Bei den aktuell zur Diskussion stehenden Client-PCs (auf dem ausfallbedinggt mal VMs laufen) weiss ich es nicht, SRIOV sicher nicht.
Ich werde mal ein wenig mit rumtesten. Danke jedenfalls für den Hinweis!
Der Kommentar von mir war unter dem falschen Post. Eigentlich hatte ich den direkt wieder gelöscht. Herr Born, gerne löschen! Ich kann das jetzt nicht mehr.
TOP!
Ich habe 2 Maschinen ebenfalls auf WS 2025 laufen
Dort Funktioniert der NLB Dienst im Unicast Mode nicht mehr
Die VM ist dann nicht mehr erreichbar. (MAC Spoofing ist Aktiviert)
Im Multicast Modus geht es.
Kann das Jemand bestätigen ?
Wie "alt" sind die CPUs denn konkret? Hier gibt es das Problem mit Intel CPUs, die etwas älter sind: https://www.mcseboard.de/topic/228165-cpu-konstant-bei-0-im-hyper-v-manager-server-client/
2021 bis 2024 (Zen5) – alles dabei, ist egal welche CPU es ist. user oben beschreibt das PRoblme auch bei intel
Hmm, irgendwie kann ich das bei mir in meinem Lab System nicht nachvollziehen, da werkelt zugegebenermaßen keine Server CPU, sondern ein Ryzen 7 5700G aber im Host Taskmanager wird dort die CPU Last sehr wohl angezeigt …..
Viele Grüße
Frank
Hier auch alles 0%
Intel Gold Xeon 5218
Server 2025
Eine Frage aber keine Kritik!
Muss das Hostsystem unbedingt Windows sein? Warum benutzt du nicht Proxmox als Hostsystem? Was spricht dagegen?
Es sind schlicht zwei paar Schuhe. Beim Server 2025 könnte neben Hyper-V noch ein Exchange etc. laufen. Auf Windows Clients ist Proxmox überhaupt keine Option. Aber wir geraten auf ein Nebenthema..
Hier auch.
vorgestern installiert Server2025, ging am Anfang kurz, hat Daten angezeigt, jetzt aber alles auf 0%, bei 5 VMs.
Dell R740 mit 2 Intel Gold 6140.
Bei mir auch so auf windows server 2025 ver. 2894:
5 VMs und bei allen permanent 0% CPU-Auslastung.
CPU: AMD EPYC 7443
Bisher aber keine Probleme…
Ich habe ein komplett neu aufgesetztes System.
Windows 11 24H2 / AMD Ryzen 9 9900X
Der SVM-Mode ist im UEFI Bios aktiviert, da ich mit VirtualBox (Oracle) gelegentlich eine Linux VM laufen lassen möchte.
Hyper V sowie Hypervision sind "nicht" in Windows installiert.
Meine aktuellen Probleme: Blue/Black Sreen of Death mit Hypervision als Grund (laut Fehlerbericht / Minidump). Zu keinem Zeitpunkt war die VM aktiv.
Am häufigsten habe ich einen BSOD bei Games gehabt. Aktuell gesichert reproduzierbar bei CoD Vanguard nach ca. 10-15 Minuten Spielzeit.
Aber auch ohne Games – nur dem Brave-Browser auf YT unterwegs – hatte ich schon einen BSOD.
Die VM in VirtualBox läuft unter Windows 11 mit sehr starken Performance-Problemen. Unter Windows 10 lief die gleiche VM absolut flüssig.
Ich hoffe hier auf eine schnelle Fehlerbehebung von Microsoft.
Ich den 5 Jahren Laufzeit von Windows 10 hatte ich keinen einzigen BSOD.
Seit Windows 11 innerhalb von 4 Wochen mehr als 15.
Es scheint noch mehr Probleme zu geben. Ich kann meine Netscaler Testinstanz (v14.x) nicht mehr auf meinen Hyper-V Servern zum laufen bekommen.
Betroffen sind sowohl Zen 4 Maschinen als auch ein Server mit Intel Xeon e5-2680v2.
Netscaler selbst antwortet noch auf Pings, aber selbst die Netscaler GUI auf Port 80 lässt sich nicht mehr öffnen. Veröffentliche Webseiten auch nicht. Kein einziger Port ist offen. Auf ICMP / Pings antwortet die VM allerdings.
Selbst bei einer blanken VM ohne config besteht der gleiche Fehler. Scheint also nicht an meiner Config zu liegen…
Kann ich bestätigen. Bei 23h2 alles prima.
Hast du bereits eine Lösung?
Gibt es schon eine Lösung dafür?
Bei mir werkelt ein Ryzen 5 7600 mit WS2025 (aktuellste updates).
Noch merke ich nicht viel davon, dass VMs gegeneinander arbeiten, doch die TrueNAS-VM fühlt sich gelegentlich schon sehr laggy an und jede VM hat auch die 0% CPU-Auslastung
Sonst läuft da noch ein Domänencontroller, ein Terminalserver und ein VPN Server für aktuell 2-3 Clients, da ist also generell noch nicht viel Last drauf.
Hoffe das wird bald irgendwie gefixt bevor mehr Clients kommen :D
Ich habe mehrere Kunden auf 2025 laufen (Host und Guests, wobei letztere auch mit älteren Versionen), mit Epyc und Xeon, und ich habe das Problem nicht.
Hyper-V hatte und hat hier und bei Unmengen von Kunden seit wohl 20 Jahren keine Probleme – ich betreibe darunter Windows, Ubuntu, Debian,… -Gäste, und alles läuft wie immer anstandslos. Den einzigen Effekt, den ich wohl seit einigen Wochen, aber nur auf den meisten (nicht allen) Systemen beobachte, ist die fehlende CPU-Auslastung im Hyper-V-Manager, ober ohne funktionale Auswirkungen. Wer das gleiche Problem hat, sollte dort mal "I have the same question" anklicken. Erstaunlich, dass ich da vorhin der erste war:
https://learn.microsoft.com/en-us/answers/questions/2151400/is-there-a-fix-for-windows-2025-server-to-show-cpu. Gibt vermutlich noch weitere
Der Scheduler ist unabhängig von Hyper-V und AMD defekt, denn der Fehler tritt auch mit einem alten Intel i5-750 (4-Core, ohne SMT) und ohne Hyper-V auf, also auf dem ganz normalen Windows-Desktop ohne laufende VM.
Windows 10 LTSC IoT Enterprise 2021 (aktuellstes Build 19044.5859 vom 27.5.2025)
Installiert ist "Rainmeter 4.5.23" mit dem "CPU Usage"-Gadget aus dem Paket "Gadgets Rainmeter Theme", um den Ressourcenverbrauch direkt auf dem Desktop anzeigen zu können.
( visualskins. com/skin/gadgets )
Da sieht man, dass der zweite CPU-Core (Nummer 1 aus der Reihe 0,1,2,3) nicht benutzt wird (Ausschlag nur bis maximal 1 Prozent, während die anderen Cores 2-stellige Auslastung haben).
Alternativ zum Rainmeter-Gadget kann man auch den Windows-Task-Manager benutzen. Unter Reiter "Leistung", "Ressourcen-Monitor"-Button, Reiter "CPU" sieht man am rechten Rand des Fensters ebenfalls den Effekt, dass ein CPU-Core gar nicht benutzt wird.
Lösung:
msconfig starten ("Systemkonfiguration"), Reiter "Start", "Erweiterte Optionen"-Button,
[x] "Prozessoranzahl" (anhaken, war vorher nicht angehakt).
In der Listbox direkt darunter die maximal Anzahl der CPU-Cores einstellen.
OK, OK, Neustart
Jetzt werden wieder alle CPU-Cores benutzt.
Der Scheduler ist defekt, da nicht alle CPU-Cores benutzt weren, wenn im msconfig das Kästchen bei "Prozessoranzahl" nicht angehakt ist.
Normalerweise sollten dann nämlich automatisch alle verfügbaren CPU-Cores benutzt werden und auf Windows 7 ist das auch der Fall, bei Windows 10 und 11 aber nicht unbedingt.
Installiert ist zusätzlich noch VirtualBox 7.1.10, aber ich nehme bisher an, dass dies nicht die Ursache ist und VirtualBox war auch nicht gestartet, während der Effekt des nicht benutzten CPU-Cores auftrat.
Frage:
Wie kann man denn außerhalb von Hyper-V, also auf dem Host, den Scheduler wechseln (Classic, Standard, Core, Root, New)?
Das geht vermutlich gar nicht.
Also bei mir [W11 24H2, Ryzen 5 (6/12)] laufen alle Kerne ähnlich, auch ohne 'msconfig' Änderung.
Schau ma hier (Änderung nur bei Windows Servern supported!):
[ https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/manage-hyper-v-scheduler-types ]
Hyper-V ist gar nicht installiert.
Die Abfrage mittels Powershell laut Microsoft-Seite scheitert mangels Hyper-V-Eventlog-Einträgen.
Steigerung meines Problems:
Nachdem das Problem mittels msconfig für ca 5 Stunden scheinbar gelöst war trat es plötzlich wieder auf.
Der selbe Core lief wieder nicht, trotz maximaler Einstellung in msconfig und ich habe zwischen den Zuständen "geht" und "geht nicht" auch gar nichts am System verändert.
Als Auslastungs-Testprogramm benutze ich x264.exe, welches mir viele Jahre lang alle Cores bestens ausgelastet hat.
Einen Hardwaredefekt in der CPU schließe ich aus, denn in der Ereignisanzeige habe ich noch keinen passenden Eintrag gefunden (Hardware-Ereignisse ist leer), ein Gegentest mit Windows 7 zeigte keine Probleme, alle Kerne konnten voll ausgelastet werden und die Rechenergebnisse sind einwandfrei.
Nach einem Neustart in Windows 10 funktioniert es aktuell auch wieder normal. Mal sehen für wie viele Stunden…
Na dann wird wohl eher der Neustart helfen :)
Meiner läuft übrigens seit letzter Woche durch, daran kann es also eher nicht liegen.
Defekte CPU würde wahrscheinlich eher zum Absturz führen und da das Problem nur bei einem Kern Auftritt, der aber wohl trotzdem rechnet, spinnt der vielleicht doch etwas, taktet wegen eines punktuellen Hitzestaus selbstständig runter und/oder vergisst (dann) das Hochtakten. Bei Letzterem könnte ein Bios Update vielleicht helfen oder möglicherweise wurde es durch ein Vorheriges sogar verursacht und außerdem könnte das eventuell erklären, warum ein Neustart hilft bzw. ein Boot in Windows 7!?
Der selbe Effekt mit einem nicht benutzten CPU Core ist gestern und heute erneut zwei mal aufgetreten, also insgesamt 4 mal bewusst beobachtet.
#1. nach einer unbekannten Zeit, nur durch Zufall entdeckt.
#2. nach 5 Stunden nach Neustart
#3. nach ca 12 Stunden nach Neustart
#4. nach ca 12-22 Stunden nach Neustart
Im Ressourcenmonitor ist keiner der Cores als "geparkt" gekennzeichnet.
"ParkControl" zeigt an, dass die Park-Funktion nicht aktiv ist (ok), es werden alle 4 Cores angezeigt, aber nur 3 davon grün und 1 grau.
Ich habe schon einige Stunden verballert, um dieses Park-Problem zu checken. Registry-Tricks und Tools ausprobiert.
Ich glaube am Core-Parking liegt es nicht.
Eine Überhitzung liegt auch nicht vor laut HW-Monitor und laut QuickCPU.
Average 45 Grad Celsius,
Maximum: 61 Grad Celsius.
Also gar kein Problem, kein Throtteling.
Außerdem habe ich einen sehr großen CPU-Kühler, der jede Wärme frühzeitig wegschafft und von der alten CPU niemals ausgelastet werden kann.
QuickCPU zeigt bei "Utilization" nur 0,4 Prozent für den einen Core an, während die anderen Cores bei 100 Prozent stehen.
Clock-Speed und Multiplier sind bei allen Cores identisch.
QuickCPU meldet dort auch kein Throtteling, sondern normale Temperatur und normale Taktung, wie bei den anderen Cores auch.
Wenn man in diesem Zustand x264.exe über ein Video laufen lässt, dann werden nur 3 Cores benutzt. Normalerweise müssten alle Cores voll ausgelastet sein.
"Prozess Lasso" ist auf diesem System nie installiert gewesen und nicht gestartet.
Ich halte das weiterhin für einen Bug im Windows Kernel Thread-Scheduler.
Ist mir erst seit ein paar Tagen aufgefallen.
Die CPU ist nicht defekt, denn unter Windows 7 tritt der Effekt nie auf und alle bisherigen Tests zeigten keine Fehler.
Im msconfig sind 4 Cores (maximum) eingetragen und angehakt.
Wie könnte man den einen Core wieder reaktivieren ohne den Computer neuzustarten oder wie kann man den Thread-Scheduler fixen?
Der Thread-Scheduler teilt dem einen Core einfach keine Aufgaben mehr zu.
Das ist für mich ein Rätsel.
Sollte das ein Bug sein und nicht gefixt werden können, dann ist Windows mit so einem defekten Scheduler so nicht benutzbar, da ich die Rechenleistung brauche.
QuickCPU Free ist übrigens ein tolles Tool mit sauvielen Infos zur CPU wie ich es noch bei keinem anderen Tool gesehen habe.
coderbag. com/product/quickcpu
Verschwörungstheorie als Alternative zum Bug:
Das könnte eventuell auch ein versteckter Kopierschutz sein.
Microsoft hat entdeckt, dass die Lizenz nicht korrekt ist, weil IoT LTSC so nicht benutzt werden darf und hat dann einen Core sabotiert als Rache.
Halte ich für technisch leicht möglich, aber einen Bug halte ich für wahrscheinlicher.
Beobachtungen:
Energieeinstellung auf "Höchstleistung" bringt keine Änderung.
Prime95 benutzt alle Cores.
Der angeblich "schlafende" Core ist also da und einsatzfähig.
Beendet man Prime95, dann ist der eine Core wieder "schlafend" und wird von x264.exe etc wieder nicht eingesetzt.
"Process Explorer" zeigt bei "Affinität" für x264.exe, dass alle 4 Cores eingesetzt werden sollen, aber das geschieht nicht.
Auch die neueste Version von x264.exe bringt keine Änderung.
Park Control kenne ich nicht, aber nach einer kurzen Recherche scheint das nicht normal zu sein und eher einen deaktivierten Kern anzuzeigen – man müsste halt wissen, was das genau versucht auszulesen. Abgesehen davon scheint 'parken' wohl nach Win7 eingeführt worden zu sein.
Achtung, mit Hitzestau meinte ich nicht die komplette CPU, sondern sowas wie eine kleine Luftblase in der Wärmeleitpaste, die man ggf. nach einiger Zeit erneuern muss, damit eben keine 'Wärmenester" entstehen können!
Die Aussagen, dass die CPU bei 0,4% laufen würde und, dass sie keine Aufgaben zugeteilt bekommen würde sind miteinander inkompatibel. Außerdem weißt du nicht, ob Rückmeldungen zum Zustand von Win7 und 10 nicht unterschiedlich interpretiert werden und die 0,4 entsprechend als 100% Vollauslastung ausgelegt werden und vielleicht enthält die CPU auch einen Fehler, mit unter Windows 7 umgangen wird und bei Win 10 vergessen wurde (Die CPU scheint auch offiziell, zumindest in neueren Versionen, nicht unterstützt zu sein!).
PS Ohne Neustart den CPU Kern zu aktivieren wird eher nicht gehen, weil die Verwaltung/Rückmeldung wahrscheinlich vom BIOS/EFI kommt, weiß ich aber nicht!
Prime95 aktiviert den Core aber wieder.
Allerdings nur solange wie Prime95 rechnet.
Ist kein UEFI, sondern reines altes BIOS, wo Windows keine Zugriff drauf hat.
1.
Zitat:
"Park Control kenne ich nicht, aber nach einer kurzen Recherche scheint das nicht normal zu sein und eher einen deaktivierten Kern anzuzeigen"
—
ParlControl ist vom selben Hersteller wie "Process Lasso".
Grau ist der Hintergrund für jeden Core und darauf wird mit grün die Auslastung gemalt.
Grau bedeutet also nicht deaktiviert, sondern keine Auslastung.
Wäre der eine Core deaktiviert, dann gäbe es dort nur 3 Kästchen statt 4.
2.
Zitat:
"mit Hitzestau meinte ich nicht die komplette CPU, sondern sowas wie eine kleine Luftblase in der Wärmeleitpaste, die man ggf. nach einiger Zeit erneuern muss, damit eben keine 'Wärmenester" entstehen können!!"
—
Das könnte eventuell sein.
Die Wärmeleitpaste ist vermutlich 15 Jahre alt.
In Windows 7 tritt der Effekt aber nciht auf und auch in WIn10 gibt es auch mit höchster Auslastung durch Prime95 kein Throtteling.
Also eher kein Hitzeproblem.
3.
Zitat:
"Die Aussagen, dass die CPU bei 0,4% laufen würde und, dass sie keine Aufgaben zugeteilt bekommen würde sind miteinander inkompatibel."
—
Nicht "CPU", sondern "Core".
Nur der eine Core hat 0,4 Prozent Auslastung, die anderen Cores 100 Prozent.
Das passt zu der Aussage, dass der eine Core keine Aufgaben zugeteilt bekommt.
4.
Zitat:
"Außerdem weißt du nicht, ob Rückmeldungen zum Zustand von Win7 und 10 nicht unterschiedlich interpretiert werden und die 0,4 entsprechend als 100% Vollauslastung ausgelegt werden"
—
Man sieht es aber an der Geschwindigkeitsanzeige fps pro Sekunde im x264-cli Fenster.
Die Geschwindigkeit passt recht genau zu 3 Cores.
Im Windows 7 oder direkt nach einem Neustart in Win10 habe ich 4/3 der Leistung im Vergleich zu dem seltsamen Zustand bzw während des seltsamen Zustandes habe ich nur 3/4 der normalen Leistung.
5.
Zitat:
"Die CPU scheint auch offiziell, zumindest in neueren Versionen, nicht unterstützt zu sein!"
—
Das wusste ich nicht.
Ich sehe aber auch keinen Grund, warum diese CPU mit Windows 10 inkompatibel sein sollte.
Direkt nach dem Neustart funktioniert es ganz normal für mehrere Stunden.
Vielleicht hat eines der letzten Windows Updates den Scheduler verbuggt.
Ja mein Gehirn hat mehrmals CPU aus Kern gemacht, sollte aber nachvollziehbar sein, aus dem, was ich geschrieben habe!
Ich dachte, die grünen Blätter sind geparkte Kerne, aber damit werden wohl Effizienz-Kerne markiert und wenn der Kern garkeine Aufgaben hat müsste der logischweise eigentlich bei 0% bleiben und nicht bis auf 0,4% hochgehen. Deshalb wundert mich jetzt am meisten, dass sich jede Software, die du benutzt irgendwie anders zu verhalten scheint.
Wenn die Geschwindigkeit recht genau zu 3 Kernen passt, könnte der 4. immernoch mit seinen 0,4% mitmachen. Du musst bedenken, dass die Rechnung folgendermaßen aussieht:
100% + 100% + 100% + (0,4% v. 100%)
3 Kerne wären dann
3 x 100 / 3 = 100
4 Kerne inklusive dem 'Defekten' wären
3 x 100 / 3 + 0,4 = 100,4
Ist natürlich die Frage, ob man den Unterschied zwischen 100% und 100,4% überhaupt sehen kann.
Gibt jetzt also mehrere Möglichkeiten:
– Win7 reagiert nicht auf irgendeine Rückmeldung der CPU wg. Inkompatibilität
– Win10 reagiert nicht auf irgendeine Rückmeldung der CPU wg. Bug
– Win7 reagiert auf irgendeine Rückmeldung der CPU und verhält sich 'normal'
– Win10 reagiert nicht auf irgendeine Rückmeldung der CPU, weil vielleicht ein Workaround oder eine veraltete Funktion gestrichen wurde und es deshalb keinen Support mehr gibt. Vielleicht mal eine ältere W10 Ausgabe testen!?
Das mit der Temperatur würde ich auch nicht unbedingt ganz ausschließen. Mir ist noch eingefallen, dass man bei Intel CPUs und unterstützer Hardware früher mit 'coretemp' – bei AMD analog mit 'amdtemp' – die Temperatur direkt vom Wärmesensor auf der CPU ausgelesen werden konnte, was aber seit einigen Jahren direkt per 'ACPI' aus dem BIOS/EFI ausgelesen wird/werden kann (so oder so ähnlich) und entsprechend auch nicht anders funktionert. Bei meinem 15 Jahre alten Atom D252 geht das noch, bei späteren CPUs nicht mehr. Seit wann genau, weiß ich aber nicht, könnte aber zeitlich hinkommen, ist aber möglicherweise nur eine Unix/FreeBSD spezifische Angewohnheit oder ein in dem Umfeld nicht mehr gepfleger Treiber!
Es könnte noch einen anderen Grund für so einen Effekt geben:
"BD PROCHOT".
Das ist ein von einem externen Sensor gesteuertes Throtteling.
PROCHOT bedeutet "Processor Hot" und bezeichnet das CPU-interne Throtteling als Überhitzungsschutz.
Zusätzlich kann die CPU aber auch noch gethrottelt werden, obwohl sie selber gar nicht zu heiß ist.
Nämlich dann, wenn ein Sensor außerhalb der CPU, also irgendwo auf dem Mainboard, etwa ein Temperatursensor auf den Spannungswandlern, am CPU-Register 0x1FC ein Ereignis signalisiert.
Dann reagiert die CPU so als ob sie selber überhitzt wäre und regelt sich herunter, um so die externen Bauteile zu entlasten.
Solche Sensoren befinden sich an den Spannungswandlern, im Netzteil, im Lüfter, in der GPU.
Welche Sensoren wo verbaut sind und welcher Sensor wie an dieses CPU-Register angeschlossen ist wird leider nirgendwo von den Mainboardherstellern dokumentiert und nicht verraten.
"BD PROCHOT" bedeutet "Bi-Directional Processor Hot".
Bi-Directional, weil man das Register als Input oder als Output benutzen kann, je nachdem wie es verdrahtet ist.
Konfiguration als "Input" ist Standard, also kann ein Sensor auf dem Mainboard der CPU befehlen herunterzuregeln.
Das ist besonders auf älteren Mainboards ein Problem, wenn diese Sensoren ungenau oder defekt werden bzw sind.
Dann regelt die CPU sich selber herunter, obwohl objektiv gar kein Grund dafür vorliegt.
Anzeigen kann man "PROCHOT" und "BD PROCHOT" mit Tools wie ThrottleStop.
Die PROCHOT-Schwelle ist bei mir mit 99 Grad Celsius in der Mainboard-Firmware eingetragen. Diesen Werte erreiche ich aber nie, also gibt es bei mir auch kein PROCHOT-Throtteling.
Ob bei mir einer der externen Sensoren defekt ist und deshalb "BD PROCHOT" ausgelöst wird, weiß ich aktuell noch nicht und mangels Dokumentation über solche Sensoren wird das auch sehr schwierig herauszufinden sein.
"BD PROCHOT" kann man mit ThrottleStop auch deaktivieren, indem man das Register löscht, allerdings hat Intel ab der 12.CPU-Generation das Deaktivieren gesperrt (betrifft mich aber nicht).
Mittels "BD PROCHOT" kann man auch "geplante Obszoleszens" implementieren, denn wenn ein alter Sensor die CPU auf Multiplier 1 und 800 MHz runterzieht, dann ist das Laptop unbenutzbar langsam und muss ausgetauscht werden.
Der Programmierer von ThrottleStop hat einige erhellende Kommentare in diversen Foren zu "BD PROCHOT" abgegeben. Er empfiehlt das Abschalten dieser Funktion, wenn möglich.
Das Problem tritt nicht mehr auf, wenn man im BIOS die "Intel C-State Tech" abschaltet.
Stufe "C6" hatte ich vorher bereits abgeschaltet, daran liegt es also nicht.
"C1E" (Enhanced Halt State) ist weiterhin aktiviert, daran liegt es also nicht.
Das Problem liegt also höchstwahrscheinlich am "C3" (Deep Sleep) Stromsparmodus.
Da das Problem in Windows 7 und Linux nicht auftritt handelt es sich vermutlich um einen Fehler im Windows 10 Energiesparprofil. Schlafenlegen eines CPU-Kerns funktioniert, aufwecken aber nicht zuverlässig.
Da der Effekt mittels deaktiviertem "C-State" behoben ist, liegt es also auch nicht an "BD PROCHOT". Kein externer Sensor defekt, der der CPU das Throtteling befiehlt.
Demnächst teste ich dann, C-States im BIOS aktiv zu lassen und nur Windows 10 per powercfg auf "C2" oder "C1" zu begrenzen:
powercfg /SETACVALUEINDEX scheme_current SUB_PROCESSOR IDLESTATEMAX 2
powercfg /setactive scheme_current
Die Beschränkung des Stromsparmodus auf maximal C2 mittels powercfg-Befehl hat bei mir funktioniert. Das Problem mit dem nicht mehr benutzbaren CPU-Kern trat seitdem nicht mehr auf.
powercfg /SETACVALUEINDEX scheme_current SUB_PROCESSOR IDLESTATEMAX 2
powercfg /setactive scheme_current
Im BIOS habe ich weiterhin C3 aktiviert und nur Windows 10 mit powercfg auf C2 beschränkt.
Windows 7 und Linux laufen also weiterhin mit C3 problemlos.
Weiteres Testergebnis:
Falls man im BIOS und im Windows 10 die C-States auf C3 eingestellt hatte und der CPU-Kern dann unbenutzbar wird, so kann man diesen Zustand mit dem powercfg Befehl im laufenden Betrieb ohne Neustart nicht mehr korrigieren.
Schlussfolgerungen:
– Die in Windows 10 eingebauten Stromsparpläne sind nicht kompatibel mit dieser CPU und man muss entweder per BIOS oder mit powercfg den "Deep Sleep" modus C3 und höher abschalten und die C-States auf maximal C2 beschränken.
Vorher vermutetete mögliche Ursachen konnten ausgeschlossen werden:
– keine Überhitzung der CPU-Kerne (Schwelle 99 Grad Celsius, "PROCHOT" #1). Keine lokale Hotspots aufgrund zu alter Wärmeleitpaste.
– keine Überhitzung des CPU-Gehäuses (Schwelle 72,7 Grad Celsius, "PROCHOT" #2)
– kein defekter externer Sensor (etwa auf dem Mainboard-Spannungsregler), der der CPU das Runterregeln signalisiert ("BD PROCHOT")
Nachteil von abgeschalteten C3:
Die CPU schafft dann nur noch All-Core-Turbo (Multi 21) und nicht mehr die beiden höheren Turbo-Stufen (Multi 24), die mit nur 1 oder maximal 2 Kernen möglich wären, denn die anderen Kerne müssten während dieser hohen Turbo-Phase im Deep Sleep Modus C3 sein.
Da bei Videobearbeitung und Kompression aber alle Kerne eingesetzt werden spürt man keinen Unterschied.
Das Problem liegt in der Datei intelppm.sys
Das ist der "Intel Power Management Driver".
Der stammt aber gar nicht von Intel selbst, sondern von Microsoft, wie Intel im FAQ in der Antwort zur Frage 8 (Q8) schreibt:
www. intel. com/content/www/us/en/support/articles/000100206/processors/processor-utilities-and-programs.html
Probleme mit falschem CPU-Takt aufgrund dieses Treibers gibt es schon seit dem Jahr 2012 seit Windows 8.
Scrollt man runter in dem Strang, bis "February 2, 2013 6:50 PM", dann steht dort eine Lösung zum Deaktivieren dieses Treibers.
learn. microsoft. com/en-us/archive/msdn-technet-forums/b95d3e0e-4d86-458b-a719-a02c0b22677f
Genau die selbe Lösung (Workaround) wurde auch vom Microsoft-Support selber im Jahr 2024 genannt (Nicholas.Z – MSFT | Microsoft Community Support Specialist):
answers. microsoft. com/en-us/windows/forum/all/intelppm-capping-base-processor-speed-how-to-fix/22deadd5-ec5e-448d-b33f-0771ea3e96f5
Die haben es in den vergangenen 13 Jahren nicht geschafft, diesen Treiber zu fixen, damit die Prozessor-Energieverwaltung korrekt funktioniert.
Diesen Kernel-Treiber zur CPU-Energieverwaltung kann man entweder über die Konsole oder über die Registry am Starten hindern:
sc config intelppm start= disabled
—
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\intelppm]
"Start"=dword:00000004
—
Neustarten in WinPE oder in Linux, um die Treiberdatei ( C:\Windows\System32\drivers\intelppm.sys ) umzubenennen, zum Sichergehen, dass der Treiber nicht mehr startet.
Für AMD gibt es ebenfalls einen CPU-Energieverwaltungs-Treiber von Microsoft:
amdppm.sys
Im Windows-Energiesparplan fehlen nach Deaktivierung des intelppm.sys ein paar Optionen bei Prozessor-Energie-Verwaltung.
Prozessorleistung (100 %) und Prozessorkühlung (Aktiv) sind aber noch vorhanden und alle Tools wie CPU-Z, Rainmeter, QuickCPU etc zeigen auch weiterhin lastabhängige Taktwechsel an, wie es sein soll.
Ein weiteres Problem könnte in der Datei liegen:
c:\Windows\Provisioning\Packages\Power.Settings.Processor.ppkg
("Intel PPM provisioning package")
Diese Datei stammt von Intel und soll die CPU-Energie regeln helfen.
Entweder stehen dort falsche Werte drin für manche CPUs oder der Microsoft-Treiber wertet diese Daten falsch aus.
Wie man diese .ppkg Dateien entschlüsselt habe ich aber noch nicht herausgefunden.
—
Das Tool ThrottleStop kann das falsche Runtertakten auch beheben, weil es das entsprechende CPU-Register löschen kann.
Die deaktivierte Option "BD PROCHOT" scheint die CPU immun zu machen gegen externe Aufforderungen zur Drosselung, egal ob das nun von einem Sensor oder einem verbuggten Microsoft-CPU-Treiber stammt.
Anleitung wie man das Tool ThrottleStop mittels Aufgabenplanung automatisch bei jeder Anmeldung starten lässt (im Tool selber "Start minimized" anhaken und "BD PROCHOT" abhaken):
techpowerup. com/forums/threads/effective-clock-speed.293296/#post-4749675
Besonders bei Laptops (D.ll) hilft das Tool, weil manche Modelle zu aggressiv runterregeln (Energieplan-Standard "Cool" statt "Performance", das ist vor allem bei Gaming-Laptops ein Designfehler, weil sie ihre theoretische Geschwindigkeit nicht "auf die Straße bringen").
Das Tool funktioniert aber ab der 12. CPU-Generation nicht mehr, weil das CPU-Register gesperrt wurde.
– Intelppm.sys Treiber deaktivieren
– ThrottleStop Autostart
-> jeweils unabhängig voneinander keine Probleme, auch bei C-State "C3" im BIOS und im Energiesparplan.
Microsoft sollte sich mal endlich hinsetzen und die Energiesparpläne fixen und im Treiber korrekt auswerten und umsetzen.
Erstaunlicherweise scheint es einen Zusammenhang mit dem DVB-Viewer zu geben.
Bei mir ist eine alte DVB-S PCIe Karte (TechnoTrend S2-4100) eingebaut und zum schauen oder aufnehmen benutze ich diesen DVB-Viewer. Dieses Programm läuft bei mir praktisch permanent nebenher als Background Videorekorder.
Das Problem scheint vermehrt aufzutreten, wenn ich HD-Videos mit der DVB-Karte streame.
Wenn jetzt nach einigen Stunden das Problem mit dem einen nicht ansprechbaren CPU-Kern auftritt und ich den DVB-Viewer schließe, dann berappelt sich das System wieder und der eine CPU-Kern ist auch wieder normal ansprechbar. x264 läuft dann wieder auf allen 4 Kernen statt nur auf 3 Kernen.
Das Tool ThrottleStop kann das Problem mit der deaktivierten Funktion "BD PROCHOT" übrigens nicht beheben. Wenn ein externer Sensor die CPU zum drosseln auffordern würde, dann sollte das Tool das eigentlich verhindern. Da es das nicht macht, ist vermutlich kein externer Sensor das Problem.
Es bleibt für micht weiterhin ein Rätsel, warum manchmal der eine CPU-Kern "ausfällt".
Welchen Zusammenhang kann es denn zwischen dem DVB-Viewer und dem einen nicht mehr ansprechbaren CPU-Kern geben?
Die Temperaturen der CPU-Kerne und der Grafikkarte sind niedrig und auf keinen Fall zu heiß.
Kann der MPEG-Chip auf der DVB-S-Karte zu heiß werden oder zu viel Strom ziehen, das dann über PCIe an das Windows-Energiesparsystem melden und die CPU drosseln? Warum dann aber immer nur den einen selben CPU-Kern und nicht rotierend über alle Kerne hinweg?
Wie kann man denn die Stromaufnahme und die Temperatur der DVB-Karte messen und wie schaltet man die Drosselung ab?
Überhitzung kann aber auch kaum sein, da der riesige CPU-Kühler und der Grafikkartenkühler beide die DVB-Karte eigentlich mitkühlen sollten.
Bei Überhitzung des DVB-Chips müsste es auch irgendwelche Bildfehler geben, aber die Streams sind alle einwandfrei.
Die DVB-Karte hat auch keinen eigenen Lüfter, weil Temperatur für diese Chips eigentlich nie ein Problem ist.
Es ist auch kein MPEG-2-Dekoder, der bei höheren Auflösungen wärmer werden müsste, sondern der "dumme" Chip leitet einfach nur die DVB-Streams über PCIe an DVB-Viewer bzw auf die Festplatte durch und entschlüsselt nichts. Es ist auch kein CI-Modul bzw Smartcard vorhanden.
Meine Hauptthese ist weiterhin, dass die Energiesparpläne von Windows 10 fehlerhaft sind.
Das Problem tritt unter Windows 7 und Linux weiterhin niemals auf, also muss Windows 10 irgend etwas falsch machen.
Ich habe vermutlich endgültig die Ursache des Problems im Energieprofil von Windows 10 gefunden.
In den Energiesparplänen von Windows 10 gibt es einen Unterschied zu Windows 7:
"Schwellenwert zum Erhöhen der Prozessorleistung"
auf englisch:
"Processor performance increase threshold"
GUID:
06cadf0e-64ed-448a-8927-ce7bf90eb35d
Alias:
PERFINCTHRESHOLD
(kann man im Konsolen-Befehl statt 06cadf0e-64ed-448a-8927-ce7bf90eb35d einsetzen)
In Windows 7 war dort der Wert 30 (Prozent) eingetragen in Windows 10 aber 60.
AMD empfiehlt übrigens 25.
Dieser Schwellenwert (Analogie "Hürde") 60 in Windows 10 ist zu hoch, so dass die CPU nicht richtig hochtaktet.
Diese Einstellmöglichkeit ist versteckt und kann deswegen mit der Windows-GUI nicht angeschaut und nicht verändert werden, bevor man nicht das Attribut löscht:
powercfg -attributes SUB_PROCESSOR 06cadf0e-64ed-448a-8927-ce7bf90eb35d -ATTRIB_HIDE
Jetzt kann man in der Windows-GUI im Energiesparplan den Wert "Schwellenwert zum Erhöhen der Prozessorleistung" sehen und ändern.
Man kann den Wert aber auch in der Konsole ändern (30 eintragen am Ende):
powercfg /setacvalueindex scheme_current SUB_PROCESSOR 06cadf0e-64ed-448a-8927-ce7bf90eb35d 30
Das aktuelle Energieschema mit den geänderten Werten aktivieren:
powercfg /setactive scheme_current
Anmerkung:
Das AC in setACvalueindex bedeutet Wechselstrom, also Betrieb an Steckdose.
Für Laptops mit Akku muss man die Gleichstrom-Variable benutzen:
setDCvalueindex
Das Problem mit dem schlafenden nicht mehr ansprechbaren CPU-Kern trat seitdem bei mir nicht mehr auf, obwohl der DVB-Viewer läuft (der konnte das Problem triggern) und obwohl die C-States aktiv sind (deren Abschaltung konnte das Problem entschärfen).
Damit ist für mich erwiesen, dass das Standard-Energieschema in Windows 10 falsche Werte enthält.
Vermutlich ist die AMD-Empfehlung 25 noch besser als der Windows 7-Standard 30.
Microsoft wollte mit dem Wert 60 bei Windows 10 ein aggressiveres Stromsparen einbauen und das funktioniert bei manchen CPUs nicht richtig, weil sie dann nicht mehr aufwachen, wenn Leistung gefordert ist.
Endlich habe ich den "missing Link" gefunden:
MMCSS
= "Multimedia Class Scheduler service"
= "Multimediaklassenplaner"
Diese Funktion kann dynamisch den CPU-Thread-Scheduler ändern, wenn Programme laufen, die Audio- oder Video-Streams capturen oder wiedergeben.
Dadurch sollen Drops (Aussetzer) verhindert werden, indem mehr CPU-Ressourcen für diese Programme reserviert werden.
Das erklärt, warum DVB-Viewer und Videos in Firefox-Tabs diesen Effekt triggern können und warum sich das System wieder automatisch zurück zum Normalzustand berappelt, wenn diese Programme bzw Tabs geschlossen werden.
In Windows 7 war MMCSS noch ein normaler Dienst, aber in Windows 10 wurde der Dienst im Services-Dialog ausgeblendet und läuft als Kernel-Modul.
Über die Registry kann man MMCSS aber immer noch abschalten.
Das sollte man aber nicht machen, denn diese Funktion ist ein Feature, kein Bug, kein Scherz.
Da es in Windows 10 viel mehr gleichzeitige Threads gibt im Vergleich zu Windows 7, wird diese Schutzfunktion für verlustfreie Audio-und Video-Aufnahme und Wiedergabe eher aktiviert.
Meine bisherigen oben beschrieben Maßnahmen bezüglich Stromsparmodi und Energieprofileinstellungen haben das Problem nur entschärft, aber nicht dauerhaft behoben.
Besonders wenn man viel gleichzeitig macht zusätzlich zum Video-Capturing, dann wird der MMCSS aktiv und nimmt den anderen Programmen etwas Rechenleistung weg, um diese Rechenleistung in Reserve für das in Bedrängnis geratene Capturing-Programm zu haben.
In der Registry kann man einstellen, wie viel Prozent Rechenleistung reserviert wird und welches Profil ein Programm hat (Audio, Capturing, Games, Playback, etc).
Im Quellcode von Firefox und Chromium kann man genau sehen, dass MMCSS benutzt wird, etwa auch für WebRTC ("RT" = RealTime, class ScopedMMCSSRegistration).
Die rufen das MMCSS-Api auf und melden sich an, damit der MMCSS dann dynamisch die Rechenleistung anpasst, damit es nicht zu Tonaussetzern etc kommt.
Deswegen fehlt dann anderen Programmen wie x264 manchmal scheinbar ein Rechenkern.
learn. microsoft. com/en-us/windows/win32/procthread/multimedia-class-scheduler-service
Ich hatte den betreffenden Computer vorher komplett auseinandergenommen und die Wärmeleitpaste erneuert, aber das war nicht die Ursache. Die Wärmeleitpaste war auch nach 16 Jahren nicht eingetrocknet und die neue Paste brachte keine Änderung.
Die deaktivierten C-States und höhere Einstellungen im Energieprofil konnten bei hoher Last (mehr Threads mit Audio- oder Video-Verarbeitung) das Problem nicht dauerhaft beseitigen.
Unter Windows 7 konnte der MMCSS noch theoretisch 16384 Threads bearbeiten und deren Priorität regeln, in Windows 10 ist das auf 32 Threads beschränkt.
Sieht aus als sei das Problem noch immer nicht behoben – wow
Das Problem scheint mit dem optionalen Patch behoben zu sein.
KB5062660, Windows 11, 24H2, [manueller Download], optionales Update, Juli, 26100.4762.