I wanted to know whether a Windows 11 debloat buys anything you can measure, and whether it quietly breaks Windows Update weeks later. So I took a fresh 24H2 box, counted everything I could before touching it, removed apps with the built-in Appx cmdlets, then ran the most popular community script on top and pushed a pending cumulative update through.
The short version: the box lost 18 provisioned packages, 17 background processes and 1.81 GB of app files, and the October cumulative update installed afterwards without a single error. These notes cover which packages I’d never remove, the Remove-AppxProvisionedPackage flag that decides whether existing accounts keep an app, what Win11Debloat actually does once you read its source, and how to put an app back. I ran all of it in October 2026 on a Windows 11 Enterprise 24H2 VM in my Proxmox lab, and every count below comes from that box.
Deciding what counts as bloat
Bloat is any inbox app you’ll never open that still installs for every new account, updates through the Store and sometimes runs in the background. Everything that installs, updates or protects Windows itself is not bloat, however unused it looks. That line matters because almost every “debloat broke my PC” story I’ve read traces back to a script that removed one of these:
Microsoft.DesktopAppInstaller: winget lives hereMicrosoft.WindowsStoreandMicrosoft.StorePurchaseApp: inbox apps update through themMicrosoft.SecHealthUI: the Windows Security app- the HEVC, AV1, VP9, WebP, HEIF and Raw extensions: Photos and browsers decode with them
Microsoft.MicrosoftEdge.Stable: other apps lean on its WebView runtime- the
wuauserv,UsoSvc,BITSandWaaSMedicSvcservices: they fetch and install updates
That last line is not an app, but a lot of scripts touch those services under a “speed up Windows” banner, and that’s how updates die silently. A box that stops patching also misses fixes that only ship through Windows Update, such as the cumulative updates that carry this year’s Secure Boot certificate changes. Keep everything on the list and you can remove nearly anything else, then get it back later with winget. My own removal list was the twelve consumer apps I’d uninstall on any work machine. Those were Clipchamp, News, Weather, the Xbox app, the Microsoft 365 hub, Solitaire, the new Outlook, Power Automate, To Do, Dev Home, Feedback Hub and the inbox Teams client.
Measuring the box before touching it
Without a baseline, “it feels faster” is all you’ll have afterwards. I wrote a small script that counts provisioned packages (what new accounts get), installed packages across all users, processes, running services, memory in use and the size of C:\Program Files\WindowsApps, which is where Store apps keep their files. Create a folder for it and open a new file in Notepad from an elevated Windows PowerShell window:
New-Item -ItemType Directory C:\lab -Force
notepad C:\lab\measure.ps1Paste the script and save it. Reading the WindowsApps folder needs an elevated session, otherwise that line quietly returns zero.
$ProgressPreference='SilentlyContinue'
$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
$os = Get-CimInstance Win32_OperatingSystem
$c = Get-PSDrive C
$wa = (Get-ChildItem 'C:\Program Files\WindowsApps' -Recurse -File -Force -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum
[pscustomobject]@{
Build = "$($cv.DisplayVersion) $($cv.CurrentBuild).$($cv.UBR) $($cv.EditionID)"
Uptime_min = [int]((Get-Date) - $os.LastBootUpTime).TotalMinutes
Provisioned = (Get-AppxProvisionedPackage -Online).Count
Installed_All = (Get-AppxPackage -AllUsers).Count
Processes = (Get-Process).Count
Services_Running = (Get-Service | Where-Object Status -eq 'Running').Count
RAM_Used_MB = [int](($os.TotalVisibleMemorySize - $os.FreePhysicalMemory) / 1KB)
C_Used_GB = [math]::Round($c.Used / 1GB, 2)
WindowsApps_GB = [math]::Round($wa / 1GB, 2)
} | Format-ListReboot, sign in, and give Windows about ten minutes to finish its first-logon work before you run it. On the boot that created my account, a reading at one minute of uptime showed 157 processes; after a reboot and nine minutes it was 143, so a reading taken too early flatters whatever you do next. Run it the same way each time:
powershell -NoProfile -ExecutionPolicy Bypass -File C:\lab\measure.ps1My box gave this baseline nine minutes after boot, with my account signed in.
Build : 24H2 26100.9457 EnterpriseEval
Uptime_min : 9
Provisioned : 51
Installed_All : 129
Processes : 143
Services_Running : 99
RAM_Used_MB : 2803
C_Used_GB : 29.68
WindowsApps_GB : 4.89Two of those numbers aren’t trustworthy on their own. Memory in use wandered between 2,239 and 2,959 MB across four readings in the same boot, and C_Used_GB grew by 1.4 GB in nine minutes because Windows was downloading updates in the background. The package counts, the process count and the WindowsApps size held steady, so those are the ones I compared. Take the snapshot now if you’re on a VM; I took one in Proxmox before removing anything. My test VM ran on emulated SATA and e1000 hardware, so no VirtIO drivers were in play, and if you’d rather test on bare metal first, a clean install from a bootable Windows 11 USB gives you the same starting point.
Removing provisioned apps with PowerShell
An inbox app exists twice on Windows 11: once as an installed package in each user’s profile, and once as a provisioned package that gets installed into every new profile. Remove only the first and the app comes back for the next account you create. Remove only the second and your existing accounts keep it, which surprised me more than it should have. List what your build provisions first, because the set changes between releases:
Get-AppxProvisionedPackage -Online | Sort-Object DisplayName | ForEach-Object { $_.DisplayName }My 24H2 image (build 26100.9457) returned 51 names. These are the ones a debloat usually targets, cut from that list.
Clipchamp.Clipchamp
Microsoft.BingNews
Microsoft.BingSearch
Microsoft.BingWeather
Microsoft.GamingApp
Microsoft.MicrosoftOfficeHub
Microsoft.MicrosoftSolitaireCollection
Microsoft.MicrosoftStickyNotes
Microsoft.OutlookForWindows
Microsoft.PowerAutomateDesktop
Microsoft.Todos
Microsoft.Windows.DevHome
Microsoft.WindowsAlarms
Microsoft.WindowsFeedbackHub
Microsoft.WindowsSoundRecorder
MicrosoftCorporationII.QuickAssist
MicrosoftWindows.Client.WebExperience
MSTeamsI put my twelve in a script so the list is easy to edit and rerun after a feature update. Create it the same way.
notepad C:\lab\remove-apps.ps1Each pass removes the app from every existing profile and then from the provisioned image, matching on the exact package name so nothing with a similar name gets caught:
$apps = @(
'Clipchamp.Clipchamp'
'Microsoft.BingNews'
'Microsoft.BingWeather'
'Microsoft.GamingApp'
'Microsoft.MicrosoftOfficeHub'
'Microsoft.MicrosoftSolitaireCollection'
'Microsoft.OutlookForWindows'
'Microsoft.PowerAutomateDesktop'
'Microsoft.Todos'
'Microsoft.Windows.DevHome'
'Microsoft.WindowsFeedbackHub'
'MSTeams'
)
foreach ($app in $apps) {
Get-AppxPackage -AllUsers -Name $app | Remove-AppxPackage -AllUsers
Get-AppxProvisionedPackage -Online |
Where-Object DisplayName -eq $app |
Remove-AppxProvisionedPackage -Online -AllUsers | Out-Null
Write-Output "removed $app"
}Use Windows PowerShell 5.1 for this, not PowerShell 7, since the Appx cmdlets only load in 7 through its Windows PowerShell compatibility layer.
powershell -NoProfile -ExecutionPolicy Bypass -File C:\lab\remove-apps.ps1All twelve went in 29 seconds with no red text, on a VM that was not installing anything else at the time:
removed Clipchamp.Clipchamp
removed Microsoft.BingNews
removed Microsoft.BingWeather
removed Microsoft.GamingApp
removed Microsoft.MicrosoftOfficeHub
removed Microsoft.MicrosoftSolitaireCollection
removed Microsoft.OutlookForWindows
removed Microsoft.PowerAutomateDesktop
removed Microsoft.Todos
removed Microsoft.Windows.DevHome
removed Microsoft.WindowsFeedbackHub
removed MSTeamsDid it actually work? “removed” only means the loop got past that name, so check that nothing survived in either place.
$names = 'Clipchamp.Clipchamp','Microsoft.BingNews','Microsoft.BingWeather','Microsoft.GamingApp','Microsoft.MicrosoftOfficeHub','Microsoft.MicrosoftSolitaireCollection','Microsoft.OutlookForWindows','Microsoft.PowerAutomateDesktop','Microsoft.Todos','Microsoft.Windows.DevHome','Microsoft.WindowsFeedbackHub','MSTeams'
"Provisioned: $((Get-AppxProvisionedPackage -Online).Count)"
"Installed (all users): $((Get-AppxPackage -AllUsers).Count)"
"Left behind: $(@(Get-AppxPackage -AllUsers | Where-Object Name -in $names).Count + @(Get-AppxProvisionedPackage -Online | Where-Object DisplayName -in $names).Count)"Provisioned packages fell from 51 to 39 and installed packages from 129 to 117, twelve each, with nothing left behind:
Provisioned: 39
Installed (all users): 117
Left behind: 0That was the only check that mattered before going on, because a removal that silently fails would leave me comparing “after” numbers against apps that were still there.
Why -AllUsers on Remove-AppxProvisionedPackage matters
Microsoft’s page for Remove-AppxProvisionedPackage says the cmdlet stops an app from installing for new accounts and does not remove it from existing ones. Plenty of debloat snippets online call it without -AllUsers. I first tried that on Sound Recorder and repeated it later on Phone Link, which is the capture below:
Get-AppxProvisionedPackage -Online | Where-Object DisplayName -eq 'Microsoft.YourPhone' | Remove-AppxProvisionedPackage -Online
Get-AppxPackage -AllUsers -Name Microsoft.YourPhone | Format-List Name,Version,PackageUserInformationThe provisioned copy went, but the app was still installed for both accounts on the box, mine and a second local account called sam. The third entry is a newer build that Windows had staged for SYSTEM while updates were running:
Online : True
RestartNeeded : False
Name : Microsoft.YourPhone
Version : 0.26072.255.0
PackageUserInformation : {S-1-5-21-2947570338-2649883975-988964596-1000 [sam]: Installed, S-1-5-21-2947570338-2649883975-988964596-1002 [philip]: Installed}
Name : Microsoft.YourPhone
Version : 0.26082.121.0
PackageUserInformation : {S-1-5-18 [NT AUTHORITY\SYSTEM]: Staged}Then I ran the same thing on the Camera app with -AllUsers added, and Get-AppxPackage -AllUsers -Name Microsoft.WindowsCamera came back empty: gone from the image and from both profiles in one call. So on my 24H2 box, for Camera, the switch did what the old snippets needed two cmdlets for. Microsoft’s page doesn’t promise that (it only says the switch applies the command to all users), so I still keep the Remove-AppxPackage -AllUsers line in my script, because it costs nothing and it also catches apps that a user installed from the Store and that were never provisioned.
Reading Win11Debloat before running it
The script most people mean when they search for a Windows 11 debloat script is Raphire’s Win11Debloat, and its quick-start line pipes a web page straight into PowerShell. I will not run a remote script I haven’t read on a machine I care about, so I downloaded the latest tagged release instead. This picks up whatever the newest tag is when you run it:
cd C:\lab
$tag = (Invoke-RestMethod https://api.github.com/repos/Raphire/Win11Debloat/releases/latest).tag_name
$tag
Invoke-WebRequest "https://github.com/Raphire/Win11Debloat/archive/refs/tags/$tag.zip" -OutFile "Win11Debloat-$tag.zip"
Expand-Archive "Win11Debloat-$tag.zip" -DestinationPath . -ForceIt printed 2026.08.24, and the archive unpacked into 330 PowerShell, registry and JSON files outside the test suite. Nobody reads all of that line by line, so I searched it for the things that would break updates. First, any PowerShell that names an update service or changes a service’s startup type:
cd "C:\lab\Win11Debloat-$tag"
Get-ChildItem -Recurse -File -Include *.ps1 -Exclude *.Tests.ps1 | Select-String -Pattern 'wuauserv|UsoSvc|WaaSMedicSvc|BITS|Set-Service|Stop-Service|sc\.exe'That returned nothing at all. Most of the script’s tweaks are .reg files, though, so the second search goes through those for update policy, Delivery Optimization and service keys:
Get-ChildItem .\Regfiles -File | Select-String -Pattern 'WindowsUpdate|DeliveryOptimization|CurrentControlSet\\Services' | Select-Object Filename, Line | Format-Table -AutoSizeFour files matched, and I opened each one.
Filename Line
-------- ----
Disable_AI_Service_Auto_Start.reg [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WSAIFabricSvc]
Disable_Delivery_Optimization.reg [HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\DeliveryOptimization\Settings]
Disable_Update_ASAP.reg [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings]
Prevent_Auto_Reboot.reg [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]None of them stops updates. The first sets the Windows AI service to manual start, which is part of the defaults. The other three only change when and from where updates arrive (no peer-to-peer downloads, no early non-security updates, no forced reboot while you’re signed in), and each sits behind its own opt-in switch that the defaults don’t turn on. Then I checked what the default app selection would touch:
$apps = (Get-Content .\Config\Apps.json -Raw | ConvertFrom-Json).Apps
"{0} apps listed, {1} selected by default" -f $apps.Count, @($apps | Where-Object SelectedByDefault).Count
$apps | Where-Object { $_.AppId -match 'WindowsStore|DesktopAppInstaller|SecHealthUI|Photos|WindowsTerminal|Edge' } | Format-Table AppId, SelectedByDefault -AutoSizeThe Store, Edge, Photos and Terminal are listed but unticked, and App Installer and Windows Security aren’t in the catalog at all, so the defaults can’t take them:
141 apps listed, 84 selected by default
AppId SelectedByDefault
----- -----------------
AdobeSystemsIncorporated.AdobePhotoshopExpress True
PicsArt-PhotoStudio True
{Microsoft.Edge, XPFFTQ037JWMHS} False
Microsoft.Windows.Photos False
Microsoft.WindowsStore False
Microsoft.WindowsTerminal FalseHere are the same three checks in one terminal, the way they looked on the box.
One more thing I read was the removal function in Scripts\AppRemoval\Remove-SelectedApps.ps1. It wraps each name in wildcards ('*' + $app + '*') and, for the all-users target, calls Remove-AppxPackage -AllUsers followed by Remove-ProvisionedAppxPackage -Online -AllUsers, the same pair my script uses. The wildcard is looser than my exact match, so if you add your own names to Apps.json, make them specific.
Running Win11Debloat with its defaults
Run it from your own account in an elevated Windows PowerShell 5.1 window. The privacy and taskbar tweaks land in the current user’s registry hive, so launching it as SYSTEM or from another admin account applies them to the wrong profile. The release notes also say it refuses to start under PowerShell 7. I ran the defaults silently, asked for a restore point, and pointed the log at my lab folder:
Set-ExecutionPolicy Bypass -Scope Process -Force
New-Item -ItemType Directory C:\lab\wdlog -Force
cd "C:\lab\Win11Debloat-$tag"
.\Win11Debloat.ps1 -RunDefaults -Silent -CreateRestorePoint -LogPath C:\lab\wdlogIt took 153 seconds. Below is the console output minus the 90 “Removing” lines. Note that it saved a registry backup before changing anything, which is what makes its own undo possible:
Win11Debloat Script - Default Mode (User: philip)
-------------------------------------------------------------------------------------------
> Creating registry backup...
Backup successfully created: C:\lab\Win11Debloat-2026.08.24\Backups\Win11Debloat-RegistryBackup-20261031_004641.json
> Creating a system restore point...
System restore point created successfully
> Removing selected apps for all users...
84 apps selected for removal
> Disabling telemetry and diagnostic data collection...
The operation completed successfully.
> Disabling telemetry scheduled tasks...
Scheduled Task \Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser not found
Disabled Scheduled Task: \Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser Exp
Scheduled Task \Microsoft\Windows\Application Experience\ProgramDataUpdater not found
Disabled Scheduled Task: \Microsoft\Windows\Application Experience\StartupAppTask
Disabled Scheduled Task: \Microsoft\Windows\Customer Experience Improvement Program\Consolidator
Disabled Scheduled Task: \Microsoft\Windows\Customer Experience Improvement Program\UsbCeip
Disabled Scheduled Task: \Microsoft\Windows\DiskDiagnostic\Microsoft-Windows-DiskDiagnosticDataCollector
Disabled Scheduled Task: \Microsoft\Windows\Autochk\Proxy
> Disabling tips, tricks, suggestions and ads throughout Windows...
The operation completed successfully.
> Disabling ads, suggestions and the MSN news feed in Microsoft Edge...
The operation completed successfully.
> Disabling tips & tricks on the lock screen...
The operation completed successfully.
> Disabling Bing web search & Copilot integration in Windows search...
The operation completed successfully.
> Disabling Microsoft Store search suggestions for user philip...
Disabled Microsoft Store search suggestions for user philip
> Disabling Microsoft Copilot...
The operation completed successfully.
> Disabling Windows Recall...
The operation completed successfully.
> Disabling Click to Do...
The operation completed successfully.
> Preventing AI service from starting automatically...
The operation completed successfully.
> Disabling widgets on the taskbar & lock screen...
> Enabling file extensions for known file types...
The operation completed successfully.
> Disabling network connectivity during Modern Standby...
The operation completed successfully.
> Attempting to restart the Windows Explorer process to apply all changes...
Restarting the Windows Explorer process... (This may cause your screen to flicker)
Script completed! Please check above for any errors.“84 apps selected” doesn’t mean 84 removals, and Sound Recorder’s per-user copies went here too, since I’d only taken its provisioned copy in the test above. Most of the catalog (Candy Crush, TikTok, Disney+ and friends) wasn’t on my Enterprise image in the first place. On my box it found five provisioned packages my own list hadn’t covered: Bing Search, Sticky Notes, Clock, Quick Assist and the Windows Web Experience Pack that drives Widgets. I’d have kept Quick Assist on a family PC, since it is how you help someone remotely without installing anything. Set its SelectedByDefault to false in Apps.json before running if you want it too.
The Start menu shows the difference better than the counts do. This is my account before either pass, with Outlook, the Microsoft 365 Copilot hub and Clock pinned, plus the weather widget and a 365 icon on the taskbar:
- 1Outlook
- 2Microsoft 365 Copilot
- 3Clock
- 4weather widget
- Outlook: the new Outlook, gone after my manual pass
- Microsoft 365 Copilot: the old Office hub under a new name, also mine
- Clock: taken by Win11Debloat’s defaults
- weather widget: went with the Web Experience Pack
And after both passes and a reboot, the pins for removed apps are gone, as are the widget and the extra taskbar icon:
“Get Started” still sits in Recommended. Win11Debloat’s own catalog notes that Get Started can’t be uninstalled on Windows 11, and turning off the Recommended section is a separate opt-in switch.
Measuring again and running Windows Update
I rebooted, signed in, waited the same nine-ish minutes and ran measure.ps1 again.
Build : 24H2 26100.9457 EnterpriseEval
Uptime_min : 8
Provisioned : 33
Installed_All : 108
Processes : 126
Services_Running : 92
RAM_Used_MB : 2036
C_Used_GB : 28.6
WindowsApps_GB : 3.08So what did all that buy? Side by side, with the earlier caveat about memory still applying.
| Measure (about 9 min after boot) | Before | After | Change |
|---|---|---|---|
| Provisioned packages | 51 | 33 | -18 |
| Installed packages, all users | 129 | 108 | -21 |
| Processes | 143 | 126 | -17 |
| Running services | 99 | 92 | -7 |
| WindowsApps folder | 4.89 GB | 3.08 GB | -1.81 GB |
| Memory in use | 2,803 MB | 2,036 MB | noisy, see below |
The package and disk numbers are solid, and the process count fell by 17 on two readings in a row. I didn’t save a process list before the removal, so I can’t tell you which 17 they were, only that Widgets and the 365 hub no longer appear on the taskbar. I wouldn’t quote the memory figure as a saving: the “before” readings spread over 720 MB on their own, so the honest claim is “several hundred MB less, on an idle 8 GB VM”. On a laptop you’ll notice the quieter Start menu and taskbar well before you notice that.
Next I checked the services that actually deliver updates. Right after the script, BITS read stopped and manual where the baseline had it running and automatic. Had the debloat touched it after all? The System log records every start type change as event 7040, so I asked it who did it and when.
Get-Service wuauserv,BITS,UsoSvc,WaaSMedicSvc | Format-Table Name,Status,StartType
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7040} -MaxEvents 15 | Where-Object Message -match 'Background Intelligent' | Format-List TimeCreated,MessageBy the time I ran it again during the update test, BITS was back to automatic, and the log showed why it had moved at all:
Name Status StartType
---- ------ ---------
BITS Running Automatic
UsoSvc Running Automatic
WaaSMedicSvc Stopped Manual
wuauserv Running Manual
TimeCreated : 10/31/2026 1:56:05 AM
Message : The start type of the Background Intelligent Transfer Service service was changed from demand start to auto start.
TimeCreated : 10/31/2026 1:44:04 AM
Message : The start type of the Background Intelligent Transfer Service service was changed from auto start to demand start.
TimeCreated : 10/31/2026 1:39:59 AM
Message : The start type of the Background Intelligent Transfer Service service was changed from demand start to auto start.Every one of those entries came from SYSTEM, and the alternation runs on a four and twelve minute rhythm. Scrolling further back, the same flip-flop appears on 19 September, weeks before this VM was cloned and before any debloat existed. The change at 00:45:24 that worried me was one more tick of that cycle, a minute before Win11Debloat even started, and its source has no BITS reference anyway. So a Manual BITS on a snapshot of Get-Service proves nothing; check event 7040 before you blame a script, and compare against a box that was never debloated.
Services that look right still don’t prove updates work, so the real test was to install whatever Windows Update had waiting. I used the PSWindowsUpdate module from the PowerShell Gallery because it prints a result per update and makes the run easy to time. Save this as C:\lab\wu.ps1 with Notepad, the same way as the other two scripts.
$ProgressPreference = 'SilentlyContinue'
Start-Transcript C:\lab\wu.log -Force
if (-not (Get-Module -ListAvailable PSWindowsUpdate)) {
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force | Out-Null
Install-Module PSWindowsUpdate -Force -Scope AllUsers
}
Import-Module PSWindowsUpdate
$t = Measure-Command { $u = Get-WindowsUpdate -MicrosoftUpdate }
"SCAN seconds: $([int]$t.TotalSeconds)"
$u | Format-Table KB, Size, Title -AutoSize | Out-String -Width 220
$t = Measure-Command { $r = Install-WindowsUpdate -MicrosoftUpdate -AcceptAll -IgnoreReboot }
"INSTALL seconds: $([int]$t.TotalSeconds)"
$r | Format-Table Result, KB, Size, Title -AutoSize | Out-String -Width 220
"REBOOT required: $(Get-WURebootStatus -Silent)"
Stop-TranscriptStart it from an elevated prompt. I ran mine as SYSTEM through the Proxmox guest agent so it could keep going unattended, which is not quite the same session as yours, but the module and the update agent it drives are the same. It’s a script module, so the default execution policy refuses to load it unless you bypass it for this process.
powershell -NoProfile -ExecutionPolicy Bypass -File C:\lab\wu.ps1The scan took 210 seconds and found four updates, including the October cumulative update that moves 24H2 to build 26100.9711. Installing them took 3,410 seconds, close to an hour, on a VM with four cores and SATA emulation. Every row came back as installed, and the transcript ended like this:
INSTALL seconds: 3410
Result KB Size Title
------ -- ---- -----
Installed KB890830 84MB Windows Malicious Software Removal Tool x64 - v5.146 (KB890830)
Installed KB5007651 22MB Update for Windows Security platform - KB5007651 (Version 10.0.29680.1000) - Current Channel (Broad)
Installed KB5127648 90GB 2026-10 Security Update (KB5127648) (26100.9711)
Installed KB5127690 185MB 2026-10 .NET Framework Security Update (KB5127690)
REBOOT required: TrueIgnore the 90GB in the Size column; that’s what the module reported for the cumulative update, and the download folder held 1.18 GB at the time. PSWindowsUpdate also printed the same four rows three times over, which I’ve trimmed. While the install ran, the Store side of Windows Update pushed 18 app updates of its own, including App Installer, the Store itself, Terminal, Photos and the codec extensions. I half expected one of those to drag a removed app back in. None did: I checked all 19 names the two passes had taken, and every one stayed gone, installed or provisioned.
After a reboot the cumulative update ran its “You’re 18% there” screen, went through a second firmware restart and came back in about seven minutes. These checks confirm it actually committed, rather than rolling back on the restart, and that nothing else is waiting:
$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
"Build: $($cv.DisplayVersion) $($cv.CurrentBuild).$($cv.UBR)"
"WU client failures (Id 20) since 00:00: " + @(Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WindowsUpdateClient'; Id=20; StartTime=(Get-Date).Date} -ErrorAction SilentlyContinue).Count
"WU client successes (Id 19) since 00:00: " + @(Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WindowsUpdateClient'; Id=19; StartTime=(Get-Date).Date} -ErrorAction SilentlyContinue).CountThe build number moved, and the Windows Update client logged no failures all day against 26 successes, which counts the Store app updates too:
Build: 24H2 26100.9711
WU client failures (Id 20) since 00:00: 0
WU client successes (Id 19) since 00:00: 26A second Get-WindowsUpdate -MicrosoftUpdate from a Bypass prompt finished in 30 seconds and returned nothing pending. That’s the result I was after: the manual removal plus Win11Debloat’s defaults left a 24H2 box that scans, downloads, installs and reboots into a new cumulative update without a single failure. I didn’t run the same cycle on an untouched clone for comparison, and it’s one update cycle on one VM, though, so I can’t promise the same for a feature update to the next Windows 11 release.
Undoing a removal
Most removed inbox apps come straight back from the Store, and winget can fetch them for you, which is one more reason never to remove App Installer. I’d removed Camera during the -AllUsers test, so that’s the one I reinstalled, from my own account rather than an admin shell since Store installs are per user:
winget install --id 9WZDNCRFJBBG --source msstore --accept-package-agreements --accept-source-agreementsIt took 20 seconds, and Get-AppxPackage Microsoft.WindowsCamera showed version 2026.2608.1.0 afterwards. The install output is below.
Found Windows Camera [9WZDNCRFJBBG] Version Unknown
This package is provided through Microsoft Store. WinGet may need to acquire the package from Microsoft Store on behalf of the current user.
Agreements for Windows Camera [9WZDNCRFJBBG] Version Unknown
Version: Unknown
Publisher: Microsoft Corporation
Starting package install...
Successfully installedFind any other app’s Store ID with winget search "app name" --source msstore, and my winget guide covers the rest of the client. Two catches apply. A Store reinstall comes back for your account only, not as a provisioned package for future users. And on a managed fleet, Microsoft’s policy-based in-box app removal is the supported route (Enterprise and Education on 24H2 or newer, set through Intune or Group Policy). Apps on its list stay blocked from reinstalling until the admin takes them off it.
For the tweaks rather than the apps, you have three ways back, from smallest to biggest.
- Win11Debloat’s GUI: Options, Restore backup, Restore Registry Backup, pick the JSON in its
Backupsfolder, confirm, restart - roll back to “Restore point created by Win11Debloat”, if it exists
- on a VM, revert the snapshot you took before the baseline
I only exercised the first kind of undo here, the winget reinstall. Rolling back the restore point or the snapshot would have thrown away the update test, so I left both untouched, and I can’t tell you from this run how cleanly the registry restore puts every tweak back. Take your own snapshot or restore point either way, because Win11Debloat’s backup covers settings, not the apps it removed. Its -CreateRestorePoint switch also skips creating one when a restore point from the last 24 hours already exists, so look for it in System Restore before you need it. And the registry backup lives inside the extracted script folder, so deleting that folder deletes your only copy.
What I still don’t know
One clean cumulative update on one VM settles the question I started with, but it leaves a few I couldn’t answer from this lab:
- a feature update to the next release: only a 24H2 image was available
- Home and Pro images: mine was Enterprise, without the Candy Crush tier of apps
- which 17 processes went: I never saved a process list before
- the registry restore: untested, for the reason above
Would I run the script on my own laptop? Yes, but only after the manual pass, with Quick Assist unticked, and with a restore point I’d actually checked was there. If you manage a fleet of Enterprise or Education machines, skip the script and use the policy-based removal Microsoft supports instead, since it’s one setting in Intune or Group Policy rather than a script run on every box. Pro fleets don’t get that option and are back to a reviewed script like mine.
