Return of the bogus 3.99 TB Windows Update Cleanup files

Topic

New Reply

The unacknowledged Win10 cumulative update KB 3201845 brings with it another annoying bug. ch100 reports: Following the installation of KB3201845 on 3
[See the full post at: Return of the bogus 3.99 TB Windows Update Cleanup files]

Reply | Quote

Replies

Wow! I had no idea that it was a well known bug from previous versions of the Windows 10 CUs.
Thanks for posting Woody. 🙂

Reply | Quote

I never thought I would say this but I’m almost starting to feel sorry for MS%^t – they’ve gone from malicious to malicious, incompetent and pathetic.

Reply | Quote

I wonder if we’ll ever see a stable/bug-free-ish Windows 10 at this point.

This level of sloppiness and poor QC would kill any “regular” company/product.
The only thing keeping MS/Windows alive is the huge inertia and the fact that people don’t really have alternatives.

Reply | Quote

@ Woody & CH100 What happened to the MS ‘Think Tank’ of old? Since I haven’t followed the OS blogs until a year and half ago, I really don’t have a first hand knowledge of troubles with Win 98 thru Win 7. I have known a few IT’s before my retirement in 2006, and can’t remember complains about OS’s or installations. It seems that the MS ‘Think Tank’ has been disbanded and the recommendations for builds and updates is coming from all over the world with no coordination. You all can correct me if I am wrong but I can’t remember so many builds and updates in past OS’s.

Reply | Quote

Apparently it doesn’t do that on all systems…

http://Noel.ProDigitalSoftware.com/ForumPosts/Win10/14393/DiskCleanupAfter479.png

Still, even a mere 1.8 GB seems like a helluva lot for Windows Update to have chewed up. I guess I’ll run it and see if I really do get gigabytes back.

-Noel

Reply | Quote

I’m not really sure how MS ranks suggestions these days. Merely compiling suggestions from 10 million or so “Insiders,” who are running with very stable almost-locked-in-concrete builds, is mind-boggling.

Reply | Quote

It would appear the the 3.99 (TB) would give away the fact that it was bogus. Maybe the update system of MS has been “hacked”!

Reply | Quote

The CU itself is almost 1GB

Reply | Quote

Naw. It’s just a bug that crept back in. Does make you wonder about Microsoft’s regression testing, though.

Reply | Quote

I got it on our 2 HP laptops with the KB 3200970 November 1607 CU [winver 14393.447]. These machines have massive 220GB HDDs in ’em. /rolleyes
Deletion did the trick; it took about 40 minutes for the process.

Reply | Quote

KB3201845 installed on my desktop and laptop last night and neither were affected by this ‘bug’.

Reply | Quote

LOL, running Disk Cleanup caused cleanmgr.exe and TiWorker.exe to go into a hard loops and use up several cores worth of CPU, while doing little I/O.

http://Noel.ProDigitalSoftware.com/ForumPosts/Win10/14393/DiskCleanupLoop1.png

It stayed in that state for about 10 minutes, after which TiWorker.exe settled down, I/O picked up to megabytes per second, and cleanmgr continued to loop hard.

http://Noel.ProDigitalSoftware.com/ForumPosts/Win10/14393/DiskCleanupLoop2.png

It finally finished after about ANOTHER 50 minutes of lots of CPU and not so much I/O. AN HOUR for a Disk Cleanup on an SSD setup?

http://Noel.ProDigitalSoftware.com/ForumPosts/Win10/14393/DiskCleanupLoop3.png

All in all about 6 GB of disk space was recovered.

LOL, since when did Disk Cleanup become highly CPU-intensive? That is just ridiculous.

This is somewhat reminiscent of the “looping update” problems with Win 7 and Vista.

-Noel

Reply | Quote

Maybe nobody taught the kids doing the programming to leave comments in the code when they fix something so that the next one doesn’t come along and unfix it.

-Noel

Reply | Quote

Regression Traceability seems non-existant at MS!

Reply | Quote

Jeeeeeezzzz…

Reply | Quote

Nick, there is a company named Citrix which has an even poorer quality record. It just happens that I work with Citrix products and I like the company and its products for being extremely innovative and having products which once the bugs are sorted out are like no other. Microsoft seems to have taken that approach with Windows 10. In both cases, support, even paid support is minimal and not quite at the expected standards. The end results are fantastic, but this requires a much higher effort on the side of the users/systems engineers.
Like with Citrix, the initial cost of the product is cheap or “free” but the real cost is in the time spent on the customer side to finalise the product and make it work as it should.
It is a gamble and I don’t know if it will eventually pay off for Microsoft, but I see it as the new way of doing this sort of business. I am involved in it and I am playing this game.

Reply | Quote

