Very strange Windows 11 MCT .ISO version: 26200.8653. It has issues! 8655 also...

Hans de Ruiter 20 Reputation points
2026-07-07T11:01:08.9533333+00:00

This subject was rejected by the system as Spam inside the Microsoft Community Hub. Where is the Spam than in this message? This is a serious technical question that needs to be looked at !!!!

A while back I download the latest Windows 11 Build 26200.8653 .ISO by using the Media Creation Tool. This was created on 06-06-2026. A date newer than the complete Windows 11 .ISO called "Win11_25H2_<Lang>_x64_v2.iso" which has build 26200.8037.

I installed this 8653 build as a new installation because my Windows 11 version was damaged (An In-Place-Installment could not fix the issue) Installed this version. SFC and DISM /RestoreHealth reported no issues. Check it content (ComponentStore) found 61x 1742 and 61x 8653 packages and some other packages with other build versions. 139 Packages in total. After this installment an official update came along; 26200.8655. This installation refused to see this update. Each time I pressed Check for updates it said None. OK I thought. Maybe 8653 and 8655 are so close together that there was no upgrade path known. Wait on the next one then. It came in with update 26200.8737 (Again a preview version..... It happens a lot lately...) Windows update saw this update and started to download this one and apply the update. After the update I checked with SFC and DISM /RestoreHealth if the installation was OK. DISM was unusually long busy so I analyzed the CBS.log after everything was finished. Great was my supprise that CBS detected 1652 "corrupted" packages it "repaired". While both the .ISO and update where official ones. How is this possible? I looked at the content of the ComponentStore again and to my amazement it reported 72x 1742 and 72x 8737 packages, 162 in total....... It seems to me that those files were not corrupted but missing. Seen that of both versions 1742 and 8653 rose from 61 to 72 packages with a lot of files beneath each package; a grand total of 1652 files..... So why is MS through MCT releasing (i checked) until today version 26200.8653 while I would expect an official version like 26200.8655?

A second issue has introduced with 8737. It takes DISM /RestoreHealth some 10 min. while with 8653 it took some minutes to complete. I can see in the CBS.log file that DISM is spending much time at downloading what? (CBS FC: FCAcquirerWUClient: WULib DownloadProgress: [[0-100] / 100]) The percentage of 0 to 100% is taking up much of the time. 2 tries with some 2-3 minutes; that's 4-6 minutes out of the 10 minutes. And for what? It clearly want to download something from the MS servers. If something is corrupt or missing I understand. But each time if you start DISM /RestoreHealth 5 times in a row? Very unlikely. Also some strange messages are to be seen in the CBS.log that I have never seen before;

  • "Info, CBS MumX velocity marker '\?\C:\WINDOWS\Servicing\mumxenabled.cbs' present: FALSE" a lot of times. Is this a good or bad thing?
  • "Info, Attempting to load DPX from \?\C:\WINDOWS\CbsTemp\31264038_1696250520\Client.OS.rs2.amd64_history_cix\metadata\dpx.dll" after that some check. It checks every package onboard expands it as reaction of "Flags=0x00000003" or this is a result flag? (Good?)

There seems to be changes made inside the CBS engine resulting in a longer duration of the DISM /RestoreHealth command. It's just not me. Everyone have this issue and are also complaining that DISM /RestoreHealth is taking now so long with build 26200.8737. No wonder if Windows tries to download things for no apparent reason. (bogus so to speak) Why is this? Is this known? And if so; is this issue being fixed or explained why?........ Find it strange that this behavior reaches production while this would also be noticeable inside canary channels..... I don't think I am the only one that is noticing this.

  • Last minute update. Installed a new Win11 from Win11_25H2_<Lang>_x64__v2.iso (build 26200.8037) on a VM. Updated the system. Instead of updating to 8737 it was updating to 8655 first. It seems that 8655 has a changed CBS engine. I thought it was introduced with 8737. No. That long dism /restorehealth behavior was introduced with 8655.
    Because of this this behavior is prolongated to 8737 etc. also..... During the first DISM /RestoreHealth run I saw that CBS found 1282 (???) corrupted files and repaired them (downloading 250Mb) At a second, third etc. attempt it keeps downloading but at the end it's downloaded 0 Bytes. And after 8655 is complete with no errors. Updating to 8737. Again 791 corrupted files? (252Mb download again) How is this possible? Updates suppose to leave no corrupted files behind.....

I understand that it took the 1st time some time to download 250Mb but why at the next attempt is it downloading again and in the end downloads nothing? Each check takes 16 min of which 2x it's downloading nothing. That's 2x 4-6 min of the total of 16 min. (slower on my VM) Why?

Windows for home | Windows 11 | Windows update
0 comments

2 answers

Sort by: Newest
Most helpful Newest Oldest
  1. Hans de Ruiter 20 Reputation points
    2026-07-08T14:25:44.27+00:00

    It seems your system has a problem with the word c-o-r-r-u-p-t. It rejected my answer 3 times. Now I see that only one message was deleted and I can't delete my 2 other same answers.

    Was this answer helpful?

    1 person found this answer helpful.
  2. Carl-L 22,155 Reputation points Microsoft External Staff Moderator
    2026-07-08T07:00:38.4833333+00:00

    Hello Hans de Ruiter,

    Welcome to Microsoft Q&A forum.

    I understand your concern when your freshly install Windows reports corruption after updates. However, this is more likely an over aggressive report from DISM rather than an actual corruption. DISM report usually means that "This component is not in the expected state" and not always "This component is broken and need replacing". This actually can happen when Windows update contain a new version of a component. DISM may scan and notice this mismatch and attempt to normalize the change. Also, since DISM /RestoreHealth is not local (the full command contains /Online). The downloading message you say is an attempt to download missing repair payloads, which could take time even if your machine is completely healthy. The time is not always used to download the payloads, it can also be used to validating the resources, checking the signatures,... After that, the DISM can decide that the data needed is 0.

    About the 8653 and 8655 build, you are correct, since 8653 and 8655 are quite close (Only 2 revisions apart), so the content cannot be much different. If Windows update check and define it already has the cumulative payloads it needed compared to 8655, it will not offer the update.

    For the message Info, CBS MumX velocity marker '?\C:\WINDOWS\Servicing\mumxenabled.cbs' present: FALSE, this is log as Info rather as error or warning. So this is not considered an error, it just notes that CBS check if MumX marker exists and it doesn't. The other message also looks normal since dpx is part of CBS.

    In short, since you can reproduce it on your VM, I'd say that it might just be the new update force the system check to perform much more validation and resource downloading, rather than the issue with the ISO file itself. I hope this clarifies.

    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    Was this answer helpful?

    2 people found this answer helpful.

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.