HDD GURU FORUMS

(This happens on a SSD but might be relevant on HDD too. It's been "touched upon" but I haven't seen a definitive answer. It might be something pretty basic...)

I'm running Win 7-64 Ultimate. My boot drive (e.g. C: - the one with the "issue") is a 256G SSD. I had another issue to which I did a boot trace (WPR/WPA) which generated a large file on the C: drive (~40G). It pretty much filled up my C: drive (e.g. SSD drive). I've deleted it along with some other unneeded large files as I solved my initial problem - the one that necessitated the WPR/WPA boot trace. The trace files are too large to go into the trash so I just permanently deleted them as I have no need from them. I get the free disk space (File Manager --> C: --> Properties) and all is well...

... until I re-boot. The (large) files have reappeared thereby "choking" my system due to the full C: drive; that necessitates another deletion which works just fine until my next re-boot ... (ad infinitum)

If it matters, the SSD is a Samsung 840 Pro (again, 256Gb); I haven't had any other issues with it.

Not that this is relevant but the System Event Log shows a somewhat cryptic (at least to me) message/error during boot: Volsnap (eventid 35) The shadow copies of volume C: were aborted because the shadow copy storage failed to grow.

I'm not running any virtual machines. The boot trace is "turned off".

Any thoughts? (just want those trace/log files on the C: drive to "go away forever"/really get deleted) - Thx.

I had something like that happen quite a while ago. Just looked up what was the cause in my case:

The problem is solved, and I am embarrassed to reveal the cause. I
have Synchback SE set to periodically mirror a number of directories
and files between drives, including the directory containing the files
and folders that refused to stay deleted. The settings I had used,
called for files missing from the destination to be replaced with
copies from the source, and vice versa, which is the essence of
synchronization. I've changed that to do nothing for files missing
from the source, which makes it a backup, not synchronization, job.
<Blush>

Well, the problem has been solved but...

First, thank you for the suggestion. I'm not running Synchback or any sync software (at least I don't think I am) but I did another thorough search of the running processes and startups (via msconfig & autorun) and nothing stood out. It was a good suggestion as it most certainly could have been something of that ilk.

What happened and "worked": The short answer is "I don't know exactly what fixed it but it's fixed". I went though yet another (many) re-boots and every time the SSD filled to capacity with the trace file - I want to say it was a 46Gb file! My usual work-around is to delete it and the C: drive (with the subsequent extra 46Gb of free space) is just fine until the next boot. I noticed that the timestamp of the log/trace file was "at the time of the boot" and not some previous date/time (e.g. when it was originally created). I got in to XPERF (a somewhat cryptic command line utility) and WPR (Windows Performance Recorder) and "entered a few commands" (de-checked all boxes in the graphic interface although there is no button to save that information so I'm not sure it did anything). I stopped the hash table recording in XPERF and tried other options with subsequent error messages. Now I boot and there are no trace files generated; my C: drive has that 46Gb of headroom. Sorry - I just don't know what it was that stopped it (or what was causing it in the first place).

Note that there was no option to de-install (remove program) for XPERF or WPR/WPA. Also, I never saw any process/task queued up/running (via msconfig or autoruns or any task manager) so I have no idea on what kicks it off and as such how to stop if from running as such. I also don't know what was in the enormous trace file (I'd suspect it was an appended file across multiple boots and not a new from scratch one but I can't verify that) as I couldn't run the analyzer as I got choked out due to disk space. If it was building upon the old/deleted file, I don't know how it did that.

I hope that this helps somebody in the future. I'm certain that there are some/many significantly more competent than I am at using XPERF and WPR/WPA; right now I'm not looking to become an "expert". Suffice it to say that XPERF & WPR are idiosyncratic...

Well, glad you got it fixed, in any event. I hate it when that happens to me (don't know what fixed it). I've had customers who had inadvertently set up Norton Backup to back up to the c: drive. Filled it right up and kept it filled. Doesn't sound like a candidate in your case.

Thanks Larry -

The good news is that it's fixed...