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

...Winston wrote:
> 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


Hi Winston,

Like you, I have decades of experience working with developers in the
Silicon Valley on million-dollar software far more complex than Win10.

Like most people here, I have thousands upon thousands of successful
product change requests (i.e., bugs and enhancements) to that software.

Given your contacts up in Redmond, I thank you again for taking the effort
to research & the time to respond. I appreciate the clarification about how
the Servicing Stack and Defender updates behave on 22H2/ESU systems.

Where we differ is not on the intended behavior of Windows, but on the
observed behavior on this specific machine which is highly customized.

As you are well aware, Windows is almost unusable out of the box for power
users who customize almost every aspect of the operating system setup.

Here are the facts that I can demonstrate and have demonstrated so far.

1. Hibernation had been disabled for years.
   "powercfg /a" and the absence of hiberfil.sys confirm that state 
    across hundreds of cold boots.

2. The BootType history shows no Hybrid Boot events.
   Every Kernel-Boot event (ID 27) for the past ~6 months is BootType 0.
   That rules out:
      a. Fast Startup
      b. user-initiated hibernation
      c. any boot-time mechanism that would recreate the file

3. Yet hiberfil.sys was recreated anyway.
   And it happened while the system was live, not during a boot transition.

4. Therefore, something in the running OS re-enabled hibernation.
   This is not speculation. This is not guessing. 
   It is the only conclusion consistent with the logs.

I am not asserting a specific mechanism with certainty. 
But I am asserting that the "only possible cause is user tampering"
explanation is contradicted by the dataset.

5. There are known Windows behaviors that can reset power policy:
   Whether or not they apply here, Microsoft has documented several 
   mechanisms that can revert HibernateEnabled to 1 on legacy hardware:

      a. Maintenance / Remediation tasks
         System Health scripts can restore missing default power states.

      b. Driver or ACPI transitions
         Some update installers reset the power provider to defaults.

      c. Registry hive recovery
         A write error can cause Windows to fall back to the default hive,
         where hibernation is ON.

I am not claiming any one of these did occur. Only that Windows does have
non-user pathways that can re-enable hibernation (and most likely did).

6. The logs rule out the usual suspects.
   So the question is not "should Windows do this?"
   The question is "what in Windows did this on this machine?"

I am continuing to investigate, but the evidence so far shows:

      a. hibernation was off
      b. no hybrid boots occurred
      c. the file was recreated live

Therefore, Occams Razor tells us something in the OS changed the state.
If/when I find the exact trigger, I will post it for the group.

Note that Paul has experienced changes in the file size while Zaidy has
clearly experienced something causing him to turn it off constantly, so
even in this tiny group of Windows 10 experts, it seems to happen here.