Windows 11 25H2 26200.8037 — KB5079473 repeatedly fails after in-place repair

NMcG 0 Reputation points
2026-09-27T16:34:41.6233333+00:00

Windows 11 25H2 26200.8037 — KB5079473 fails with 0x800705B9 /

0x80240069 despite in-place repair

I am looking for advice from anyone who has encountered this particular

Windows servicing problem.

SYSTEM

  • Windows 11 Home
  • Version 25H2
  • OS Build 26200.8037
  • Intel i9-14900
  • 64 GB RAM
  • ASUS PRIME Z790-A WIFI
  • Scan 3XS Computer Music PC
  • RTX 4060

The PC is currently stable and has very little third-party software

installed.

PROBLEM

KB5079473 repeatedly fails to install.

I have experienced:

  • Windows Update error 0x800705B9
  • Windows Update error 0x80240069
  • On one attempt the update reached approximately 18%, after which the entire Windows desktop became unresponsive. Mouse and keyboard stopped responding and the PC required a forced shutdown.
  • Subsequent attempts failed without another freeze.

DIAGNOSTICS ALREADY COMPLETED

  • DISM /CheckHealth — no component-store corruption reported
  • DISM /ScanHealth — failed with 0x800705B9, reporting that Windows was unable to parse requested XML data
  • DISM /RestoreHealth — failed with 0x800706BE / Error 1726
  • /RestoreHealth was also attempted using a matching Windows 11 25H2 WIM extracted from official installation media; this also failed with Error 1726
  • SFC /scannow — stopped at approximately 30% with Windows Resource Protection unable to perform the requested operation
  • CHKDSK — completed successfully; NTFS volume reported clean
  • Windows Update components were reset, including SoftwareDistribution and catroot2, without resolving the problem

MANUAL INSTALLATION

I downloaded the x64 KB5079473 MSU from the Microsoft Update Catalog.

DISM processed the package successfully but did not install it.

I then placed the documented checkpoint package KB5043080 and KB5079473

together and attempted to add them with DISM.

That produced:

  • 0x80070228
  • DISM Error 552

The DISM log showed both component databases being loaded, but

subsequently treated the packages as not applicable.

INTERESTING CBS FINDING

The most interesting evidence is in CBS.log.

During servicing, CBS reports:

Unable to resolve Package: @Foundation

with:

HRESULT_FROM_WIN32(1168)

i.e. ERROR_NOT_FOUND / 0x80070490.

However, this does not appear to mean that the Foundation package is

actually missing.

I independently checked the system and found:

Microsoft-Windows-Foundation-Package_(31bf3856ad364e35)amd64~~10.0.26100.1

registered under:

HKLMBased Servicing

and DISM reports the Foundation package as:

Installed | Foundation

So the package appears to exist and be registered, while CBS is

nevertheless unable to resolve the internal @Foundation reference during

servicing.

IN-PLACE REPAIR

I also performed an official Windows 11 25H2 in-place repair using the

same 26200.8037 ISO.

Setup was run from within Windows with:

Keep personal files and apps

The repair completed successfully.

Afterward the machine remained on:

26200.8037

but KB5079473 still failed.

This seems significant because the in-place repair did not resolve the

servicing problem.

QUESTION

Has anyone encountered this combination of:

  • Windows 11 25H2
  • build 26200.8037
  • KB5079473
  • KB5043080 reported as not applicable
  • DISM servicing failures
  • CBS reporting Unable to resolve Package: @Foundation
  • ERROR_NOT_FOUND (0x80070490)
  • and an in-place repair that completes successfully but does not correct the servicing problem?

In particular, I would like to know whether @Foundation is a known

CBS/package-store issue in 25H2, or whether there is another supported

way of diagnosing the component/package registration without performing

another Windows reinstall.

The PC is currently stable, so I am deliberately leaving the failed

update alone rather than repeatedly retrying it.

I have seen other Microsoft Q&A reports of KB5079473 failing on 25H2 /

26200.8037, including reports involving the KB5043080 checkpoint, so I

am particularly interested in whether this is a recognised variant of

the broader KB5079473 servicing problem.

Windows for home | Windows 11 | Windows update
0 comments

13 answers

