TR Forums

My wife's desktop is having a weird issue, and having been mostly out of the Windows world for a while I'm appealing to the collective gerbil wisdom for ideas here.

OS is Windows 7 Home Premium, 64-bit.

This started out as an exercise to figure out why she kept running out of disk space. The system has a 250GB SSD, and she kept getting into a state where there was 0 bytes free (causing the system to lose its mind). After several rounds of deleting old stuff and running Windows Disk Cleanup, the problem continued to come back every few weeks. The amount of space in use by all the top level folders (as shown by right-clicking and bringing up the properties) added up to just a little over 100GB, so there should've been a ton of free space.

I booted a Linux live drive, and determined that the Windows folder was the culprit; even though Windows claimed it had about 30GB of stuff in it, there was a Temp subfolder with ~140GB of crap in it. For some reason, Disk Cleanup Wizard isn't touching this stuff either (we've run that multiple times).

The bulk of the space is being taken up by files having names of the form cab_xxxx_xx, with a length of exactly 127837925 bytes and the exact same contents (looks like compressed data of some sort). The system has been creating one of these roughly 3 times/day, going back about a year.

So...

"Missing" space has been accounted for. I'm assuming I can just nuke these things. But why are they being created, and how do I get Windows to stop creating them?

On a more rhetorical note: 1) Why does Windows not include them in the total by default, when you ask it how much space is being consumed by the C:\Windows folder? We were able to get it to start including it in the total by clicking directly on the Temp folder, and confirming when asked to elevate to gain access to the folder; but hiding space usage of a potentially large folder by default just seems retarded. 2) Why isn't the Disk Cleanup wizard deleting these things?

I've seen this a whole bunch lately (last six months or so, probably three dozen machines), though I'm not really sure the exact cause.