1-1.8 GB is more like normal for the size of the patches.
The behaviour of Disk Cleanup may depend on the history of the patches applied in the past or even Windows Update settings in Group Policy, i.e. update location – internal server or Windows Update, or the configuration of WU itself – Disabled, Auto, Download Only.

Reply | Quote

As Noel noticed above, on some systems it does not show. This may depend on the history of updates installed in the past and/or if Disk Cleanup was run in the past in relation to the patches introducing the same bug in the past and/or even the configuration of WU.

Reply | Quote

This looks very much like my experience with long time for installing and cleaning the stack post-installation.

Reply | Quote

This is too old fashion Noel 🙂
Now they do “agile” development and the results are obvious.
Saying that, it seems that the market these days prefers innovation against quality and this is exactly what Microsoft does.

Reply | Quote

Have you run Disk Cleanup in the past, i.e since October 2016?
Have you installed every patch released since August 2016 release of 1607?
Is your system a clean install of 1607 or upgraded from previous versions like 1507 or 1511?
All my systems are clean installs and one of them is Server 2016 which shares the code with 1607, more accurately is the server version of LTSB 1607, as it does not have Cortana and the Store Apps.
Just trying to identify a pattern, although it is only of academic interest at this stage, as the “bug” seems to be mostly cosmetic and misleading and not causing any trouble.

Reply | Quote

Yes, this is what I said in few previous posts about this update.
https://www.askwoody.com/2016/new-windows-10-version-1607-build-14393-479-kb-3201845-rolling-out/#comment-110639

Reply | Quote

Yes, I experienced that too after the update – in a max 64GB Parallels VM!!!

Reply | Quote

Except in my case the update went in fairly quickly; it was the Disk Cleanup that took an hour.

Call me old fashioned all you want 🙂 but I prefer “To Work” rather than “Agile”.

Why would anyone buy something that’s not expected to work? Sooner or later it leads to not being able to eat!

-Noel

Reply | Quote

In my case, no to the first question – I haven’t run Disk Cleanup in a long time.

My system was an in-place upgrade to 1511.

-Noel

Reply | Quote

I never had this bug the previous time or this time.

Just ran cleanup, had 3.89Gb. That’s G, not T.

It took 16 seconds on HP-Envy Win 10 1607 build 14393.479.

This was an in-place upgrade from Win 8.1 to 1507 and every update since.

It’s been stable and there’s been no trouble with any of the updates.

😉

Reply | Quote

Innovation involves DOING new things – not just breaking things or doing things that have already been done before (and better) and saying it’s innovation.

-Noel

Reply | Quote

Answer to the first two questions is yes. I have an upgraded version of 1607 on both PCs. I have Cortana but not downloaded and store apps.

Reply | Quote

Every time I ran Disk Cleanup to remove Windows Update files on my installed copies of Windows 8.1 and 2012 R2 (either in VM or running directly on a SSD), it took more than 1 hour, closer to 2 hours, before it would eventually complete.

No idea if this is related to your issue. I have absolutely no idea why it would take so long.

I thought it was ridiculous. Now whenever I decided to run Disk Cleanup on those systems I would just leave it to run until it completes.

On Windows 7 and Windows Server 2008 R2 Disk Cleanup usually finishes in a reasonably quick manner.

On that 3.99TB bug, I believe I had also seen it once or twice in my Windows 10 VMs before, so this is definitely not a new occurrence and is a regression if it appears again now.

Reply | Quote

@Jim I didn’t notice the bug in October for the simple reason that I didn’t run Disk Cleanup then. Maybe you had the issue then and fixed it then as you mentioned that you have run Disk Cleanup in the past and updated each time.
Difficult to find a definitive answer and I am wondering if Microsoft is interested at all in fixing this “trivial” bug when they have a lot more important problems to fix, like this current DHCP issue.

Reply | Quote

Same here! The update took about 25 minutes, but Disk Cleanup (and TiWorker.exe) took another 60 minutes.

Reply | Quote

I noticed this before I ran the Nov updates on my Win 10-1511 PC. I knew that 3.99TB was a bug, because my system drive is only 250GB 🙂

Maybe someday somebody will float an idea at Microsoft to make Windows just another desktop environment that runs on top of the Linux kernel. Leave the OS development to the big boys, and just focus on the GUI, lol!!!

Reply | Quote

On Windows 8.1 and 2012 R2 there is a maintenance scheduled task which should run Disk Cleanup for old updates in the background without user intervention. I think the computer needs to be on at that time.
This can be done manually by using the command lines:

dism.exe /Online /Cleanup-Image /AnalyzeComponentStore

dism.exe /online /Cleanup-Image /StartComponentCleanup

True, they take a while to complete.
I think the commands above work in Windows 10 as well.

Reply | Quote

🙂

Reply | Quote