Sort by: Oldest
Most helpful Newest Oldest
  1. NMcG 0 Reputation points
    2026-09-28T08:48:17.24+00:00

    Restore Health failed

    C:\Windows\System32>DISM /Online /Cleanup-Image /RestoreHealth

    Deployment Image Servicing and Management tool

    Version: 10.0.26100.5074

    Image Version: 10.0.26200.8037

    [===========================55.2% ]

    Error: 1726

    The remote procedure call failed.

    The DISM log file can be found at https://1drv.ms/u/c/7308677839a9f7c7/IQASgFlUqtRKQ5p4C47TfSB1Af-RgndT4wQQs1gxO9_sKo0?e=Jj2NZ2

    Was this answer helpful?

  2. NMcG 0 Reputation points
    2026-09-28T09:14:49.0333333+00:00

    I completed the clean-boot test as requested. After restarting with all non-Microsoft services and startup items disabled, I ran:

    DISM /Online /Cleanup-Image /RestoreHealth

    It again failed with Error 1726, this time at 54.7%.

    This is essentially the same result as normal startup, where it failed at 55.2%.

    I did not have Process Monitor running during this particular attempt. I will capture a complete ProcMon trace during another clean-boot RestoreHealth attempt if required.

    Was this answer helpful?

  3. NMcG 0 Reputation points
    2026-09-28T10:55:02.1533333+00:00

    Diagnostic update following the clean-boot test

    Following the recommendation to perform a clean boot and rerun DISM /Online /Cleanup-Image /RestoreHealth, I carried out the following tests.

    1. Clean boot

    Using msconfig:

    • Hid all Microsoft services.
    • Disabled all remaining non-Microsoft services.
    • Disabled all enabled startup applications in Task Manager.
    • Restarted Windows successfully into the clean-boot configuration.

    The remaining non-Microsoft services included Intel and NVIDIA services.

    2. RestoreHealth in clean boot

    I then ran:

    DISM /Online /Cleanup-Image /RestoreHealth

    The result was:

    [===========================54.7%]

    Error: 1726

    The remote procedure call failed.

    This is essentially the same result as under normal startup, where RestoreHealth previously failed at 55.2% with the same Error 1726.

    Therefore, disabling the non-Microsoft services and startup applications did not resolve the RestoreHealth failure.

    3. Unexpected reboot and BSOD

    Following the clean-boot RestoreHealth failure, Windows unexpectedly rebooted.

    I checked the System event log and found Event 41 (Kernel-Power), reporting that the system had rebooted without cleanly shutting down first.

    I then found Event 1001 (Microsoft-Windows-WER-SystemErrorReporting), which recorded:

    Bugcheck: 0x0000003B

    Exception: 0xC0000005

    A minidump was created:

    C:\Windows\Minidump\092826-7984-01.dmp

    The dump is 3,839,974 bytes and has been preserved.

    4. Hardware-related checks

    Because Event 41 can be associated with unexpected hardware or power events, I checked the System log for WHEA-Logger events covering approximately 10:20–10:30, including the period of the crash.

    There were no WHEA-Logger events during this period.

    I also checked for Disk, NTFS, storport, iaStor, volmgr and related storage events around the crash.

    There were no Disk, storport or iaStor errors. NTFS reported the C:, D: and other volumes as healthy.

    The relevant volmgr Event 162 simply confirmed that dump-file generation succeeded.

    5. Preliminary examination of the crash dump

    The dump confirms:

    0x3B SYSTEM_SERVICE_EXCEPTION

    with:

    0xC0000005 STATUS_ACCESS_VIOLATION

    The reported fault address is:

    FFFFF8031195B776`

    The module information places this address within:

    FLTMGR.SYS

    I have also obtained a copy of the installed FLTMGR.SYS for comparison.

    The dump contains references to Windows servicing activity, including TiWorker.exe associated with the servicing stack.

    I am not concluding that FLTMGR.SYS or TiWorker.exe caused the crash. At this stage, the evidence only establishes that the reported fault address is within FLTMGR.SYS and that servicing activity was occurring.

    6. Current picture

    The sequence now appears to be:

    Windows 11 25H2 / 26200.8037 → DISM RestoreHealth → approximately 55% → Error 1726 → 0x3B / 0xC0000005 system crash → automatic reboot → minidump created

    The RestoreHealth failure occurs at essentially the same point in both normal startup and clean boot:

    • Normal startup: 55.2%
    • Clean boot: 54.7%

    The clean-boot test therefore did not identify ordinary third-party services or startup applications as the cause.

    There are currently no WHEA hardware errors or storage errors associated with the crash.

    The outstanding question is whether the minidump can identify the actual failing kernel path/driver, or whether the evidence points towards memory/hardware corruption.

    I have not repeated RestoreHealth after the crash and have not made any further BIOS or hardware changes.

    The minidump is preserved and available for further analysis.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.