The Group Policy Editors, specifically gpedit.msc and gpmc from the RSAT tools, are currently experiencing significant functionality issues in Windows 11. A bug has been identified that prevents these tools from executing tasks as intended by system administrators. Instead of applying the entered values, the system truncates them due to an overflow error, leading to incorrect configurations being saved. This issue was first reported to Microsoft by Mark Heitbrink in March 2026, yet he has yet to receive any feedback regarding the matter.
A Reader’s Note from Mark Heitbrink
On May 5, 2026, Mark reached out via email, sharing insights on the malfunctioning gpedit.msc and gpmc tools on Windows client operating systems. His findings indicate that this bug is unique to Windows 11 clients; tests conducted on Windows Server showed that the values were set correctly. While I attempted to replicate the issue on Windows 10 IoT 2019 Enterprise LTSC and 22H2, I found no evidence of the problem, which left me questioning whether I had overlooked any critical details.
Mark documented his experience reporting the bug to Microsoft Research at the end of March 2026, with submission number VULN-180447 and case number 111952. Unfortunately, aside from an automated acknowledgment, he has not received any further communication.
Reproducing the Error
In his recent post on gruppenrichtlinien.de, titled “Kaputt: GPEdit und GPMC am Client – Stand 05.2026,” Mark elaborates on how to reproduce the issue. The process begins by launching either gpedit.msc or GPMC from the RSAT Tools on a Windows 10 or Windows 11 client. Users should navigate to the following path in the Group Policy Editor:
Computer Configuration Administrative Templates Windows Components Delivery Optimization
Once there, select the group policy Delay Foreground download from http (in seconds). After enabling the policy, users should enter the decimal value “4294967295” (FFFF FFFF) in the designated field.
In my own testing, the Policy Editor dialog box closed without any notification, and the policy appeared to be enabled. However, upon checking the policy in Windows 10 IoT 2019 Enterprise LTSC, the decimal value “4294967295” was displayed correctly. In contrast, on Windows 11 25H2, I encountered a different outcome, with the value being altered to “2147483647” (7FFF FFF). Although I attempted to replicate this behavior later, I was unsuccessful. After publishing the German version of this blog post, I received confirmation from other readers who reported similar experiences of the value being reduced to “2147483647.”
A Possible Reason
Mark has proposed a potential explanation for this anomaly in his German post. Dennis Lange and Stefan Kanthak have speculated that the Windows client might be utilizing the INT data type rather than unsigned INT. This miscalculation could lead to an overflow when attempting to process the value 231 – 1 = 2147483647. When the Policy Editor reads the *.ADMX file, it appears to convert the value to LONG (or INT) instead of DWORD (or “unsigned INT”), resulting in the modification.
Interestingly, I did not encounter a dialog box indicating that the value exceeded the maximum limit, as Mark described. The situation is further complicated by my tests on Windows 10 2019 IoT Enterprise LTSC and Windows 10 22H2, where the value was written correctly. In contrast, on Windows 11 25H2 (operating within a virtual machine), the value was altered during the registry writing process. Another user, Bolko, noted that his Windows 11 Version 25H2 – Build 26200.6584 (dated September 9, 2025) also did not modify the written registry values, suggesting that a recent patch may have introduced this bug.
Mark has highlighted that there are over 50 policies affected by the MaxValue issue, spanning across OS, Defender, and Office policies, and he has provided additional details in his article. The question remains: can others replicate this issue?
