.NET Framework DLL Version Not Updated After KB on Windows 11 24H2

Why This Is Happening

I've seen this exact scenario on dozens of enterprise machines running Windows 11 24H2. You install the latest cumulative update or standalone KB for .NET Framework 2.0/3.5, Windows Update reports success, you open File Explorer, right-click on mscorwks.dll or mscoree.dll inside C:\Windows\Microsoft.NET\Framework\v2.0.50727\, check Properties → Details, and it still says 2.0.50727.9157. The KB should have bumped that to a newer patch version , something like 2.0.50727.9168 or higher , but the file on disk disagrees. I know that's deeply unsettling, especially if you're validating a patched image for a compliance scan or a software vendor is screaming at you because their app won't launch.

The root cause is almost always one of three things. First, Windows Servicing, specifically the Component-Based Servicing (CBS) stack, uses a two-phase commit model. During phase one, the new file is staged into the WinSxS component store at C:\Windows\WinSxS. Phase two hard-links (or copies, in some configurations) that staged file into the runtime directory. If the machine hasn't fully rebooted since the KB landed, or if a prior pending file rename operation from an unrelated patch is clogging the queue, phase two never fires. The KB shows as installed in Windows Update history, the component store has the right file, but the directory you're checking still has the old one.

Second, Windows 11 24H2 ships .NET Framework 3.5 as an optional feature, meaning the runtime binaries are maintained through the Features on Demand (FOD) pipeline as well as the standard cumulative update pipeline. When these two servicing channels fall out of sync, which happens more often than Microsoft's documentation admits, the FOD layer can shadow the cumulative update's version, effectively winning a silent version conflict in favor of the older file.

Third, and this is the sneaky one I see in enterprise environments: the update was applied to a machine that was domain-joined with Windows Defender Application Control (WDAC) or a third-party security tool holding a file lock on the .NET runtime DLLs. CBS logs the update as successful because it staged the file, but the hard-link step silently failed because the target file was locked. No error dialog. No failed KB entry in Windows Update. Just a stale DLL sitting there.

Microsoft's error messages aren't helpful here at all. Windows Update says "Successfully installed" and gives you nothing else to go on. The Event Log entries under Application and Services Logs → Microsoft → Windows → Servicing are buried and require you to know exactly where to look. That's exactly what this guide covers. Browse all Microsoft fix guides →

The Quick Fix, Try This First

Before you go deep on DISM and registry digs, do this. It resolves about 60% of cases I see, and it takes two minutes.

Open an elevated command prompt, press Win + X, then choose Terminal (Admin) or Command Prompt (Admin). Run the following command:

shutdown /r /t 0

Yes, a full reboot. Not a fast startup shutdown (which is not the same thing). A proper restart. Fast Startup, which is enabled by default in Windows 11, doesn't fully flush the kernel session, it hibernates the kernel to disk. Pending file rename operations in the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations only execute during a genuine cold-start kernel load. Fast Startup bypasses that entirely.

After the machine comes back up, check the DLL version again. Navigate to C:\Windows\Microsoft.NET\Framework\v2.0.50727\, right-click mscorwks.dll, go to Properties → Details, and look at the File version field. If it's now showing a version higher than 2.0.50727.9157, you're done. Move on with your day.

If the version still hasn't changed, run this from an elevated PowerShell window before doing the reboot, to check whether pending rename operations actually exist:

$pending = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager").PendingFileRenameOperations
if ($pending) {
    Write-Host "Pending renames found: $($pending.Count / 2) operation(s)"
    $pending | ForEach-Object { Write-Host $_ }
} else {
    Write-Host "No pending file renames. Reboot won't help, move to Step-by-Step."
}

If that script outputs "No pending file renames," stop here, a reboot won't fix your problem and you need to follow the full guide below. If it does output pending operations, reboot and re-check.

Advanced Troubleshooting

Diagnosing via Event Viewer: The CBS Operational Log

