[English]Der Gruppenrichtlinien-Editor (gpedit.msc oder gpmc aus den RSAT Tools) ist in Windows 11 "kaputt", macht er doch auf Grund eines Bugs nicht, was ihm vom Administrator aufgetragen wird. Eingetragene Werte werden nicht übernommen, sondern wegen eines Überlauffehlers reduziert und dann gespeichert. Mark Heitbrink hat es im März 2026 an Microsoft gemeldet, ist bisher ohne Reaktion geblieben.
Leserhinweis von Mark Heitbrink
Mark hatte mich zum 5. Mai 2026 per Mail mit dem Betreff "Warum die PAW ein Server ist (sein sollte)" kontaktiert und mich darauf hingewiesen, dass sowohl gpedit.msc als auch die gpmc aus den RSAT Tools einen gravierenden Fehler auf einem Windows Client OS zeigen.
Mark hat es auf Windows 11 24H2 und 25H2 reproduzierbar getestet, und ich habe eben einen Test auf Windows 10 IoT 2019 Enterprise LTSC, Windows 10 22H2 Pro sowie auf Windows 11 25H2 Pro (Build 26200.7623) gefahren. Der Gruppenrichtlinien-Editor gpedit.msc verändert unter Windows 11 24H2/25H2 beim Speichern die vom Administrator vorgegebenen Werte.
Der Fehler tritt wirklich nur auf Windows 11-Clients auf, auf einem Windows Server wird der Testwert korrekt gesetzt, wie Mark bei Tests festgestellt hat. Ich habe es unter unter Windows 10 IoT 2019 Enterprise LTSC und 22H2 nicht reproduzieren können (hoffe, mir ist auf die Schnelle kein Fehler unterlaufen und ich habe vor lauter Bäumen den Wald nicht mehr gesehen).
Dazu schreibt Mark, dass er den Bug Ende März 2026 bei MS Research ("Submission number: VULN-180447, Case number: 111952") gemeldet. Aber außer einer automatischen Antwort "Wir haben es erhalten, Danke schön" gab es bis jetzt keine weitere Rückmeldung.
Den Fehler reproduzieren
Mark hat das Ganze inzwischen auf gruppenrichtlinien.de im Beitrag Kaputt: GPEdit und GPMC am Client – Stand 05.2026 beschrieben. Um das Problem zu reproduzieren, ruft man entweder gpedit.msc des Clients oder gpmc aus den RSAT Tools unter Windows 10 bzw. Windows 11 auf. Dann navigiert man im Gruppenrichtlinien-Editor zu folgendem Zweig:
Computer Configuration\ Administrative Templates\ Windows-Komponenten\ Übermittlungsoptimierung\
oder in Englisch zu
Computer Configuration\ Administrative Templates\ Windows Components\ Delivery Optimization\
Dann wählt man die Gruppenrichtlinie Vordergrunddownload von HTTP verzögern (in Sekunden) (Englisch Delay Foreground download from http (in seconds)) an.
Im Anschluss versucht man im Richtlinieneditor den Dezimalwert "4294967295" (FFFF FFFF) im betreffenden Feld der aktivierten Gruppenrichtlinien einzugeben.
Bei mir schließt sich das Dialogfeld des Richtlinieneditors kommentarlos und die Richtlinie wird aktiviert. Kontrolliere ich anschließend diese Richtlinie unter Windows 10 IoT 2019 Enterprise LTSC, findet sich der eingetragene Dezimalwert "4294967295" in der Anzeige (siehe obiges Dialogfeld). Unter Windows 11 25H2 wurde mir allerdings auf einem System das in nachfolgendem Screenshot gezeigte Ergebnis angezeigt.
Der Richtlinien-Editor hat den Wert auf "2147483647" dezimal (7FFF FFF) reduziert. Ergänzung: Aber es ist noch komplexer – obiger Screenshot zeigt den reduzierten Wert. Ich habe es nun in einer VM mit Windows 11 25H2 Pro (Build 26200.7623) erneut getestet. Jetzt bleibt der Dezimalwert "4294967295" im Feld erhalten (deckt sich mit dem Kommentar von Bolko weiter unten).
Eine mögliche Erklärung
Mark hat in seinem Beitrag hier eine mögliche Erklärung angegeben. Dennis Lange und Stefan Kanthak vermuten, dass der Windows Cient den Datentyp INT statt unsigned INT verwendet. Dann kommt es beim Wert2**31 – 1 = 2147483647 zu einem Überlauf. Beim Lesen der *.ADMX nach LONG alias INT statt DWORD alias "unsigned INT" konvertiert der Richtlinien-Editor den Wert und verändert diesen.
Abweichend zur Beschreibung von Mark bekomme ich aber bei Eingabe des Dezimalwerts "4294967295" keinen Dialog mit einem entsprechenden Hinweis angezeigt. Erst wenn ich versuche, einen höhere Wert einzutreten, erscheint obigem Dialogfeld und der Wert wird auf "4294967295" begrenzt. Bis auf einen Versuch konnte ich das von Mark skizzierte Verhalten nicht sehen, und kann es auch nicht reproduzieren (sehr seltsam).
Mark schreibt "Es gibt über 50 Richtlinien mit dem MaxValue problem, verteilt über OS, Defender und Office Richtlinien." und erläutert in seinem Artikel weitere Details. Kann das jemand von Euch nachstellen?
MVP: 2013 – 2016
Die Vermutung ist sehr wahrscheinlich richtig.
Was fraglich ist, ist wie man dazu kommt ein funktionierenden Code mit einem verbeugtem zu ersetzen.
Ich meine wer setzt sich hin, vor funktionierenden Code, sieht oh das ist ein DWORD machen wir doch ein LONG daraus.
Das muss doch so ein AI misst sein die haben eine AI über die ganze Codebasis laufen lassen und dann alle Empfehlungen ohne nach zu denken übernommen, vermute ich mal.
Ich denke, der Fehler liegt nicht direkt im Gruppenrichtlinieneditor, sondern in irgend einer Bibliothek, (möglicherweise C Runtime). die völlig unabhängig bei Windows 11 verschlimmbessert wurde und jetzt diesen Seiteneffekt hat.
Von diesem Dialogfeld bis hin zum Registry-Value, der damit beeinflußt werden soll ist es doch ein recht weiter Weg mit vielen beteiligten Softwarekomponenten und letztendlich ist auch das Design der Registry schuld, die nur REG_DWORD als 32-bittigen Wert kennt und keinen direkten Unterschied beim Vorzeichen macht.
DWORD ist 32bittig, ja.
Wenn du einen 64bittigen Wert in der Registry brauchst, dann ist QWORD der richtige Wert.
Workarround für das Verhalten:
Registry-Key direkt in den GPOs setzen.
Win 25H2 aktueller Updatestand
Wie bei Marc – Hinweis im Dialog wird angezeigt.
Hast Du das mit gpedit.msc getestet – als Administrator? Ich habe den Hinweisdialog in der VM nicht zu Gesicht bekommen – was mache ich falsch?
Hier kommt der Hinweis ebenfalls (Win11, 25H2).
Bist Du sicher, die korrekte Zahl — also eine zu große — eingegeben zu haben? Ich habe bewusst eine viel zu große eingegeben, einfach die '4'-Taste lange festgehalten und anschließend übernehmen geklickt. Dann kam der Hinweis, dass der Wert auf 2^31 – 1 zurückgesetzt wird.
Wenn das bei Dir nicht der Fall ist, dann … tja, entweder fällt Dein System in die Kategorie "nicht betroffen", oder aber die verursachende Bibliothek ist noch im alten Zustand oder bereits wieder gefixt — falls Fix vorhanden.
Schwierig, schwierig, ist bei dem System wie Glaskugel schauen und Teesatz lesen.
Ich habe den Wert von Mark per Copy & Paste übernommen und zur Sicherheit probiert, über das Drehfeld den Wert zu erhöhen, geht aber nicht.
Mit Admin-Rechten und wie hier im Blog beschrieben.
Inzwischen an drei anderen NBs von verschiedenen Herstellern und einer Win 11 25H2 pro VM auf Proxmox. Jedes Mal erscheint der Hinweis.
Wenn ich meine fertige Dateien in der aktuellen 25h2 Pro nach:
C:\Windows\System32\GroupPolicy (Machine und User) kopiere
(ohne alte die Datei: C:\Windows\System32\GroupPolicy\gpt.ini)
und dann einmal: gpedit und gpupdate /force "laufen lasse",
tritt dann auch dieser Bug auf? (hier nicht)
Nein. Es geht um den Schreibvorgang des Editors in das C:\Windows\System32\GroupPolicy\Machine\registry.pol File. Werte die drin sind, bleiben wie sie sind. Du müsstest einen der betroffenen Werte erneut editieren, danach sind sie falsch.
"Windows 10 IoT Enterprise LTSC 2021 Build 19044.7184" funktioniert korrekt.
"Windows 11 Pro – Version 25H2 – Build 26200.6584" (09.September 2025) funktioniert hier ebenfalls korrekt.
Der eingegebene Wert 4294967295 bleibt erhalten, nach Klick auf OK, schließen des Gruppenrichtlinieneditors und Neustart des Gruppenrichtlinieneditors.
Test mit gpedit.msc als Administrator.
Jetzt könnte man noch herauszufinden versuchen, ab welchem Patchlevel Windows 11 versagt.
Automatische Updates habe ich mittels deaktiviertem Netzwerkadapter der VM verhindert.
Schau mal in die Registry, wie der Wert am Client ankommt. Rein interesse halber. Er sollte stimmen, da der Editor ihn schon richtig anzeigt.
2 gute "Übersetzer" von Policy to Registry und ViceVersa
https://gpsearch.azurewebsites.net/
https://admscope.com/admx/ *neu*
Key: HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization
Value: DODelayForegroundDownloadFromHttp
Registry:
hex: ffffffff
dez: 4294967295
alles ok.
Danke. Das wäre sonst wirklich komisch geworden :-)
d.h. das der Fehler irgendwann nach 09.2025 als Update integriert wurde. :-(
Ich blicke nicht mehr durch (zu viele Bäume im Wald) – gerade noch auf einem Windows 11 25H2 in einer VM getestet. Nun wird der eingegebene Wert beibehalten – habe es oben im Text schon nachgetragen. Das Problem muss tiefer liegen – da Bolko es nicht nachstellen kann, bei mir auch nicht reproduzierbar ist, von anderen Lesern aber auch als Bug bestätigt wurde. Ich mache für heute mal Pause.
Als einen absoluten Bug würde ich das nicht mal bezeichnen. Wenn es zu einem Absturz käme wegen "overflow", wäre das an dieser Stelle ein echter Bug. Vielleicht war es vor der Veröffentlichung sogar so, und die KI hat als Lösung den "catch" mit dem Hinweis und der Anpassung vorgeschlagen.
Nachgelagert ist es dann aber wieder ein eklatanter Fehler. Da fängt jemand aus seiner Sicht ungültige Werte ab, ändert sie mit Hinweis ab, ohne sich über die Folgen im Klaren zu sein.
Ob die Fehlermeldung abgefangen wird oder Nicht ist irrelevant. Das Problem ist: Es werden anschliessend Invalide Werte in die Registry des Targets importiert. Ob die Auswirkung "eklatant" ist oder ändert nichts am Problem. Der Wert der zu kontrollieren gilt ist flasch konfiguriert.
Irgendwann um November 2025 wurde ja ebenfalls das Hoppala von "Set-GPPrefRegistryValue" beim Schreiben von String Values "implementiert", wo das letzte Zeichen des Strings abgeschnitten wurde. Möglicherweise ist das ebenfalls bereits ab September passiert? "Set-GPPrefRegistryValue" wurde ja immerhin mit dem April Patchday 2026 gefixed.
Wer weiß, was in diesem "legacy Bereich" von Microsoft gerade getan wird. :-)
Vielen Dank für den Tipp mit https://admscope.com/ . Sehr gut!
Der zweite Teil des Artikels von Mark Heitbrink ist ebenfalls beängstigend, weil Windows manchen GPO-Zustand "Aktiviert" mit dem Wert 4294967295 kodiert.
Wenn dieser Wert jetzt aber falsch ausgewertet oder falsch geschrieben wird aufgrund des signed-INT-Überlaufs, dann wird die GPO eben gar nicht aktiviert, obwohl sie so eingestellt worden ist.
Dann sieht man zwar im Gruppenrichtlinieneditor die aktivierten Richtlinien und fühlt sich sicher, aber die Richtlinien sind eventuell trotzdem aus.
2.
Ist das vielleicht ein Problem mit gewissen Versionen von NET Framework oder NET Desktop oder VisualC Runtimes, die durch die Datei gpedit.dll benutzt werden?
Welche Versionen davon haben denn diejenigen installiert, bei denen der Fehler auftritt?
Die gpedit.msc benutzt:
gpedit.dll und diese wiederum benutzt
mmc.exe und diese wiederum benutzt (laut Process Explorer, Properties von mmc.exe, Reiter ".NET Assemblies")
NET 4.0.30319.0 (NET Framework 4 x64, identisch bei meinen Win10 und Win11),
dort sieht man dann die kompilierten NET-Assemblies im Ordner C:\Windows\Assembly.
Bei Windows 10 sind es 5 Assemblies und bei Windows 11 sind es 11 Assemblies.
Eventuell wurden auf den betroffenen fehlerhaften Systemen diese Assemblies mit einer fehlerhaften NET Version kompiliert?
In meinem Win11 habe ich NET Framework 4.8.1 installiert (Release-Version-Code 533509 in der Registry).
In Windows 10 habe ich ebenfalls NET Framework 4.8.1 installiert (Release-Version-Code 533325 in der Registry).
steht dort in der Registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
Wenn ich Zahlen größer als 4294967295 eingebe, dann erscheint ebenfalls das Dialogfenster, aber mit der korrekten Feststellung "größer als der Maximalwert von 4294967295".
Identisch bei Win10 und Win11.
2.
Integer-Grenzwerte in C und C++
INT_MAX 2147483647
UINT_MAX 4294967295
LONG_MAX 2147483647
ULONG_MAX 4294967295
*ttps://learn.microsoft.com/de-de/cpp/c-language/cpp-integer-limits?view=msvc-170
Eventuell hat der Programmierer oder die KI einfach ein "U" (für unsigned, also ohne Vorzeichen) am Anfang eines Vergleichs des aktuellen Eingabewertes mit der oberen Grenz-Konstante vergessen oder der Fehler steckt im NET Framework Assembly-Compiler.
3.
Der Schrotthaufen Windows 11 ist in diesem Zustand nichtmal bedingt einsatzfähig, wenn die Variablen mal mit und mal ohne Vorzeichen ausgewertet werden und man nicht weiß, wann und wann nicht das Ergebnis korrekt oder falsch ist.
Use vibecoding they said, it'll be fun they said.
Warum sollte ich ein so hohen Wert überhaupt irgendwo in einer GPO einstellen?
In welchem echten Szenario gibt es jetzt ein konkrete Problem, ich sehe es nicht ?!?
… weil: Der Programmierer entschieden hat, das "Aktiviert" für seine Funktion bedeutet das alle Bits´n Bytes = 1 , bzw. F sind. Das macht bei 8 Stellen HEX -> FFFFFFFF oder auch Dezimal = 4294967295
Lesenden wird hier geholfen:
https://www.gruppenrichtlinien.de/artikel/kaputt-gpedit-und-gpmc-am-client-stand-052026
ca 20 (sicherheitsrelevante) Werte alleine unterhalb von, die FFFFFFFF für aktiviert verwenden.
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\*
Wenn man eine Richtlinie auf "Aktiviert" stellt, dann wird der Wert 4294967295 in die Registry geschrieben, ohne dass man da manuell irgend welche Zahlen eingeben muss oder diesen Wert im Gruppenrichtlinieneditor zu sehen bekommt.
Wenn jetzt aber dieser UINT_MAX bzw ULONG_MAX falsch mit Vorzeichen gerechnet wurde statt ohne Vorzeichen, dann ist der Soll-Wert 4294967295 von der Variablen gar nicht aufnehmbar, wird dann zu 2147483647 verringert und falsch in die Registry eingetragen und danach falsch ausgewertet, nämlich als aktiviert=false (weil 2147483647 ungleich UINT_MAX bzw ungleich ULONG_MAX ist) statt =true, also das Gegenteil von dem was man eingestellt hatte.
Du stellst also eine Regel auf an und intern arbeitet Windows so als ob die Regel auf aus ist.
Das ist durchaus ein Problem.
Stell dir das mal bei einem automatisch fahrenden Auto vor. Du aktivierst den Auto-Pilot, die Anzeige steht auf "ON"und das Auto fährt gegen einen Baum, weil der Autopilot "OFF" ist, obwohl er "ON" anzeigt.
siehe den Artikel von Mark Heitbrink ab der Stelle:
"Richtig kaputt geht es dann aber, wenn"
*ttps://www.gruppenrichtlinien.de/artikel/kaputt-gpedit-und-gpmc-am-client-stand-052026
Zum Glück bearbeiten wir GPOs fast auschließlich nur noch auf Servern. Nur bei Applocker muss man da alle Schaltjahre Ausnahmen machen, um die Modern-App-Regeln zu bearbeiten.
Aber ist schon eine ziemliche Schlamperei!
da hilft Event forwarding in der XML Ansicht des Events. da stehen alle Felder/Werte
wähle eine beliebige App am Server im Applocker und nutze die benutzerdefinierten Felder. dann kannst du direkt aus dem XML Event Copy Pasten
Im Artikel von Mark Heitbrink und auch hier im Blog-Artikel fehlt die Buildnummer wo der Fehler reproduzierbar aufgetreten ist.
Bei jeder Fehlermeldung bezüglich Windows ist die Buildnummer eine der wichtigsten Informationen.
Kann man diese Buildnummer mal bitte nennen und auch in den Artikeln nachtragen?
Die NET Framework Version (4.7.2 oder 4.8 oder 4.8.1) ist eventuell ebenfalls von Belang und die KB-Nummer des letzten installierten Rollups von diesem NET auf dem betroffenen System wo der Fehler auftritt.
Man muss vermutlich maximal die folgenden 9 Builds testen, die zwischen September 2025 (als OK getestet) und Ende März 2026 (Fehlermeldung von Mark Heitbrink an Microsoft) liegen:
14.10.2025
KB5066835 – Rollup – 25H2 – Build 26200.6899
11.11.2025
KB5068861 – Rollup – 25H2 – Build 26200.7171
09.12.2025
KB5072033 – Rollup – 25H2 – Build 26200.7462
13.01.2026
KB5074109 – Rollup – 25H2 – Build 26200.7623
17.01.2026
KB5077744 – Rollup OOB 1 – 25H2 – Build 26200.7627
24.01.2026
KB5078127 – Rollup OOB 2 – 25H2 – Build 26200.7628
10.02.2026
KB5077181 – Rollup – 25H2 – Build 26200.7840
10.03.2026
KB5079473 – Rollup – 25H2 – Build 26200.8037
21.03.2026
KB5085516 – Rollup OOB – 25H2 – Build 26200.8039
getestet:
KB5072033 – Rollup – 25H2 – Build 26200.7462 , 09.12.2025
Alles OK, keine Probleme.
Der Soll-Wert 4294967295 bleibt so wie eingegeben im Gruppenrichtlinieneditor und auch in der Registry.
Damit verringert sich das Problem auf die Monate Januar, Februar, März 2026, die man noch testen muss.
24h2 war Patchlevel April, 25H2 stand Mai
Warum Patchstand April und Mai, obwohl du das Problem bereits im März an Microsoft gemeldet hattest?
In deinem Artikel steht:
"Ich habe es Ende März bei MS Reserach eingekippt"
Hast du auch NET Framework Updates installiert?
Welche Version (4.8, 4.8.1) und welches letzte KB des NET-Rollups?
Trotzdem ist April und Mai eigentlich nicht genau genug, denn manchmal veröffentlicht Microsoft mehrere Out-of-Band Updates in einem Monat zusätzlich zum Patchday-Rollup.
Deswegen sollte man immer bei jeder Fehlermeldung auch die Build-Nummer mit angeben, bei der das Problem zuerst bemerkt worden ist, weil das die Suche eingrenzt.
dann war es 24H2 März und 25H2 März, April und Mai :-D
ACHTUNG ACHTUNG, Windows 11 ist Kernschrott
getestet:
KB5077181 – Rollup – 25H2 – Build 26200.7840 , 10.02.2026
Tool: gpedit.msc
GPedit.msc benutzt die Dateien gpedit.dll (10.0.26100.7705) und mmc.exe (10.0.26100.7824).
Ich habe kein NET Framework Update und kein NET Desktop installiert, sondern nur das normale Windows 11 Rollup ausd Februar 2026.
Ich habe auch keine VisualC-Runtimes installiert.
Der Fehler steckt im Windows 11 selber.
Statt eingegebenem Soll-Wert 4294967295 meldet dieses Hochstapler-OS den falschen Ist-Wert 2147483647 , genauso wie Mark Heitbrink es schrieb, mitsamt falschem Wert in dem Dialogfenster und in der Registry.
Windows 11 ist in diesem Zustand nicht einsatzfähig, da manche Gruppenrichtlinien-Einstellungen für "Aktiviert" (ff ff ff ff) intern falsch gespeichert werden, nämlich wie "nicht aktiviert" (7f ff ff ff, Abweichung von ff ff ff ff, daher liefert ein Vergleich false statt true).
Microsoft will unsigned Werte in signed Variablen speichern, was nicht funktionieren kann, da das Vorzeiehcn eben auch Speicherplatz braucht, daher diese Abweichung von "f" und "7" im oberen Bit.
Keiner hat es gemerkt außer Mark Heitbrink und Microsoft ist ernsthaft zu blöd, das seit März zu fixen, obwohl sie einfach nur bei einer Variablen ein "U" für "unsigned" davor schreiben müssten?
Auch Weia, so ein Saftladen.
Die 3 Rollups (inkl. OOB1 und OOB2) aus Januar habe ich noch nicht getestet, da ich die Intervall-Halbierungs-Methode angewendet habe, um weniger testen zu müssen.
Im Dezember 2025 war der Fehler noch nicht vorhanden.
Warum fummelt Microsoft da herum und ändert Routinen, die vorher jahrzehntelang korrekt funktionierten?
Die Behauptung von Mark Heitbrink bezüglich der verlinkten Schannel.admx Vorlage stimmt ebenfalls.
Wenn man diese admx in den Ordner Windows\PolicyDefinitions kopiert, gpedit startet und unter dem Pfad
Computer Configuration,
Administrative Templates,
Network,
SSL Configuration (SSL-Konfigurationseinstellungen),
Hashes,
sha-384
auf "Aktiviert" umschaltet,
dann landet in der Registry der falsche Wert 7fffffff statt ffffffff unter dem Pfad
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA384]
"Enabled"=dword:7fffffff
Im "Windows 10 IoT Enterprise LTSC 2021" hingegen steht dort der korrekte Wert ffffffff in der Registry.
Windows 10 rechnet korrekt unsigned (ohne Vorzeichen).
Windows 11 ab evtl Januar (noch nicht getestet) oder spätestens ab einschließlich Februar 2026 rechnet (falsch) signed (mit Vorzeichen).
Windows 11 bis einschließlich Dezember 2025 rechnet noch genauso wie Windows 10 korrekt unsigned.
Wenn jetzt ein Programm oder Windows selber in einem anderen Tool als Gpedit diesen Registry-Wert abfragt und alle Bits vorzeichenlos auswertet, dann gibt es eine Abweichung und der Vergleich wird false statt true.
In Gpedit stellt man also "Aktiviert" ein und die anderen Tools und Windows-Routinen sehen "nicht aktiviert", also das Gegenteil von dem was man eingestellt hatte.
Es macht auch rein logisch gesehen gar keinen Sinn, in solchen Variablenspeichern (sinngemäß Boolean, Aktiv oder nicht aktiv, an oder aus) zusätzlich ein Vorzeichen einzubauen.
Vorher, bis einschließlich Dezember 2025 wurde getestet, ob alle 32 Bits auf "1" stehen, daher sind alle 4 Bytes "ff".
Nachher stehen aber nicht alle 32 Bits auf "1".
Aus dem korrekten Soll-Wert:
11111111111111111111111111111111
macht Windows 11 ab einschließlich Februar 2026 den falschen Ist-Wert:
01111111111111111111111111111111
bzw
1111111111111111111111111111111
Vorne steht eine 0 statt eine 1 bzw ein Bit fehlt (reserviert als Vorzeichenspeicher der signed Variable).
Wenn Windows 11 durchgehend überall in sämtlichen Windows-Routinen signed, also mit einem Bit weniger rechnen würde, dann könnte man das fehlerfrei so machen.
Das muss man aber bezweifeln, denn dafür gibt es gar keinen logischen Grund, sowas zu machen und die Third-Party-Tools wissen von so einer Änderung auch nichts, sonst müssten die allesamt umgeschrieben werden und nach Windows-Build-Nummer differenzieren, ob signed oder unsigned gerechnet werden soll.
Das ist doch Quatsch, also hat Windows ein echtes Problem, wenn dieser Bug nicht gefixt wird.
Noch ein Argument für die fehlerhafte Logik von Windows 11:
Angenommen man hatte bereits vor dem fehlerhaften Update von Februar mit dem vorher noch unsigned arbeitenden Gpedit die Richtlinien eingestellt und damit die unsigend Registry-Werte geschrieben ("ff ff ff ff").
Dann müsste Windows 11 nach dem Februar Update auch alle Registry-Werte überprüfen und umschreiben auf die neue signed-Richtlinie, also alle "ff ff ff ff" auf "7f ff ff ff" ändern.
Das macht Windows 11 aber nicht und deshalb ist das in sich logisch falsch mit dieser unsigned-zu-signed-Änderung.
Außerdem gibt es ja auch noch die abweichende Codierung eines Richtlinien-Wertes zwischen lokalem Gpedit ("7f ff ff ff") und der Einstellung derselben Richtlinien auf dem Server ("ff ff ff ff").
Wenn Windows eine gewollte Änderung hätte machen wollen, dann müsste es auch einheitlich für den Server gelten, denn der kann die selben Richtlinien an die Clients verteilen, die man auf dem Client lokal selber einstellen kann.
Woher soll denn der Client dann wissen, was richtig ist, wenn der Client selber etwas anderes einstellt als der Server für die selbe Einstellung in der selben Richtlinie?
Das ist zweifellos ein Bug und nicht gewolltes Design (aus der Hölle).
Klingt etwas nach "Verbesserung" durch Vibecoding oder sonst eine "KI" Hilfe…
getestet:
KB5078127 – Rollup OOB #2 – 25H2 – Build 26200.7628 , 24.01.2026
alles OK.
4294967295 bleibt 4294967295
und "Aktiviert" wird ebenfalls korrekt zu 32 Bit "1" unsigned codiert.
Registry:
hex: ffffffff
dez: 4294967295
Damit sind auch das Rollup (KB5074109 – Build 26200.7623) und das OOB #1 (KB5077744 – Build 26200.7627) aus Januar noch korrekt.
Das Problem begann also tatsächlich erst mit dem Februar-Patchday 10.02.2026:
KB5077181 – Rollup – 25H2 – Build 26200.7840
Microsoft muss also nur die beiden Builds 26200.7628 und 26200.7840 vergleichen, um den Fehler zu finden im gpedit und im GPMC aus den RSAT Tools.
Damit ist der Test abgeschlossen.
Die Fehlermeldungen hier im Blog-Artikel und im Artikel von Mark Heitbrink sind korrekt.
Die "Build 26200.7840" könnte man aber noch in den beiden Artikeln nachtragen.
https://skanthak.hier-im-netz.de/blunder.html#blunder99 sowie (das Ende von) https://skanthak.hier-im-netz.de/whispers.html#whisper13 zeigen ähnliche Fehler