Re: PSA: Somehow, without action from me, hyberfile.sys got turned on

Paul <[email protected]> Sun, 5 Apr 2026 06:42:46 -0400
Newsgroups alt.comp.os.windows-10,alt.comp.microsoft.windows
Organization A noiseless patient Spider
Message-ID <[email protected]>
On Sun, 4/5/2026 1:29 AM, Maria Sophia wrote:
> Zaidy036 wrote:
>>> Why else would you be running that failsafe catch-it-fast command?
>>
>> Not a problem I have experienced. Just a method if he wanted it off.
>>
>> I have a UPS and in case of power failure and it relies on Hyberfill to 
>> do a graceful shutdown before it stops running the attached items.
> 
> Well, almost every day something is failing because I have 3GB left on a
> 1TB drive, so it's "always something" because most Microsoft engineers have
> likely never tested in their lives a machine so deficient in storage as
> mine is (given they likely only ever work on beefy monster machines).
> 
> Yesterday it was Brave looping forever, today it was MsMpEng.
> It's like trying to find what killed a bug we stepped on with our foot.
> 
> If it's not one thing, it's another. 
> It turns out that hibernation was just one thing.
> 
> 1. Check free space
>    wmic logicaldisk where "name='C:'" get freespace
> 2. Check journal 
>    fsutil usn readjournal C:
>    Kill it immediately as it will literally go on forever.
>    Immediately means instantly. It will have a billion lines.
>    Instantly means within a microsecond, if you can catch it.
>    Otherwise it's too big to even copy a snippet.
>    This scan implicated Windows Defender (but that's just the symptom).
> 3. Identify the process writing the most:
>    Get-Process | Sort-Object -Descending -Property PM | Select-Object -First 20
> 4. Confirm it's Windows defender
>    Get-Process -Id 3960 | Select-Object Name,Id,IOWriteBytes,IOReadBytes
> 
>    Name      Id IOWriteBytes IOReadBytes
>    ----      -- ------------ -----------
>    MsMpEng 3960
> 
> But you can kill it (which can be done) and delete its files. 
>    MsMpEng.exe (Windows Defender)
>    Process ID: 3960  
>    Private memory: 360 MB  
>    Working set: 384 MB
> 
> But like hibernation,shadow storage, brave and everything else, it's just a
> symptom because Windows' self-healing is atrocious when space is so low
> that the journal shows a billion lines per second of file activity.
> 
> It's interesting how fragile Windows is when it's starved for C: space. 
> 

To start with, browser caches do not have to be on disk.
You can change the browser setting so the cache is in memory.

The result of this, is not having to clean out cache2 folder
every ten minutes :-)

You're an experienced user. You have no experience at
all doing filesystem housekeeping ? There are compression
tools. You can move materials into secondary storage, and so on.

*******

One thing I found, is Windows had some sort of "incident", it
wasn't a BSOD, but the OS tried to create a .dmp to hold
the entire memory space. It stopped, when it got... about
3GB from running out of RAM.

Scan your system and see if there are any dump files.
This also, may not be in cleanmgr.exe as an area needing cleaning.

Now, I just did my 25H2 and I haven't used sequoiaview to
see what kind of mess is in there. I've already used cleanmgr.exe
to remove Windows.old (as I have a backup of the whole disk, and
I've already restored three times until I got the blasted upgrade
installed).

In sequoiaview, I see that the .vhdx for Ubuntu has dropped from
10GB to 6GB (zeroing and compaction done by the automation),
so that must have happened during migration.

    [Picture]   This site has become pretty well hopeless now...

     https://i.postimg.cc/SNZnkDbH/Sequoia-View-Color-Mode.jpg

I just put my Downloads folder contents back, as to do the Upgrade
to 25H2, I had to make some space (sound familiar?), and I moved
22GB of Downloads over to another partition. Then, when Windows.old
was purged by cleanmgr.exe, I could copy those back.

Playing ping-pong with materials, is time consuming and a bore,
but it goes with the job.

   Paul