Open Event Viewer (press Win + R, type eventvwr.msc, press Enter). Navigate to Applications and Services Logs → Microsoft → Windows → Servicing → Operational. Filter by event IDs 2 (error), 4 (warning), and 50 (package failure). Look for entries timestamped around when you installed the .NET KB. Event ID 50 with a description containing FAILED_PREPARE_PENDING or FAILED_BLOCKING_POLICY is a strong signal that a security tool or policy blocked the file replacement.

Group Policy and Windows Defender Application Control

On domain-joined Windows 11 24H2 machines, your organization may have a WDAC or AppLocker policy that prevents modification of files in C:\Windows\Microsoft.NET\. This is especially common in CIS Level 2 hardened images and DoD STIGs. Run this from an elevated PowerShell console to check if WDAC is enforcing:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
    Select-Object CodeIntegrityPolicyEnforcementStatus, UsermodeCodeIntegrityPolicyEnforcementStatus

A value of 2 means WDAC enforcement is on. If that's your situation, the fix needs to happen at the policy level, either the CBS servicing path needs to be whitelisted in the WDAC policy, or you need to temporarily set the policy to audit mode, apply the update, verify the DLL version, then re-enable enforcement. Work with your security team on this, don't just disable WDAC without authorization.

Registry: Manually Clearing a Stuck PendingFileRenameOperations Entry

In rare cases, a previous update's pending rename operation gets stuck and blocks all subsequent CBS transactions from completing their file swap. You can inspect and manually clear this in the registry, but be careful, because a legitimate pending operation that you delete might cause a different update to fail.

regedit

Navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager

Look for the PendingFileRenameOperations value. It's a multi-string (REG_MULTI_SZ). Each rename operation is a pair of strings: the source path followed by the destination path. If you see entries pointing to .NET\Framework\v2.0.50727 files with a .tmp or .old suffix, those are the stuck CBS rename operations. You can delete just those pairs, leave any unrelated pairs intact. Back up the entire key first:

reg export "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" C:\backup_sessmgr.reg

Then reboot. CBS will attempt to re-execute its pending operations from the last checkpoint.

Enterprise / WSUS / SCCM Environments

If your machines are patched via WSUS or SCCM/MECM, the KB may have been approved and distributed but the content hash in the WSUS database doesn't match the downloaded payload, causing a silent content validation failure. Check the Windows Update client log:

Get-WindowsUpdateLog

This generates a readable log at C:\Users\%USERNAME%\Desktop\WindowsUpdate.log. Search for netfx and look for DownloadFailed or FAILED_INTEGRITY_CHECK entries. If you find them, force a WSUS content re-download from the WSUS console: right-click the affected KB → Approve for Install → unapprove → re-approve, then run wuauclt /detectnow on the client.

Prevention & Best Practices

Once you've fixed the immediate problem, the real question is: how do you stop this from happening on the next patch cycle? I've put together what I consider the minimum set of practices for any environment, whether you're a solo IT admin managing a handful of machines or running an enterprise fleet through SCCM.

First, build a post-patch validation script and run it automatically after every maintenance window. A simple PowerShell script that checks the file version of key .NET DLLs against a known-good version table, and alerts you if there's a mismatch, catches these issues before your end users do. It takes 20 minutes to write and saves hours of reactive firefighting.

Second, never rely on Fast Startup in environments where you're actively patching. Fast Startup (technically called Hybrid Boot) was designed to speed up boot times on consumer laptops, it's not appropriate for managed workstations receiving regular patches. Disable it via Group Policy: Computer Configuration → Administrative Templates → System → Shutdown → Require use of fast startup → Disabled. Alternatively, via registry:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Power" `
    -Name "HiberbootEnabled" -Value 0 -Type DWord

Third, in enterprise deployments, ensure your WSUS or MECM distribution points are configured to validate content hash on download. This prevents content corruption from going undetected during distribution. In SCCM, verify under Administration → Distribution Points → Properties → Content Validation that validation is enabled on a schedule.

Fourth, if you're deploying Windows 11 images from a captured WIM, make sure the capture happens after all pending updates, including .NET Framework, have been applied and rebooted through. Capturing mid-update or with pending operations in the registry is the number-one source of the FOD version conflict described in Step 4.

Frequently Asked Questions