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

On 4/1/2026 12:36 PM, Maria Sophia wrote:
> ...He wrote:
>> For Win10 22H2, Windows Defender updates use the servicing stack but
>> that use is only by checking the presence of a Servicing Stack.
>> For Windows 10 any Serving Stack successfully installed after Sept 2025
>> is sufficient for Windows Defender to update its engine and defs. Even
>> if ESU has been enabled , the Sept. 25 as a mininum is still sufficient.
>> If ESU has been enabled, the most recent monthly cumulative update
>> provided by ESU would have installed the latest servicing stack.
>>
>> Windows Defender's installation of its engine or defs does not instruct
>> Windows Update to update the Servicing Stack or cause a power policy reset.
>>
>> i.e. The hypothesis that a serving stack power policy reset was
>> triggered during a Defender update is false.
>>
>> Something else, user controlled - managed or changed or tampered has
>> occurred.
> 
> Hi Winston,
> 
> Thanks for debugging that hypothesis for where the ghost is in Windows.
> The ghost exists. But I don't know where or how it enabled hibernation.
> 
> Yet.

I don't debug your statements especially under the hood Windows 
possibilities without having first checking with contacts and old 
friends in Bellevue.

I presented your earlier theory to a private mailing list of admins and 
'Softies'

A few responses
  -"Thanks for today's humor"
  -"Fixed in 2016, not possible since 8.1"
  -"Wow, pebkac"
  -

More for the following
>   1. Maintenance Phase Resets
-"Fixed in 20H2"
>   2. Modern Standby/S0 Transitions
-"Most likely user caused"
>   3. Corruption Recovery
-"User has bigger problems than Hibernation"
> 
> Maintenance Phase Resets:
> When the Update Orchestrator runs its "System Health" or "Remediation"
> tasks (at times which are bundled with monthly reliability rollups), it
> validates key system files. On older ACPI-compliant hardware, if the OS
> detects a power configuration it deems "incomplete" (such as missing the
> Fast Startup requirements), it possibly might "repair" the state by
> reverting HibernateEnabled to 1. I think.
> 
> Modern Standby/S0 Transitions:
> Even on older systems, certain Windows 10 updates may attempt to bridge
> legacy BIOS power states with Modern Standby logic. If a driver update
> (like an Intel Management Engine or ACPI driver) occurs via Windows Update,
> the installer script may possibly resets the power provider to defaults.
> 
> Corruption Recovery:
> If the registry hive containing the power settings hits a write error,
> perhaps Windows reverts to the System default hive, where hibernation is On
> by default.
> 
> I'm not sure which (if any) of those happened.
> I'm only sure that I didn't overtly touch the hibernation settings.

Unlikely any of them happened on Win10 22H2(with or without ESU) without 
user intervention and/or hardware related failure.
> 
> To say it can't happen because it isn't intended to happen works fine in a
> perfect environment, but there is always the reality of "Self-Healing"
> scripts that Microsoft can use (and which Paul himself had alluded to).
> 
> I just ran this debug command which is useful likely for everyone here:
> PS C:\> Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Kernel-Boot'; Id=27} | Select-Object TimeCreated, @{N='BootType'; E={$_.Properties[0].Value}}
> 
> The results indicate no transition to a Hybrid Boot state, so the
> hyberfile.sys was not created by a user changing power settings or a "Fast
> Startup" toggle.

Fast Startup does require hibernation's feature to be active, but it 
does not(nor has it ever) been capable of enabling hibernation for user 
sessions(any and all Windows logon accounts - MSA or Local) without user 
having independently enabled hibernation(powercfg /h on).
> 

> I'm guessing (from the dataset) but since hiberfil.sys was recreated but
> the BootType remained 0, it probably wasn't a "Fast Startup" event.

See above, when powercfg /h off, Fast Startup does not apply.
> 
> Instead, it was most likely a "Live" System Change where something
> triggered the HiberbootEnabled registry value to reset to 1, which
> commanded the kernel to reserve that hyberfile.sys disk space.

Possible when 'powercfg /h on' has been done <= user induced

-- 
...w¡ñ§±¤ñ