You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
π Bug: Windows Update Services auto-reactivate every 7 daysΒ #34
After running wputility.bat β Disable Updates (Option 1), all services are correctly disabled.
However, after exactly 7 days, the Update services silently reactivate on their own β without any user interaction.
Please refer to the attached video.
Observed symptoms after reactivation:
Taskbar notification: "Updates are ready to install"
Settings β Windows Update shows the normal Update UI again (no longer showing "Something went wrong. Try to reopen Settings later."
Recurrence pattern:
Occurrence
Date
1st
March 8, 2026
2nd
March 15, 2026
3rd
March 22, 2026
Interval is exactly 7 days β consistent and reproducible.
Minor: Build 26200 not recognized
The osCodenameBackup lookup ends at geq 26100 β 24H2. Build 26200 (Windows 11 25H2) falls into this bucket incorrectly.
Root Cause β Hypothesis β not final β Updated May 16, 2026
Goal: The intended end state is a fully locked-down Windows Update UI permanently showing "Something went wrong. Try to reopen Settings later." in Settings β Windows Update. This state is already achieved by running wputility.bat β Option 1 alone β however, after exactly 7 days, Windows silently reactivates update components and the UI returns to normal. The purpose of this script is to prevent that reactivation from happening, so the locked-down state persists beyond the 7-day cycle.
I believe wputility.bat already handles services correctly via sc config, net stop, and sc failure reset= 0 actions= "".
However, several things were missing and have been addressed incrementally:
WaaSMedicSvc runs as a Protected Process Light (PPL) via its kernel plugin (WaaSMedicPS.dll) on Windows 11 25H2. This allows it to silently restore disabled services and recreate scheduled tasks β overriding sc config, net stop, and registry writes entirely. Renaming WaaSMedicPS.dll removes its kernel-level privileges.
UpdateOrchestrator scheduled tasks are not neutralized by taskUpdatesDisable. wputility.bat disables telemetry tasks (schtasksDisable0-17) but none of these:
Important: These tasks are owned by TrustedInstaller, not SYSTEM or Administrators. schtasks /Change /TN "..." /DISABLE always returns ERROR: Access is denied even from an elevated Administrator shell. The only working approach is takeown + file rename after stopping the Task Scheduler service.
Task Scheduler Registry TaskCache is not cleared. Even after renaming task files, Task Scheduler rebuilds them on next boot from its internal registry cache at: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\UpdateOrchestrator\ HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\WindowsUpdate\
Both the task files and the corresponding registry keys must be removed together, otherwise Task Scheduler silently recreates the files on every reboot.
\Microsoft\Windows\WindowsUpdate\ tasks are not neutralized. These tasks exist outside the UpdateOrchestrator folder and are not covered by any existing fix. On Windows 11 25H2, Scheduled Start and Refresh Group Policy Cache were confirmed to trigger a reactivation notification every 7 days - even with all UpdateOrchestrator tasks renamed and all services disabled. They must be treated identically: takeown + file rename + TaskCache deletion + Deny ACE.
UsoSvc, WaaSMedicSvc, and wuauserv are not explicitly disabled. Even with WaaSMedicPS.dll renamed, all three services start on boot via Delayed Auto Start or on-demand SCM triggers. UsoSvc is the direct trigger for MusNotificationUx.exe (the update popup). Both must be explicitly set to Start=4 (Disabled) with FailureActions cleared β confirmed effective on Windows 11 25H2 (April 29, 2026).
Service registry Start values revert to DEMAND_START (3) after boot. Even after setting Start=4, Windows SCM rewrites its own service config through an internal path that bypasses Registry ACLs. A standard reg add from an elevated Administrator shell is insufficient β the write must be performed as SYSTEM via a Scheduled Task. Additionally, sc sdset must be applied to UsoSvc and wuauserv to deny Write DAC (WD) for both SYSTEM and TrustedInstaller at the SCM security descriptor level β confirmed required on Windows 11 25H2 (May 9, 2026).
WaaSMedicPS.dll still existed in WinSxS (component store) and could be reintroduced by servicing. Earlier versions only renamed the System32 copy. The PPL plugin WaaSMedicPS.dll also lives under %SystemRoot%\WinSxS\...WaaSMedic... and can be used by servicing/repair routines as a source of truth. The current script additionally enumerates all *WaaSMedicPS.dll matches under %SystemRoot%\WinSxS (via dir /s /b) and deletes every instance after takeown + icacls /grant + del. After this change, dir /s /b "%SystemRoot%\WinSxS\*WaaSMedicPS.dll" returns File Not Found while the Windows Update UI remains in the "Something went wrong" state.
WaaSMedicPS.dll.bak ACL in System32 still contained NT SERVICE\TrustedInstaller. Even when the DLL only exists as .bak, a future repair routine could still try to restore it as long as TrustedInstaller has write access. The current script also removes any WaaSMedicPS.dll.bak2β.bak5 copies in %SystemRoot%\System32 and strips the NT SERVICE\TrustedInstaller ACE from WaaSMedicPS.dll.bak, so TrustedInstaller no longer has a straightforward path to bring it back.
Note on sc sdset WaaSMedicSvc:sc sdset WaaSMedicSvc returns [SC] SetServiceObjectSecurity FAILED 5: Access is denied β this is expected and known behavior. SCM internally protects the WaaSMedicSvc security descriptor and does not allow external modification, even as Administrator. The Start=4 lock via SYSTEM Scheduled Task is sufficient since WaaSMedicPS.dll is already renamed, which removes PPL kernel-level self-repair capability.
Note on UpdateModelTask: A registry-only entry (Tree\UpdateOrchestrator\UpdateModelTask) with no corresponding file or Tasks\{GUID} entry reappears after every Task Scheduler restart. This is hardcoded Windows behavior and is confirmed harmless - no executable content, no trigger possible.
Note on boot timing: After a reboot, Task Scheduler may take between 1 and 7 minutes before all task-related registry entries and folder contents are fully initialized. For safety, status checks on task files and TaskCache entries should only be performed after at least 10 minutes of uptime.
Reactivation timeline observed:
Date
Event
March 8, 2026
Reactivation - wputility.bat used again
March 15, 2026
Reactivation - wputility.bat used again
March 22, 2026
Reactivation - wputility.bat used again
March 30, 2026
Reactivation - v1 applied
April 6, 2026
Reactivation - v1 failed - v2 applied (correct Deny ACE, WaaSMedicPS.dll, still no TaskCache)
Reactivation - v3 failed - v4 applied - v3 did not cover \Microsoft\Windows\WindowsUpdate\Scheduled Start and \Microsoft\Windows\WindowsUpdate\Refresh Group Policy Cache - these triggered a reactivation notification every 7 days, independently of all services and UpdateOrchestrator tasks
April 29, 2026
Reactivation - v4 failed - v5 applied - added explicit disable of UsoSvc, WaaSMedicSvc and wuauserv via Start=4 + FailureActions cleared - all three confirmed STOPPED (EXIT 1077) after reboot with 10 min uptime
May 4, 2026
Manual check revealed Windows Update UI had returned - all three services (UsoSvc, WaaSMedicSvc, wuauserv) were RUNNING despite Start=4 set by v5 - root cause: SCM was rewriting START_TYPE back to DEMAND_START (3) on boot through an internal path that bypasses Registry ACLs
May 9, 2026
v6 applied - fixed START_TYPE reverting to DEMAND_START (3) after boot: Start=4 rewritten for all three services as SYSTEM, sc sdset Deny WD applied to UsoSvc and wuauserv - sc sdset WaaSMedicSvc returns Access is denied (expected, SCM-protected) - all three confirmed STOPPED (EXIT 1077) + START_TYPE: 4 DISABLED + reg query Start returns ERROR: Access is denied after 10+ min uptime - Windows Update UI remains on "Something went wrong" state
May 16, 2026
Reactivation - v6 failed - v7 applied - extended WaaSMedic hardening: all WaaSMedicPS.dll copies removed from %SystemRoot%\WinSxS, WaaSMedicPS.dll.bak ACL cleaned to remove NT SERVICE\TrustedInstaller; verification shows only .bak under System32, no WaaSMedicPS.dll under WinSxS, all three services stay DISABLED / STOPPED, and all UpdateOrchestrator/WindowsUpdate tasks remain .bak after reboot + 10 min uptime
Note: This script (v7) is a work in progress - long-term effectiveness is still being monitored.
This issue has been happening more frequently. It reactivated as usual on Saturday, and I turned the update services off again, and then just now on Sunday it did it again.
@themiraculousEC I am still working on it on weekly basis as the 7-day-cycle comes back. It's complex and cant share now. But soon. Actually there is no "more frequently". It's exactly 7-days. Just relax. At some point there will be solution for this.
There is a 'more frequently'. It just happened to me. Yesterday (Saturday), it was due, so I checked it with the bat file to see if the update services were back on. They all were and I turned them off. Today (Sunday), I got the 'update available' pop up and checked update services again. They were all back on again and I had to turn them off again.
I'd like to report that it just happened again today (Wednesday). It was another 'We have an update for you' pop up. The one that goes all the way across the screen.
@themiraculousEC Just for protocol, have you run v7 script even once?
I'm not sure what you mean by v7 script. If you mean the script you posted, I'm not sure how to do that. That's what the comment I made on June 13th meant: I didn't know how to run the script you provided.
When the bug happened the first time, around the same time you posted your first encounter with the bug (May 16), I re-downloaded the most updated bat file. Until two weeks ago, I was only getting the bug once a week like you. It used to happen on Saturdays, but now it's been bothering me on Sundays and Wednesdays.
1.) wputility press (1) 2.) try this .bat below out:
I'm sorry, I'm still very new to running code that doesn't come pre-packaged in its own file. I can't really visualize what you mean. Can you make a short video of you doing what you want me to do? Or maybe even just pictures.
@sonnyxq I'm on desktop (acer nitro 5 gaming laptop, windows 11, fully updated firefox), it's just saying there's no video file or MIME format? Also, now I'm not seeing any of your comments in this thread and I only know you replied via my email. That's so strange.
I've given this deep thought and concluded that patience is needed here.
I'd rather not spend my time on an extensive walkthrough, so my recommendation is:
Either downgrade to 23H2 and stay there, since 25H2 / 24H2 has introduced new protection mechanisms that are quite tricky to work around
Or wait patiently until the program's author or someone in the community (other GitHub author) finds a solution
Additionally, since what I'm doing is quite experimental and modifies the system more heavily than the author's approach, there's usually no way back β a fresh reinstall is typically required. With the .bat author's method, there is a way back. Given that your technical knowledge here seems limited, I'd prefer not to go down that path, as it could cause problems on your side.
That said, I'm still trying to figure out a "minimal set" β a way to achieve this with far fewer modifications.
PS: Would it be possible for you to remove your previous comments as well, so the thread stays clean? I'd really appreciate that.
@sonnyxq I'm currently on 24H2 and I'm still having these problems. I stopped updating before the update that supposedly unmounted your ssd. I have all my files backed up on an external harddrive, too. Let me know when you get that minimal set, I guess.
I don't think deleting our comments is a good idea. The entire point of a thread is to serve as a record for other people who might be having the same problem.
@themiraculousEC
Oh, apologies for the small typo β I actually meant 23H2, since 24H2 and 25H2 both use the same "Germanium" codebase and share the same servicing branch.
Activity
sonnyxq commentedon May 16, 2026
Root Cause β Hypothesis β not final β Updated May 16, 2026
I believe
wputility.batalready handles services correctly viasc config,net stop, andsc failure reset= 0 actions= "".However, several things were missing and have been addressed incrementally:
WaaSMedicSvcruns as a Protected Process Light (PPL) via its kernel plugin (WaaSMedicPS.dll) on Windows 11 25H2. This allows it to silently restore disabled services and recreate scheduled tasks β overridingsc config,net stop, and registry writes entirely. RenamingWaaSMedicPS.dllremoves its kernel-level privileges.UpdateOrchestrator scheduled tasks are not neutralized by
taskUpdatesDisable.wputility.batdisables telemetry tasks (schtasksDisable0-17) but none of these:\Microsoft\Windows\UpdateOrchestrator\Schedule Scan<- 7-day trigger, directly causes reactivation\Microsoft\Windows\UpdateOrchestrator\Schedule Scan Static Task<- fallback scan trigger\Microsoft\Windows\UpdateOrchestrator\USO_UxBroker\Microsoft\Windows\UpdateOrchestrator\Report policies\Microsoft\Windows\UpdateOrchestrator\UUS Failover Task\Microsoft\Windows\UpdateOrchestrator\UIEOrchestrator\Microsoft\Windows\UpdateOrchestrator\StartInstall\Microsoft\Windows\UpdateOrchestrator\Schedule Maintenance Work\Microsoft\Windows\UpdateOrchestrator\Schedule Wake To Work\Microsoft\Windows\UpdateOrchestrator\Schedule Work\Microsoft\Windows\UpdateOrchestrator\Start Oobe Expedite Work\Microsoft\Windows\UpdateOrchestrator\StartOobeAppsScanAfterUpdate\Microsoft\Windows\UpdateOrchestrator\StartOobeAppsScan_LicenseAccepted\Microsoft\Windows\UpdateOrchestrator\StartOobeAppsScan_OobeAppReady\Microsoft\Windows\WaaSMedic\PerformRemediation<- restores all above tasks\Microsoft\Windows\WindowsUpdate\Scheduled Start<- confirmed reactivation vector (April 20, 2026)\Microsoft\Windows\WindowsUpdate\Refresh Group Policy Cache<- confirmed reactivation vector (April 20, 2026)Task Scheduler Registry TaskCache is not cleared. Even after renaming task files, Task Scheduler rebuilds them on next boot from its internal registry cache at:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\UpdateOrchestrator\HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\WindowsUpdate\Both the task files and the corresponding registry keys must be removed together, otherwise Task Scheduler silently recreates the files on every reboot.
\Microsoft\Windows\WindowsUpdate\tasks are not neutralized. These tasks exist outside theUpdateOrchestratorfolder and are not covered by any existing fix. On Windows 11 25H2,Scheduled StartandRefresh Group Policy Cachewere confirmed to trigger a reactivation notification every 7 days - even with all UpdateOrchestrator tasks renamed and all services disabled. They must be treated identically:takeown+file rename+ TaskCache deletion + Deny ACE.UsoSvc,WaaSMedicSvc, andwuauservare not explicitly disabled. Even withWaaSMedicPS.dllrenamed, all three services start on boot via Delayed Auto Start or on-demand SCM triggers.UsoSvcis the direct trigger forMusNotificationUx.exe(the update popup). Both must be explicitly set toStart=4(Disabled) withFailureActionscleared β confirmed effective on Windows 11 25H2 (April 29, 2026).Service registry
Startvalues revert toDEMAND_START (3)after boot. Even after settingStart=4, Windows SCM rewrites its own service config through an internal path that bypasses Registry ACLs. A standardreg addfrom an elevated Administrator shell is insufficient β the write must be performed asSYSTEMvia a Scheduled Task. Additionally,sc sdsetmust be applied toUsoSvcandwuauservto deny Write DAC (WD) for bothSYSTEMandTrustedInstallerat the SCM security descriptor level β confirmed required on Windows 11 25H2 (May 9, 2026).WaaSMedicPS.dllstill existed in WinSxS (component store) and could be reintroduced by servicing. Earlier versions only renamed theSystem32copy. The PPL pluginWaaSMedicPS.dllalso lives under%SystemRoot%\WinSxS\...WaaSMedic...and can be used by servicing/repair routines as a source of truth. The current script additionally enumerates all*WaaSMedicPS.dllmatches under%SystemRoot%\WinSxS(viadir /s /b) and deletes every instance aftertakeown+icacls /grant+del. After this change,dir /s /b "%SystemRoot%\WinSxS\*WaaSMedicPS.dll"returnsFile Not Foundwhile the Windows Update UI remains in the"Something went wrong"state.WaaSMedicPS.dll.bakACL inSystem32still containedNT SERVICE\TrustedInstaller. Even when the DLL only exists as.bak, a future repair routine could still try to restore it as long as TrustedInstaller has write access. The current script also removes anyWaaSMedicPS.dll.bak2β.bak5copies in%SystemRoot%\System32and strips theNT SERVICE\TrustedInstallerACE fromWaaSMedicPS.dll.bak, so TrustedInstaller no longer has a straightforward path to bring it back.themiraculousEC commentedon Jun 14, 2026
Hey, I'm having this problem too. Do you know how to fix it? I tried to make sense of your comment, but its a bit too advanced for me.
themiraculousEC commentedon Jul 5, 2026
This issue has been happening more frequently. It reactivated as usual on Saturday, and I turned the update services off again, and then just now on Sunday it did it again.
themiraculousEC commentedon Jul 6, 2026
There is a 'more frequently'. It just happened to me. Yesterday (Saturday), it was due, so I checked it with the bat file to see if the update services were back on. They all were and I turned them off. Today (Sunday), I got the 'update available' pop up and checked update services again. They were all back on again and I had to turn them off again.
themiraculousEC commentedon Jul 8, 2026
I'd like to report that it just happened again today (Wednesday). It was another 'We have an update for you' pop up. The one that goes all the way across the screen.
themiraculousEC commentedon Jul 21, 2026
I'm not sure what you mean by v7 script. If you mean the script you posted, I'm not sure how to do that. That's what the comment I made on June 13th meant: I didn't know how to run the script you provided.
When the bug happened the first time, around the same time you posted your first encounter with the bug (May 16), I re-downloaded the most updated bat file. Until two weeks ago, I was only getting the bug once a week like you. It used to happen on Saturdays, but now it's been bothering me on Sundays and Wednesdays.
themiraculousEC commentedon Jul 22, 2026
I'm sorry, I'm still very new to running code that doesn't come pre-packaged in its own file. I can't really visualize what you mean. Can you make a short video of you doing what you want me to do? Or maybe even just pictures.
themiraculousEC commentedon Jul 23, 2026
@sonnyxq The video is broken for me, sorry
themiraculousEC commentedon Jul 23, 2026
@sonnyxq I'm on desktop (acer nitro 5 gaming laptop, windows 11, fully updated firefox), it's just saying there's no video file or MIME format? Also, now I'm not seeing any of your comments in this thread and I only know you replied via my email. That's so strange.
sonnyxq commentedon Jul 23, 2026
@themiraculousEC
I've given this deep thought and concluded that patience is needed here.
I'd rather not spend my time on an extensive walkthrough, so my recommendation is:
Additionally, since what I'm doing is quite experimental and modifies the system more heavily than the author's approach, there's usually no way back β a fresh reinstall is typically required. With the .bat author's method, there is a way back. Given that your technical knowledge here seems limited, I'd prefer not to go down that path, as it could cause problems on your side.
That said, I'm still trying to figure out a "minimal set" β a way to achieve this with far fewer modifications.
PS: Would it be possible for you to remove your previous comments as well, so the thread stays clean? I'd really appreciate that.
themiraculousEC commentedon Jul 24, 2026
@sonnyxq I'm currently on 24H2 and I'm still having these problems. I stopped updating before the update that supposedly unmounted your ssd. I have all my files backed up on an external harddrive, too. Let me know when you get that minimal set, I guess.
I don't think deleting our comments is a good idea. The entire point of a thread is to serve as a record for other people who might be having the same problem.
sonnyxq commentedon Jul 24, 2026
@themiraculousEC
Oh, apologies for the small typo β I actually meant 23H2, since 24H2 and 25H2 both use the same "Germanium" codebase and share the same servicing branch.