ntoskrnl.exe and build version not getting updated after applying KB5078740 on server 2025

Hi,

The expected OS build after installing KB5078740 is 10.0.26100.32522, not 10.0.21600.32522. Microsoft lists KB5078740 as the March 10, 2026 cumulative update for Windows Server 2025, bringing the server to OS Build 26100.32522.

If ntoskrnl.exe and winver still show 26100.4652, the cumulative update payload was not fully committed, even if the KB appears in the installed-update history. First, make sure the server has completed a full restart rather than only shutting down or restarting individual services.

You can check the actual build using:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, OsHardwareAbstractionLayer Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' | Select-Object ProductName, CurrentBuild, CurrentBuildNumber, UBR, DisplayVersion (Get-Item "$env:SystemRoot\System32\ntoskrnl.exe").VersionInfo | Select-Object FileVersion, ProductVersion

The CurrentBuild value should be 26100 and UBR should be 32522.

Next, check the real servicing state of the package:

dism /online /get-packages /format:table | findstr 5078740

If the package is shown as Install Pending, restart the server again and verify that there are no pending-reboot conditions. If it is shown as installed but the build remains unchanged, repair the component store:

DISM /Online /Cleanup-Image /StartComponentCleanup DISM /Online /Cleanup-Image /RestoreHealth sfc /scannow

Restart the server afterwards and install the latest Windows Server 2025 cumulative update again. Because cumulative updates supersede previous updates, it is generally better to install the latest available update rather than trying to reinstall only KB5078740.

Since this server was upgraded from Windows Server 2022, I would also verify that the machine is booting from the correct Windows Server 2025 installation and system partition:

bcdedit /enum

Also confirm the running operating-system path:

$env:SystemRoot (Get-CimInstance Win32_OperatingSystem).WindowsDirectory

If Qualys is checking ntoskrnl.exe and the running file is still version 26100.4652, this is probably not just a Qualys false positive. It indicates that the updated kernel was not applied to the active Windows installation.

The CBS log should show why the update was not committed:

Select-String -Path C:\Windows\Logs\CBS\CBS.log ` -Pattern '5078740','failed','error','corrupt','pending' | Select-Object -Last 100

I would compare the DISM package state, registry UBR, winver, and the active boot entry. Those results should clarify whether this is a servicing failure, a pending reboot, or the server booting from an older installation after the in-place upgrade.