Second Reboot Fixes DISM StartComponentCleanup Error 6824

Generally speaking, whenever one installs a Win10 cumulative update (CU), it raises the possibility that component store cleanup should follow. How do you find out if cleanup is needed? The command DISM /Online /Cleanup-Image /AnalyzeComponentStore when run, will recommend for or against cleanup. Lately, I’ve observed that trying to run that cleanup immediately after the restart that CU install requires doesn’t always work. Generally, a second reboot fixes DISM StartComponentCleanup nicely.

In fact, I’ll show a sequence of PowerShell screencaps that show this in action. [WARNING! Completing this cleanup often takes a long time — over a half hour on my Surface Pro 3, for example.]

How to Tell If a Second Reboot Fixes DISM StartComponentCleanup

You’ll know if you need to try a second reboot because of the error message that DISM produces for that particular command. It appears in the following screenshot:

Notice the 6824 error at bottom: “The operation cannot be performed because another transaction is depending on that fact that this property will not change.”
[Click image for full-sized view.]

Apparently, a Reboot Clears the Pending Mystery Transaction

MS Docs labels the 6824 error code as ERROR_CANT_BREAK_TRANSACTIONAL_DEPENDENCY. As far as I can tell, it means that some other OS transaction is pending. Before DISM StartComponentCleanup can do its thing, that transaction must complete. I  can’t yet identify that other pending transaction. But it’s pretty clear that a second reboot handles and clears it. The second reboot lets the previously failed DISM command run unimpeded.

If you ever find yourself in this boat after installing a CU, try another reboot. It’s worked for me every time I’ve gotten the 6824 error code instead of package cleanup. It should probably work for you, too.

Here’s where I wound up with my successful cleanup, after the second reboot. Please note that after the DISM command ran for 30 minutes it got stuck on 94% complete. So I closed the PowerShell window, opened it again, and re-ran the same command. What you see below shows the strange results that ended in success almost immediately. I ran another /AnalyzeComponentStore command to get “post-cleanup” sizes. The component store dropped from 15.93 GB to 6.52 GB (HUGE: 9.42 GB), with attendant size reductions in actual size, primarily from backups and disabled features. It’s pretty unusual to see six (6) reclaimable packages after a CU, so I expected — and got — significant cleanup. Good stuff!

[Click image for full-sized view.]