Windows Update broken after system/debloat tooling: TrustedInstaller service ImagePath hijacked to encoded PowerShell command

### I have read the known issues - [x] Yes, I did ### Version of WinUtil latest stable ### What part of WinUtil are you having issues with? None ### Provide a clear and concise description of the issue. SUMMARY: After using Windows cleanup/debloat/privacy tools, Windows Update stopped installing updates. Bitdefender started blocking "sc.exe" and "cmd.exe" as malware when Windows tried to start TrustedInstaller. At first it looked like sc.exe was infected, but sc.exe was valid Microsoft-signed. The real problem was that the TrustedInstaller service configuration had been modified: its ImagePath was no longer the real TrustedInstaller executable, but a cmd.exe /c PowerShell.exe -encodedcommand ... payload. Because of that, every attempt to start TrustedInstaller caused the antivirus to block the chain, and Windows Update could not complete. TOOLS / CONTEXT: Possible involved tools or scripts to audit: - WinUtil / Windows utility debloat scripts - O&O ShutUp10 / ShutUp10++ - RemoveWindowsAI / Windows AI removal scripts - Any GitHub-hosted Windows debloat/privacy/removal script - Any script that touches Windows Update, Windows Modules Installer, TrustedInstaller, services, or protected system components I am not claiming which specific tool caused it. I am reporting the exact failure mode so maintainers can check whether their scripts modify TrustedInstaller, Service Control Manager entries, Windows Update services, or service ACLs. SYMPTOMS: - Windows Update did not install updates anymore. - Bitdefender notification: "2 applications have been blocked" - Blocked chain showed: C:\Windows\System32\sc.exe C:\Windows\System32\cmd.exe Command line parameters: "C:\Windows\System32\sc.exe" start TrustedInstaller - Bitdefender quarantine was empty, so it was likely a behavioral block, not a quarantined file. - TrustedInstaller service appeared stopped, which by itself is normal. - DistributedCOM 10005 errors appeared repeatedly with error %%1053. - Windows Update only succeeded again after repairing TrustedInstaller's service ImagePath. INITIAL CHECKS: 1. Verified sc.exe was the real Microsoft binary: Get-AuthenticodeSignature C:\Windows\System32\sc.exe Result: Status: Valid Path: C:\Windows\System32\sc.exe 2. Checked TrustedInstaller service state: sc.exe query TrustedInstaller Result was STOPPED, which is normally fine because TrustedInstaller is demand-start. 3. Checked key Windows Update related services: Get-CimInstance Win32_Service -Filter "Name='TrustedInstaller' or Name='wuauserv' or Name='BITS' or Name='CryptSvc' or Name='msiserver'" | Select-Object Name, State, StartMode, PathName BAD RESULT FOUND: TrustedInstaller had this PathName: cmd.exe /c PowerShell.exe -encodedcommand ... This is NOT normal. EXPECTED TRUSTEDINSTALLER PATH: C:\Windows\servicing\TrustedInstaller.exe or, in registry form: %SystemRoot%\servicing\TrustedInstaller.exe WHY BITDEFENDER BLOCKED IT: Bitdefender was not necessarily saying that sc.exe itself was malware. sc.exe was valid. It was blocking the behavior chain because starting TrustedInstaller would actually launch the hijacked command: cmd.exe /c PowerShell.exe -encodedcommand ... That explains why Windows Update was failing: Windows Update needs Windows Modules Installer / TrustedInstaller. When Windows tried to start it, the antivirus blocked the hijacked command. ONLINE REPAIR ATTEMPT: Tried to repair ImagePath from an elevated PowerShell: reg.exe add "HKLM\SYSTEM\CurrentControlSet\Services\TrustedInstaller" /v ImagePath /t REG_EXPAND_SZ /d "%SystemRoot%\servicing\TrustedInstaller.exe" /f This failed with: Accesso negato Access denied That is expected because TrustedInstaller service registry keys can be protected even from admin. WORKING FIX USED: Repaired the SYSTEM registry hive offline from Windows Recovery Environment / WinRE. Steps used: 1. Booted into recovery: Start menu -> Power -> hold Shift -> Restart Troubleshoot -> Advanced options -> Command Prompt Alternative from admin PowerShell: shutdown /r /o /t 0 2. Confirmed the Windows partition: bcdedit | findstr /i "osdevice" In this case Windows was on C:. 3. Verified files existed: dir C:\Windows\servicing\TrustedInstaller.exe dir C:\Windows\System32\Config\SYSTEM 4. Loaded the offline SYSTEM hive: reg load HKLM\FIXSYS C:\Windows\System32\Config\SYSTEM 5. Checked TrustedInstaller service control sets: reg query HKLM\FIXSYS\ControlSet001\Services\TrustedInstaller reg query HKLM\FIXSYS\ControlSet002\Services\TrustedInstaller In this case ControlSet001 existed and ControlSet002 did not. 6. Repaired TrustedInstaller in ControlSet001: reg add HKLM\FIXSYS\ControlSet001\Services\TrustedInstaller /v ImagePath /t REG_EXPAND_SZ /d C:\Windows\servicing\TrustedInstaller.exe /f reg add HKLM\FIXSYS\ControlSet001\Services\TrustedInstaller /v Start /t REG_DWORD /d 3 /f reg add HKLM\FIXSYS\ControlSet001\Services\TrustedInstaller /v Type /t REG_DWORD /d 16 /f reg add HKLM\FIXSYS\ControlSet001\Services\TrustedInstaller /v ObjectName /t REG_SZ /d LocalSystem /f 7. Verified ImagePath: reg query HKLM\FIXSYS\ControlSet001\Services\TrustedInstaller /v ImagePath Expected: ImagePath REG_EXPAND_SZ C:\Windows\servicing\TrustedInstaller.exe 8. Unloaded hive: reg unload HKLM\FIXSYS 9. Rebooted: wpeutil reboot RESULT: After reboot, Windows Update started installing updates again immediately. The repair worked. POST-FIX CHECKS TO RUN: After booting back into Windows: 1. Check TrustedInstaller path: Get-CimInstance Win32_Service -Filter "Name='TrustedInstaller'" | Select-Object Name, State, StartMode, PathName Expected: TrustedInstaller Stopped or Running Manual C:\Windows\servicing\TrustedInstaller.exe 2. Check file signature: Get-AuthenticodeSignature C:\Windows\servicing\TrustedInstaller.exe Expected: Status: Valid 3. Repair Windows component store and system files: DISM /Online /Cleanup-Image /RestoreHealth sfc /scannow 4. Search for other hijacked services: Get-CimInstance Win32_Service | Where-Object { $_.PathName -match 'encodedcommand|powershell|cmd\.exe|wscript|cscript|mshta|AppData|Temp' } | Select-Object Name, State, StartMode, PathName IMPORTANT WARNING: Do NOT whitelist cmd.exe or powershell.exe globally in the antivirus. That would hide the actual problem. In this case the antivirus was correct to block the behavior because TrustedInstaller had been hijacked to launch an encoded PowerShell command. WHAT MAINTAINERS SHOULD CHECK: Please audit any code that: - Disables, modifies, restarts, or changes ACLs for TrustedInstaller - Modifies HKLM\SYSTEM\CurrentControlSet\Services\TrustedInstaller - Changes ImagePath for any Windows service - Uses sc.exe config, reg add, Set-Service, PowerShell encoded commands, or service-tampering methods - Disables Windows Update, Windows Modules Installer, BITS, CryptSvc, msiserver, WaaSMedicSvc, UsoSvc, or related services - Runs as SYSTEM / TrustedInstaller / elevated token - Restores or patches Windows components after removing AI/Copilot features The broken value was: TrustedInstaller PathName = cmd.exe /c PowerShell.exe -encodedcommand ... The correct value is: TrustedInstaller PathName = C:\Windows\servicing\TrustedInstaller.exe CREDIT / TROUBLESHOOTING METHOD: This was diagnosed live with ChatGPT by checking: - antivirus alert chain - Microsoft signature status of sc.exe - service state - Win32_Service PathName - registry protection / access denied - offline registry hive repair through WinRE Final outcome: Windows Update was broken because TrustedInstaller's ImagePath had been hijacked. Restoring the service path offline fixed Windows Update. ### List the tweaks you applied before the issue occurred. _No response_ ### Paste the full error output (if available) or Screenshot or Video. _No response_