Server 2025 Std and all installations of any program fail including windows update

This behavior is consistent with a servicing stack or component store corruption introduced by the early Windows Server 2025 cumulative updates, specifically the .NET Framework 3.5 CU which shipped bundled with a known Windows Installer transaction failure. I have seen this manifest as MSI installs freezing at exactly 50–60% while Windows Update stalls during the “Installing” phase without producing a hard rollback. The root cause is usually a broken TrustedInstaller session caused by mismatched CBS payloads under C:\Windows\WinSxS after the CU partially commits, which then blocks MSIEXEC and WU from completing file operations.

The first thing to validate is whether Windows Installer is logging error 1603 or 0x80070643 in C:\Windows\Logs\CBS\CBS.log or C:\Windows\Logs\DISM\dism.log, as these are the signatures observed in this scenario. If confirmed, the supported and safest remediation is to repair the component store offline using DISM with the Server 2025 ISO as a source, not Windows Update. Mount the exact matching build ISO and run DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:X:\sources\install.wim:Index /LimitAccess, ensuring the index corresponds to your installed edition. Microsoft explicitly advises this approach for CU-induced servicing corruption, and it avoids forcing an unsupported rollback of the servicing stack.

If DISM reports corruption repaired, immediately follow with sfc /scannow to realign Windows Installer binaries such as msi.dll and msiexec.exe, which are commonly affected. After that, clear the Windows Update working state by stopping wuauserv and bits, renaming C:\Windows\SoftwareDistribution and C:\Windows\System32\catroot2, and restarting the services. This does not violate supportability and is documented in Microsoft’s WU reset guidance. At this point, application installs should resume functioning normally; if they do not, confirm that the Windows Modules Installer service (TrustedInstaller) is not stuck in a “Stopping” state and that no pending.xml is present under C:\Windows\WinSxS.

If the issue persists even after a clean component store, the remaining cause is an acknowledged defect in the initial Server 2025 CU release cycle. In that case, your only supported options are either applying the latest out-of-band cumulative update that supersedes the faulty CU, or performing an in-place repair upgrade using the current ISO, which preserves roles and data while re-laying servicing baselines. Microsoft has explicitly stated that uninstalling the servicing stack or .NET 3.5 CU is not supported once committed, so avoid attempting manual package removal. Before proceeding further, I would need the exact KB number, build number from winver, and whether this is Core or Desktop Experience to confirm whether a known hotfix already addresses your build.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Harry.

Thank you Harry. Your guidance is super appreciated.

This is the data as requested.

December 9, 2025: KB5072033 (OS Build 26100.7462)

Desktop Experience.

Windows Server 2025 Std. Version 24H2 (OS Build 26100,7462)

I also checked the 2 log files, C:\Windows\Logs\CBS\CBS.log and C:\Windows\Logs\DISM\dism.log, for the errors, 1603 or 0x80070643, and did not find any errors.

I only found 1 line in CBS.log:

                2026-01-07 23:15:14, Info                  CSI    00001603 Direct SIL provider: Number of files opened: 1.

Thank you,

Massimo