KB5131595 still offered although WinRE is already at build 19041.7801

Question

KB5131595 still offered although WinRE is already at build 19041.7801

Alberto 5

KB5131595 is still offered although WinRE is already at build 19041.7801 — installation fails with 0x80070005 during WIM commit

System configuration

Windows 10 Home, version 22H2, x64

OS build: 19045.7807

ESU enrollment: confirmed

Recovery environment: enabled

Recovery partition: partition 4

Problem description

Windows Update continues to offer KB5131595, the October 2026 WinRE update, but installation repeatedly fails with error 0x80070643.

According to Microsoft's documentation for KB5131595, the update should not be offered when the installed WinRE image is already at version 10.0.19041.7801 or later.

I manually updated the WinRE image to build 19041.7801. However, Windows Update still offers KB5131595, and subsequent installation attempts continue to fail.

The active WinRE configuration has been verified using reagentc /info:

Windows RE status: Enabled

Windows RE location: \?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE

The image at that exact location was queried using DISM. The output confirms:

Version: 10.0.19041

ServicePack Build: 7801

Architecture: x64

Image type: WindowsPE

Last modified: 15 October 2026

The image is therefore at the version specified in Microsoft's documentation.

Installation failure details

The update repeatedly fails while processing the temporary image at:

C:$WinREAgent\Scratch\update.wim

The relevant errors in setupact.log and the DISM logs include:

C:$WinREAgent\Scratch\Mount\Windows\System32\drivers\ItSas35i.sys (HRESULT=0x80070005)

Could not commit changes during unmount.

ImageRecaptureDirectory: Access denied.

WIMCommitImageHandle: Access denied.

The failure occurs during the commit/unmount phase of the WIM servicing operation.

The file ItSas35i.sys has a valid Microsoft Windows digital signature. Its original copy and the copy in the mounted image have identical SHA-256 hashes. File permissions were also compared and did not reveal an obvious discrepancy.

Troubleshooting already performed

The following steps have already been completed:

SFC /scannow found and repaired corrupted system files.

DISM /CheckHealth and /ScanHealth reported no component store corruption.

The WinRE image was manually updated to build 19041.7801.

The WinRE image is enabled and registered at the expected recovery partition.

The failed servicing operation was examined using Process Monitor.

Relevant file and registry access events were investigated, but no confirmed root cause was identified.

The temporary WIM is reported by DISM as mounted read/write with status OK.

The update still fails after these checks.

Questions

Applicability detection: Why does Windows Update continue to offer KB5131595 when the active, registered WinRE image is already at build 19041.7801, which appears to meet Microsoft's stated exclusion criterion? Is there another applicability condition, detection mechanism, or registry state that must be satisfied?
WIM commit failure: What could cause DISM to return 0x80070005 specifically during ImageRecaptureDirectory / WIMCommitImageHandle, with the error pointing to ItSas35i.sys, even though the file is correctly signed, its contents match the original, and its permissions appear normal?
Recommended diagnostic procedure: Is there a Microsoft-supported diagnostic procedure to identify the underlying cause of this specific WinRE servicing failure, without resorting to a Windows reinstall or an in-place repair?

I am looking for a technically supported explanation of both the unexpected update applicability and the WIM commit failure, rather than generic troubleshooting steps for error 0x80070643.

0 comments

2 answers

Your answer

Answer 1

Alberto 5

Hi Ramesh,

Thank you for your suggestion. I checked the WinREVersion registry value, and it currently matches the version of the active WinRE image: 10.0.19041.7801.

On 19 October, KB5131595 was installed successfully without me manually starting another installation attempt. Windows Update now reports that the system is up to date.

Unfortunately, I did not record the registry value before the successful installation, so I cannot confirm whether it was previously outdated. The cause of the earlier installation failures also remains unknown.

Thank you again for your help.

Ramesh Srinivasan 89,855 Reputation points Independent Advisor

2026-10-19T04:37:15.3066667+00:00

Hi Alberto,

Looks like Windows has updated the registry value automatically. Glad it's sorted.

The cause of the earlier installation failures also remains unknown.

Clean-booting Windows using msconfig.exe, removing third-party filter drivers, and uninstalling third-party antivirus/firewall software might help resolve the issue. The Farbar Scanner can remove third-party filter drivers using a custom fixlist.txt file. But it will be a trial-and-error solution, as we won't know which driver is blocking the WIM mount or unmount operation.

Answer 2

Ramesh Srinivasan 89,855 Independent Advisor

Hi Alberto,

Applicability detection: Why does Windows Update continue to offer KB5131595 when the active, registered WinRE image is already at build 19041.7801, which appears to meet Microsoft's stated exclusion criterion? Is there another applicability condition, detection mechanism, or registry state that must be satisfied?

After manually updating the winre.wim image, I wonder if you've updated the WinREVersion registry value manually. Please open Regedit.exe and check the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

If the latest WinRE update is installed, WinREVersion should read 10.0.19041.7801. If it hasn't been updated, Windows Update will offer the same update again.

enter image description here

Regarding the WIM commit failure, Microsoft hasn't acknowledged that issue, although many users have reported it in this forum. Clean-booting Windows using msconfig.exe, removing third-party filter drivers, and uninstalling third-party antivirus/firewall software might help resolve the issue.

Alberto 5 Reputation points

2026-10-19T04:08:28.7433333+00:00

Hi Ramesh,

Thank you for your reply and for suggesting that I check the WinREVersion registry value. Your suggestion gave me another possible explanation to investigate.

Update (19 October 2026):

The issue appears to have resolved itself, although the underlying cause remains unknown.

On 19 October, I checked Windows Update and found that KB5131595 had been installed successfully. I had not manually initiated another installation attempt. Windows Update now reports that the system is up to date, and a subsequent manual check for updates produced the same result.

I have verified the following:

The active WinRE image (winre.wim) is at version 10.0.19041.7801, as confirmed by DISM.

The registry value HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinREVersion currently also reads 10.0.19041.7801.

Windows Update history records KB5131595 as successfully installed on 19 October 2026.

Windows Update no longer reports any outstanding updates.

Your suggestion raises an interesting possibility: perhaps the WinREVersion registry value did not reflect the manually updated WinRE image before the successful installation, causing Windows Update to continue offering KB5131595. Unfortunately, I did not record the registry value before the update succeeded, so I cannot establish whether it was previously outdated.

The earlier DISM/WIM commit failures involving error 0x80070005 and ItSas35i.sys also remain unexplained. The eventual successful installation does not, by itself, tell us what caused those failures or what changed before the update succeeded.

I am still looking for an explanation of what happened. If you have any further thoughts on the applicability detection mechanism, or on how the registry value might have affected it, I would be very interested to hear them.

Thank you again for taking the time to help.