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

Question

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

Hans de Ruiter 20

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?

0 comments

2 answers

Your answer

Answer 1

Carl-L 22,155 Microsoft External Staff Moderator

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.

Hans de Ruiter 20

What is still troubling to me is after installation on 8037 the CBS finds no corrupted things. This message is seen inside the CBS log: "CSI FileFlags Corrupt: 0" After installing update 8655 I check it again and then see "CSI FileFlags Corrupt: 1282" Despite downloading update 8655 and installing it DISM downloads an extra 250Mb to repair the installation. How can this be? And to make matters worse the same behavior is also seen after updating to 8737: "CSI FileFlags Corrupt: 791" and is downloading additional 252Mb...... Again an other repair after installing 8737.... Is this the future of every update? Installing an update on a before good system with no faults and during a DISM check it sees corruption that needs to be repaired?

A second, third, fourth DISM check; it spends also a lot of time downloading 252Mb and 0 Bytes while the end report is saying "CSI FileFlags Corrupt: 0" each time. For some reason the check is set in some kind download mode.

I dove somewhat more into this issue and found something that is absolutely not right:
I ran DISM /RestoreHealth commands 2 times each on my system and inside a VM installation. Which each run (2 times) I saw the same behavior. (I renamed each time the CBS.log to make sure I capture only those 2 runs)