Yes, it's perfectly safe to delete all these files. They're created by SFC having issues creating .cab files (I don't know what causes this part). I've thus far, found that deleting all the logs in the c:\windows\logs\cbs folder seems to prevent the issue from resurfacing.

I see the size issue from time to time, Windows has issues calculating the size of large folders and it just stops trying. Subsequent attempts on the same folder will sometimes kickstart it into working, though (I see this mostly on very large folders both by file count or size).

@Seeroftime - Thanks for the tip!

In this case, the size calculation issue appears to have been a permission thing. Would've been nice if there had been a warning to the effect of "couldn't calculate size of some sub-folders" instead of just silently excluding it.

I think you're spot on with the diagnosis of the "space eater" though: https://answers.microsoft.com/en-us/win ... 040c4eedfa (was able to find that using search terms based on your suggestion)

And there is indeed a really huge log file in the \Windows\Logs\CBS folder, dating back to around the timestamp of the oldest mystery file in Temp. I believe that is also the same general timeframe when this system experienced a HDD failure, so perhaps the large log was the result of excessive disk errors.

Not a problem!

Permissions, huh? I never thought about that even being possible, but I have seen it behave exactly that way before, now that you mention it. I agree, though, it would be nice if it said that it didn't have access to look at the files, so you knew that wasn't the end of it. I think disktective will show you the size even of those folders (though you may need to run as admin) if you run into something similar in the future.

Oh, that's interesting. I wondered if the excessive size of the logs would do that, but I've seen some die at a few hundred megabytes and a few die at a few gigabytes, so I never found anything concrete. Hopefully it's related to that failure, though, at least you can trace it back to something. Ours are new images, all in the past six months, and I suspect that whoever made these images left a few bugs in them, as I'd seen it once before June, when we reimaged every machine on property.

Ahh, and I see that you just signed up. So welcome to the TR forums!

Good gods this makes me glad I don't use Windows anymore or did MS fixed this with Windows 10? Since using smaller SSDs is very common to use for boot/OS drives among geeks, I would think MS would fixed this issue by now.

I haven't used the utility in Windows 7 for a while, but if you run the built-in Disk Cleanup utility and specifically right-click and choose the "run as administrator" option, you should see additional items listed, such as Windows Update temporary files and some other stuff. I believe you may have to manually choose that option even if you're already logged in as an admin.

whm1974 wrote:

Good gods this makes me glad I don't use Windows anymore or did MS fixed this with Windows 10? Since using smaller SSDs is very common to use for boot/OS drives among geeks, I would think MS would fixed this issue by now.

I've never even heard of it til now, so I'd be surprised if it was a win8 or 10 thing. (Both of them also self repair their filesystem, which could be related based on other posts.)

I'd be doing a clean install at that point just to be sure. You never really know if the fix is permanent or it's just going to happen again.

LostCat wrote:

whm1974 wrote:

Good gods this makes me glad I don't use Windows anymore or did MS fixed this with Windows 10? Since using smaller SSDs is very common to use for boot/OS drives among geeks, I would think MS would fixed this issue by now.

I've never even heard of it til now, so I'd be surprised if it was a win8 or 10 thing. (Both of them also self repair their filesystem, which could be related based on other posts.)

I'd be doing a clean install at that point just to be sure. You never really know if the fix is permanent or it's just going to happen again.

Well, I cleaned stuff out of the \Windows\Temp and \Windows\Logs\CBS folders. I will check in a couple of days to see if things look like they are back to normal. And if it starts happening again, at least I know where to look!

just brew it! wrote:

Ahh, and I see that you just signed up. So welcome to the TR forums!

Thanks! Been a long time lurker and have been thinking about joining for years, but never pulled the trigger until this morning, haha. Glad something finally made me join up.

Humorously, I just got finished helping another user with this exact problem. One thing I've noticed as well is that the makecab process likes to eat up a lot of your system power, either CPU cycles or disk IO while this is occurring.

I cannot say whether or not this is in Windows 8 or 10. We're nearly exclusively Windows 7 here, and the workstations that aren't never got touched. I run 7 pro at home as well and have not experienced this at all. I don't know for certain that it won't come back, but I can say that I have checked a few machines that I saw this on and it hasn't come back.

And yeah, there are other options if you run disk cleanup as an admin, exactly as The Egg said. If you have UAC on, I believe you have to run it as administrator, but if it is off, you don't. Typically there is a message if it isn't run as an admin, I believe.

And regarding fixing the issue, knowing how so many updates behave, it's entirely possible that this was recently broken by a bad update but takes a while to actually surface. I'd not heard of it in all my years working with 7, so I suspect some newly added functionality to the process of creating the cab files winds up breaking the whole thing in the right conditions.

Well, it looks like it has been lurking on this system for over a year, so I suppose that depends on the definition of "newly added functionality". (A year old is "new" in the context of Windows 7, I suppose...)

It took a number of months for it to cause visible symptoms in this case, and we only started to suspect something was seriously amiss when deleting multiple GB of unneeded user files and running the Cleanup tool only provided temporary relief. This led to the deeper investigation which indicated that ~140GB of disk space was MIA!

Mildly annoyed that it took loading a Linux live image to figure out that the Windows disk usage calculation was lying to me...

I'm on Windows 7 Pro in the office. Had to have IT take a look at what was eating up more than 100GiBs of space: .cab files.

I don't have admin permissions, so I couldn't clean them out myself. They certainly accumulated over the course of 5 years.

Things got tense for a while when I had less than a gig left.

titan wrote:

I'm on Windows 7 Pro in the office. Had to have IT take a look at what was eating up more than 100GiBs of space: .cab files.

I don't have admin permissions, so I couldn't clean them out myself. They certainly accumulated over the course of 5 years.

Things got tense for a while when I had less than a gig left.

If your system isn't using disk encryption and the boot options aren't locked down in the BIOS/EFI, you could've probably done what I did and used a live boot image to diagnose...

just brew it! wrote:

Well, it looks like it has been lurking on this system for over a year, so I suppose that depends on the definition of "newly added functionality". (A year old is "new" in the context of Windows 7, I suppose...)

It took a number of months for it to cause visible symptoms in this case, and we only started to suspect something was seriously amiss when deleting multiple GB of unneeded user files and running the Cleanup tool only provided temporary relief. This led to the deeper investigation which indicated that ~140GB of disk space was MIA!

Mildly annoyed that it took loading a Linux live image to figure out that the Windows disk usage calculation was lying to me...

I find to really quite strange that it took another operating system to diagnose and fix Windows problems.

whm1974 wrote:

I find to really quite strange that it took another operating system to diagnose and fix Windows problems.

It's not really that strange. It's easier to get "close to the metal", which can be useful for diagnostic/forensic purposes. In this case, it was the Linux NTFS driver's bypassing of NTFS permissions that led me to the "Aha!" moment. The actual fix was done natively in Windows once I knew what to look for, with a little help from Seeroftime's post.

just brew it! wrote:

Well, it looks like it has been lurking on this system for over a year, so I suppose that depends on the definition of "newly added functionality". (A year old is "new" in the context of Windows 7, I suppose...)

It took a number of months for it to cause visible symptoms in this case, and we only started to suspect something was seriously amiss when deleting multiple GB of unneeded user files and running the Cleanup tool only provided temporary relief. This led to the deeper investigation which indicated that ~140GB of disk space was MIA!

Mildly annoyed that it took loading a Linux live image to figure out that the Windows disk usage calculation was lying to me...

That's pretty much what I meant, new to Win7, or more accurately, functionality that wasn't in the initial release of whatever is actually breaking in the process. I was initially going to put newly in quotes, but so many people nowadays misuse quotation marks to denote emphasis that I opted not to in attempt to not throw anyone off.

My system at home hasn't had a reinstall since late 2008/early '09 and has not seen this issue at all, and I use it heavily (less so than 10 years ago, but still). However, the three dozen or so I've seen were all imaged in June and the image was created, new, in February (so we're told, that's not our department). I don't think the buildup is really time based. However, another application being the culprit is entirely possible. We used to use SCCM here, which caused issues with its initial deployment, then we stopped after figuring the issue out (it caused problems with WMI, and needed hotfixes that Microsoft didn't publish in Windows update). Something akin to this could be a likely cause as well. (Not necessarily SCCM, just citing an example).

whm1974 wrote:

Good gods this makes me glad I don't use Windows anymore or did MS fixed this with Windows 10? Since using smaller SSDs is very common to use for boot/OS drives among geeks, I would think MS would fixed this issue by now.

OS servicing is different in 10. For more details, contact MS. 7 really is reaching obsolescence day by day.

Seeroftime wrote:

However, another application being the culprit is entirely possible.

I was also thinking the imaging application could be causing issues that just don't come up in normal usage.

Oh, what a tangled web we weave...

My day job has been development for nearly all of my career, so I've seen a lot of crazy stuff, and can easily imagine how a mess like this came to be. I'd like to believe that my net effect has been to reduce software entropy by writing clean code and cleaning up other people's messes (the latter is something I seem to be reasonably good at, and consequently a task I've gotten stuck with at a few of my jobs), but I suppose I may not have always been 100% successful. People I worked with at my previous employers are still on friendly terms, so I think that counts for something!

just brew it! wrote:

Mildly annoyed that it took loading a Linux live image to figure out that the Windows disk usage calculation was lying to me...

Not sure why. There's no such thing as an suid in the Windows world. How exactly do you expect commands to bypass permissions when they always run with the privilege of the user?

Ryu Connor wrote:

just brew it! wrote:

Mildly annoyed that it took loading a Linux live image to figure out that the Windows disk usage calculation was lying to me...

Not sure why. There's no such thing as an suid in the Windows world. How exactly do you expect commands to bypass permissions when they always run with the privilege of the user?

Why couldn't it say, in effect, "Hey, these numbers may not be accurate since I couldn't access some of this stuff" instead of just reporting wrong data? Seems like common courtesy to me.

That would've led me to dig further into permissions on sub-folders, instead of going to the trouble of booting from a live drive.

Ryu Connor wrote:

just brew it! wrote:

Mildly annoyed that it took loading a Linux live image to figure out that the Windows disk usage calculation was lying to me...

Not sure why. There's no such thing as an suid in the Windows world. How exactly do you expect commands to bypass permissions when they always run with the privilege of the user?

Does Windows 7,8 and 10 have a Safe Mode anymore?

just brew it! wrote:

Why couldn't it say, in effect, "Hey, these numbers may not be accurate since I couldn't access some of this stuff"? Seems like common courtesy to me.

That would've led me to dig further into permissions on sub-folders, instead of going to the trouble of booting from a live drive.

You want to talk about common courtesy in a Windows versus Linux situation? Cause that's not gonna end well for Linux.

Ryu Connor wrote:

just brew it! wrote:

Why couldn't it say, in effect, "Hey, these numbers may not be accurate since I couldn't access some of this stuff"? Seems like common courtesy to me.

That would've led me to dig further into permissions on sub-folders, instead of going to the trouble of booting from a live drive.

You want to talk about common courtesy in a Windows versus Linux situation? Cause that's not gonna end well for Linux.

Yeah but many commands do have a verbose option.

whm1974 wrote:

Does Windows 7,8 and 10 have a Safe Mode anymore?

Yes, though it's a bit more convoluted to access it in 8 and 10.

Ryu Connor wrote:

just brew it! wrote:

Why couldn't it say, in effect, "Hey, these numbers may not be accurate since I couldn't access some of this stuff"? Seems like common courtesy to me.

That would've led me to dig further into permissions on sub-folders, instead of going to the trouble of booting from a live drive.

You want to talk about common courtesy in a Windows versus Linux situation? Cause that's not gonna end well for Linux.

Touche. But this seems like a particularly egregious offense on Windows' part. "Don't lie to the user" seems like a pretty simple rule. If you can't do something because of a permissions issue, at least tell me there's a permissions issue! Linux may be cryptic at times, but it generally bitches when it can't figure something out; good luck understanding what it is bitching about, but at least you know there's a problem so you don't trust the answer.

Aside: I did fall into the smoking crater that is Linux GPU drivers when I tried to boot the live image -- KDE desktop was barely functional. And this was an older Nvidia GPU, which really should've had stable in-tree support. I ended up hitting Ctrl-Alt-F1 and using the pure text console, since that was easier than figuring out whatever magic incantation was needed to fix the DE.

just brew it! wrote:

"Don't lie to the user" seems like a pretty simple rule. If you can't do something because of a permissions issue, at least tell me there's a permissions issue!

Welcome to the LOCAL_SYSTEM privilege layer.

Captain Ned wrote:

just brew it! wrote:

"Don't lie to the user" seems like a pretty simple rule. If you can't do something because of a permissions issue, at least tell me there's a permissions issue!

Welcome to the LOCAL_SYSTEM privilege layer.

psexec -i -s cmd.exe

Pretty much impossible to administer Windows Server without occasionally using this. Service having trouble with a mapped network drive? No way to see that as regular administrator.

WinDirStat seems to reliably bypass odd permissions issues if you run it as an administrator. Awesome little tool.