During each run I see that the CBS engine downloads 2 times. (Clearly marked by: "CBS FC: FCAcquirerWUClient: WULib DownloadProgress: [ x / 100]" At the first occasion of downloading it was downloading 252Mb. At the second occasion 0Mb.

This is DISM doing all the time each time I run that DISM /RestoreHealth command. Why is it downloading with each time constant 252Mb? Everything with the first run was (if any) already repaired. So why keep on repairing and downloading each time while the report later on mentioned 0 corrupted files found?

I have a suspicion that early on in the proces it evaluate after the initial check. It enters that stage with "FLOW: Entering stage: CheckCsi" After 41 seconds it returns and starts the evaluation proces and.... Makes the wrong decision to enter that Download stage. Seeing this 2 times one direct after another I must conclude: There is something wrong with this decision making. A bug so to speak.

This is shown after a 2nd run, third, fourth etc. by running DISM /RestoreHealth

CBS    FLOW: Entering stage: CheckCsi

---> This stage took 41 seconds and then continues.

CSI    00000009 Direct SIL provider: Number of files opened: 146079.
CSI    0000000a@2026/7/8:10:22:13.801 Corruption detection complete. numCorruptions = 0, Disp = 1.
CBS    Repr: CSI meta data corruption found, will commit repair transaction if repair is asked.
CBS    Repr: CSI Store check completes
CBS    FLOW: Entering stage: CheckStagedPackages
CBS    Repr: Not adding baseline package: Microsoft-Windows-FodMetadataServicing-Desktop-Metadata-Package~31bf3856ad364e35~amd64~~10.0.26100.1742 to removal list
CBS    Package Format: PSFX
CBS    Delta Format: ForwardOnly
CBS    Appl:LCU package and revision compare set to explicit
CBS    Package Format: PSFX
CBS    Delta Format: ForwardOnly
CBS    Package: Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10 is a Baseline according to custom properties
CBS    Repr: Not adding baseline package: Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10 to removal list
CBS    Appl:LCU package and revision compare set to explicit
CBS    Package Format: PSFX
CBS    Delta Format: ForwardOnly
CBS    Repr: Staged package check completes
CBS    Repr: No payload missing but suspected file flag corruption detected, continuing to acquire CIX for RepairStagedFileFlags.
CBS    Exec: Download qualification evaluation, business scenario: Manual Corruption Repair
CBS    Exec: Clients specified using Windows Update.
CBS    FC:   Calling Download on WUClient Acquirer
CBS    FC:   FCAcquirerWUClient: Calling WindowsUpdateDownloadFromUUP
CBS    FC:   FCAcquirerWUClient: WULib Mode Complete: [0]
CBS    FLOW: Entering stage: Download
CBS    WU: Microsoft Update service is the default, URL: https://fe2cr.update.microsoft.com/v6/, Name: Microsoft Update
CBS    Windows Insider Program: Current settings: Content type: (null), Build branch: (null), Ring: (null), Build Flighting Enabled: No
CBS    DWLD: Current product search criteria: (Product='Client.OS.rs2.amd64' and CurrentVersionOnly=1 and DeploymentAction=*)
CBS    DWLD: WU search succeeded with WU result code 2
CBS    FC:   FCAcquirerWUClient: WULib Mode Complete: [1]
CBS    WU: PSF is available and preferred for the update.
CBS    DWLD: Downloading update (0 of 0 bytes)...[0 of 0 bytes overall - 0%], sub phase: 1, sub percentage: 0
CBS    FC:   FCAcquirerWUClient: WULib DownloadProgress: [0 / 100]
CBS    DWLD: Downloading update (0 of 0 bytes)...[0 of 0 bytes overall - 0%], sub phase: 1, sub percentage: 0
CBS    FC:   FCAcquirerWUClient: WULib DownloadProgress: [0 / 100]
CBS    FC:   FCAcquirerWUClient: WULib DownloadProgress: [0 / 100]
CBS    FC:   FCAcquirerWUClient: WULib DownloadProgress: [0 / 100]

---> After 4 minutes it is finished. Later on it initiates a second download but downloads 0 bytes.

CBS    DWLD: Downloading update (266329085 of 266329085 bytes)...[266329085 of 266329085 bytes overall - 100%], sub phase: 4, sub percentage: 100
CBS    FC:   FCAcquirerWUClient: WULib DownloadProgress: [100 / 100]
CBS    DWLD: Downloading update (266329085 of 266329085 bytes)...[266329085 of 266329085 bytes overall - 100%], sub phase: 4, sub percentage: 100
CBS    FC:   FCAcquirerWUClient: WULib DownloadProgress: [100 / 100]
CBS    FC:   FCAcquirerWUClient: WULib Mode Complete: [2]
CBS    FC:   FCAcquirerWUClient: WindowsUpdateDownloadFromUUP returns. [0x0]

---> After 4 minutes the summery and conclusion.

CBS    Summary:
CBS    Operation: Detect and Repair 
CBS    Operation result: 0x0
CBS    Last Successful Step: Remove staged packages completes.
CBS    Total Detected Corruption:	0
CBS    	CBS Manifest Corruption:	0
CBS    	CBS Metadata Corruption:	0
CBS    	CSI Manifest Corruption:	0
CBS    	CSI Metadata Corruption:	0
CBS    	CSI Payload Corruption:		0
CBS    	CSI FileFlags Corrupt:		0
CBS    Total Repaired Corruption:	0
CBS    	CBS Manifest Repaired:		0
CBS    	CSI Manifest Repaired:		0
CBS    	CSI Payload Repaired:		0
CBS    	CSI FileFlags Repaired:		0
CBS    	CSI Registry Metadata refreshed:	False
CBS    	CSI Store Metadata refreshed:		True
CBS    Staged Packages:
CBS    	CBS Staged packages:			0
CBS    	CBS Staged packages removed:	0
CBS    
CBS    Total Operation Time: 537 seconds.
CBS    Ensure CBS corruption flag is clear
CBS    Ensure WCP corruption flag is clear
CBS    CheckSur: hrStatus: 0x0 [S_OK], download results: Client.OS.rs2.amd64_history_cix:0x0;Client.OS.rs2.amd64:0x0;
CBS    Count of times corruption detected: 3
CBS    Seconds between initial corruption detections: -1
CBS    Seconds between corruption and repair: -1
CBS    Reboot mark cleared
CBS    Winlogon: Simplifying Winlogon CreateSession notifications
CBS    Winlogon: Deregistering for CreateSession notifications
CBS    Exec: Processing complete, session(Corruption Repairing): 31264451_2291411557 [HRESULT = 0x00000000 - S_OK]

All because at the beginning it states: CSI meta data corruption found while if this was true it was already repaired at the first run. This is the 2nd run direct after the first run. Nothing has been changed or altered on 2 different systems!!!!

It says it found 3x a corruption after the run before resolved any corruption already. It states that it clears the CBS corruption flag but it seems that is not the case because a second run mentioned CSI meta data corruption from the start again..... I think someone with some technical skills must take a look at this reproduceable issue. I could reproduce it on 2 different systems. And it does this each time I run DISM /RestoreHealth. Something is wrong here. Nothing have to repaired a second, third, fourth etc. time.... (I look in the CBS.log file for a clue which 3 corrupted things were found and are being repaired. Normally I can see lines where a certain file etc. is being replaced but in this case I found nothing)

In the meantime DISM /RestoreHealth reports that's nothing is wrong.

C:\Windows\System32>dism /online /cleanup-image /restorehealth

Deployment Image Servicing and Management tool
Version: 10.0.26100.8737

Image Version: 10.0.26200.8737

[==========================100.0%==========================] The restore operation completed successfully.
The operation completed successfully.

That maybe but is suddenly slows down around 63,4% and the complete proces took 12 minutes while before the CBS change with 8655 it took a 4 minutes. It's now downloading unnecessary things while everything was repaired just before with a run just before it. Something is wrong. Unless Microsoft is tickering at the their reference where DISM is looking at each day, every 15 minutes... Can't believe that. There are those updates that are released on a monthly basis.

While writing this I noticed something new. After 30 min (system 1) and 1,5 hours (system 2) when the TrustedInstaller ends it DISM /RestoreHealth proces. (times out, nothing to do.) suddenly the CBS engine is woken again and does some Feature and Language checks and adding stuff. (3 minutes) This maybe a new proces (I am not an Insider) that is introduced but this has nothing to do with that DISM /RestoreHealth issue. I think a new scheduled task has been added inside Windows with 8655 or 8737.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Carl-L 22,155 Reputation points Microsoft External Staff Moderator

2026-07-09T13:24:28.6+00:00

Hello Hans de Ruiter,

Thanks for replying.

I'll see what I can do. I'll keep you updated.
Carl-L 22,155 Reputation points Microsoft External Staff Moderator

2026-07-14T12:33:17.8+00:00

Hello Hans de Ruiter,

Based on this, I would not take it as a normal behavior, but for now. It is best for us to let it be since I cannot be sure of what might cause it. For the DISM, the next time please try to use ScanHealth or CheckHealth to see if the same behavior appears. In the meantime, it'd be best to wait for the next cumulative update to see if the issue persists.

Thank you for your understanding.
Hans de Ruiter 20 Reputation points

2026-07-14T13:14:53.0166667+00:00

OK.
I suspect a change is made with 8655 concerning the CBS-Engine. Since this build I see new messages that I did not see before that build. It seems to be significant because when I newly install 8037 and update the system, it first has to download 8655, after that it updates to 8737. Before build 8655 you could install 8037 and straight after that it updated directly to the latest build. With other words; when updating from 8037 to 8737 it always has to pass through 8655. That means a major change. Direct from 8037 to 8737 is not possible. That path is there for a reason; A major change inside the CBS-engine it looks like.

Using ScanHealth or CheckHealth will not help. They don't download. It checks only if it could finds issues. If there are; RestoreHealth fixes these issues.

Just checked. Ran ScanHealth and CheckHealth; both reported "No component store corruption detected." But if I run RestoreHealth after this it starts to download again (252Mb) while there is nothing wrong. Both commands checked that already. Basically RestoreHealth is making the wrong decision. It "Thinks" there is something wrong while the previous 2 commands said: No. Before 8655 it never did that.

Well we have to see if this issue continues after the next update..... Solved or not.
Hans de Ruiter 20 Reputation points

2026-07-20T09:19:06.7966667+00:00
OK. @Carl-L

Well I have since the last comment installed update 26200.8875 and yesterday the OOB update 26200.8894. I noticed that after update 8875 the packages of the old update 8737 packages were not removed. After 8894 they were removed so the total of packages dropped from 265 down to a normal 184 packages.

I checked the behaviour of Restorehealth again and the issue still remains despite SFC and Scanhealth found nothing. After update 8894 I ran Restorehealth for the first time. It downloaded again 254Mb of data. All it found was "CSI FileFlags Corrupt: 7" OK it corrected this issue. A second run show suddenly an unexpected "CSI Payload Corruption: 1" corruption...?? How was this possible after the first run? That should correct those flags and payload corruption in one go. A third run it again downloaded again 254Mb but did not repair anything. The same after a 4th and 5th run.
Looking at the CBS I noticed 1 line which is the cause of the issue. Because the CBS suspects a corruption it went straight into download mode.
That line I have seen to be present in all attempts where it downloaded 254Mb while nothing needed to be repaired:

CBS Delta Format: ForwardOnly CBS Repr: Staged package check completes CBS Repr: No payload missing but suspected file flag corruption detected, continuing to acquire CIX for RepairStagedFileFlags. <<<<<<!!!!! CBS Exec: Download qualification evaluation, business scenario: Manual Corruption Repair CBS Exec: Clients specified using Windows Update. CBS FC: Calling Download on WUClient Acquirer CBS FC: FCAcquirerWUClient: Calling WindowsUpdateDownloadFromUUP CBS FC: FCAcquirerWUClient: WULib Mode Complete: [0] CBS FLOW: Entering stage: Download <<<<<<!!!!!!

In the first run it saw a Fileflag corruption, in the second attempt a Payload corruption. But at the 3rd, 4th, 5th attempts nothing. It's only because of this suspicion that it enters the download mode while in the final report it reports no corruption at all. So it spent time to download in the first stage 254Mb in the second stage; 0 bytes for no appeared reason! (duration of 1st and 2nd stage are the same and prolongate the delay in performance of that RestoreHealth command.) As I said earlier instead of 4 minutes it takes now 14 minutes before RestoreHealth reports: "The restore operation completed successfully." with "no errors"....

So the issue is not solved with these 2 updates......
Carl-L 22,155 Reputation points Microsoft External Staff Moderator

2026-07-21T13:41:28.8533333+00:00

Hello Hans de Ruiter,

Thanks for getting back.

In this case, I'd say that you should submit the issue to the Feedback Hub so the engineering team can take a look on it as soon as possible.

I'll see if there anything we can do now. I'll keep you updated.
Hans de Ruiter 20 Reputation points

2026-07-21T14:37:53.1466667+00:00

Hello @Carl-L
Thanks for the advice. Just did that. Added also a link to this page in order to don't have to explain everything twice. 👍

Wait and see if I get any reaction on this issue......
Hans de Ruiter 20 Reputation points

2026-09-17T13:10:38+00:00

Hello @Carl-L Despite I send a report through the Feedback Hub nobody looked at it or gave a reaction.
It seems this is ignored for unknown reasons.

We are sitting now on 25H2 Build 26200.9457 and the CBS-bug is still present!
To make things worse: Even the new 26H2 preview build (26300.9457) has it also. It is just a copy of 25H2.

Only Winver says it is 26300.XXXX but if I look in the Component Store there are no packages beginning with 26300 what so ever. They are still beginning with 26200! This is not a 26H2 version. It is just renaming 25H2 to 26H2 and claiming is is newer than 25H2. No it isn't!! It has the same issues as 25H2 already has.
Is this some marketing stunt? We have seen this before with 24H2 -> 25H2 and now with 26H2. There are still basic packages from 24H2 in 25H2 and 26H2. Those were released on 6 September 2024. 2 years later those are still there. How long will this continue? 27H2, 28H2? Will we see ever a real successor of Windows 11?

Since 26200.8737 and 26200.9457 3 months has gone by with nobody looking at this issue or doing something about it.

Sending a report does not doing anything also. They are shoving this issue beyond 26H2.

They even have trouble to test their releases thorough. With 9445 (8 Sept. 2026) suddenly came for some people issues with their USB 1.0 products. They reported it. And 6 days (14 Sept. 2026) later an OOB update 9457 was released to solve this issue.

This CBS-bug is ignored and keeps on continuing with 26H2 and further on..... Because no one is listening.
Other Windows 11 forums (non-MS) has seen this also and complain. They revert now to DISM /ScanHealth to see if there is something wrong. This command detects issues!! CSI FileFlags corrupted: 1245 and just reports: Everything is OK. Running DISM /RestoreHealth sees this issue and downloads 2x 270Mb (1; real, 2; denied by the upload server: "You got it already. So why asking for it again?....") and fixes in the end those corrupted CSI FileFlags.

And the troubling part is that it only occurs after each regular update. (no-preview updates) Why? Everything before the update was not corrupted. After the update it is. How reliable are those updates then???? It seems that the updates itself corrupts things.

What the consequences will be when so many CSI FileFlags are corrupted I don't know. One thing are certain; those FileFlags are there for a reason. One is security. To make sure that those files are protected from manipulating from cybercriminals. A manifest is send with the update and a check makes sure that certain files does not have the wrong rights so that a certain file owned by the TrustedInstaller don't have the wrong rights so that a file can be replaced by an other malicious version. Because of this CBS-bug everybody could check their system with ScanHealth. It sees those CSI FileFlags are corrupted according to that manifest and reports: Everything is OK. NO It isn't. (Inside the CBS.log file you can see!!! That things are not OK!) So a possible gap in security exists waiting to be exploited!!!!!

If these things are happening deep inside Windows what will surface and becomes an problem also tomorrow?

It seems that that Feedback Hub is useless for reporting serious issues. They seems to end up at their helpdesk and don't look at it and bother to send it up the chain.

Regards, Hans.

Answer 2

Hans de Ruiter 20

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.

Caozhi Li 7,525 Reputation points Volunteer Moderator

2026-07-08T14:31:27.47+00:00

Hi Hans, sorry for the confusion! I restored and converted your answers as comments, and they are all located under Carl's answer. You can see them here:

https://learn.microsoft.com/en-us/answers/c/2727843.

https://learn.microsoft.com/en-us/answers/c/2727844.

https://learn.microsoft.com/en-us/answers/c/2727858.
Caozhi Li 7,525 Reputation points Volunteer Moderator

2026-07-08T14:33:24.9966667+00:00

If you want to delete any of these, please feel free to let me know, or click the "Flag" icon (Report a Concern) and choose any of the reasons. The system will then delete it for you. :)