Solved

Aug 14, 2026

Windows 11 Freezes Exactly 5 Minutes After Boot but Works in Safe Mode: Secure-Boot-Update Fix

A Dell XPS 8700 running Windows 11 Pro hard-froze about five minutes after boot but worked in Safe Mode. Disabling the Secure-Boot-Update scheduled task stopped it.

Windows 11Secure BootDell XPS 8700UefiScheduled Tasks

I know this isn’t smart.

I know you’re not supposed to install Windows 11 on old hardware that Microsoft, Dell, and probably several sensible people have told you is unsupported.

You can, though.

And sometimes it works surprisingly well… right up until the computer works perfectly for almost exactly five minutes and then hard-freezes. No blue screen. No useful error. Mouse stops moving. Keyboard stops responding. The only way out is holding the power button.

Play stupid games, win stupid prizes.

In this case, the prize appears to have been the Windows Secure-Boot-Update scheduled task interacting badly with old UEFI firmware.

A little context before anyone mistakes this for responsible enterprise computing: this particular machine is going to be used by my kids for gaming. There is nothing important on it, the Windows installation can be blown away whenever necessary, and I am not particularly concerned if some future update means I have to reinstall it.

That makes me considerably more comfortable accepting an imperfect workaround.

You probably shouldn’t do this on a machine you actually care about.

Also, if BitLocker or Device Encryption is enabled, make sure you have the recovery key before experimenting with BIOS, UEFI, TPM, or Secure Boot settings. Those changes can cause Windows to ask for it.

Short version

The symptoms were unusually specific:

Windows 11 would hard-freeze about five minutes after every normal boot, but worked normally in Safe Mode.

On this machine, the freeze happened at roughly 5 minutes and 8 seconds of CPU uptime.

The workaround that fixed it was disabling this Windows scheduled task:

1
\Microsoft\Windows\PI\Secure-Boot-Update

You can disable it through Task Scheduler:

1
Task Scheduler Library
2
└── Microsoft
3
    └── Windows
4
        └── PI
5
            └── Secure-Boot-Update

Right-click Secure-Boot-Update and choose Disable.

Or, from an elevated Command Prompt or Terminal:

1
schtasks /change /tn "\Microsoft\Windows\PI\Secure-Boot-Update" /disable

That disables the scheduled task only.

It does not disable Secure Boot itself.

After disabling the task, the five-minute freeze disappeared.

One thing worth remembering: this is a Windows-managed scheduled task. I would not assume the disabled state will survive every future Windows servicing or feature upgrade forever. If the computer suddenly starts freezing five minutes after boot again following a major Windows update, this is the first thing I would check.

The computer

The machine involved was:

Dell XPS 8700
Intel Core i7-4790
AMD Radeon RX 5700 XT
Dell BIOS A14
Windows 11 Pro

The XPS 8700 predates Windows 11 by a considerable margin.

Dell lists Windows 7, Windows 8/8.1, and Windows 10 for the XPS 8700, but not Windows 11.

That does not necessarily mean Windows 11 won’t run.

It does mean that when something weird happens between modern Windows and decade-old firmware, I have forfeited some of my right to look surprised.

Symptoms and things I ruled out

A normal Windows boot would end in a hard freeze after about five minutes.

Very consistently.

Safe Mode, however, worked normally.

That distinction turned out to matter.

I also tried or ruled out:

Wi-Fi
Ethernet
Bluetooth
card readers
newer AMD graphics drivers
older AMD graphics drivers

Windows 10 had previously operated normally on the same hardware.

The graphics driver initially looked suspicious, especially because Windows Update installed an AMD driver automatically.

It wasn’t.

What the Windows logs showed

After forcing the frozen machine off and booting again, Windows recorded:

1
Kernel-Power Event ID 41
2
Event ID 6008

It also showed:

1
BugcheckCode = 0

There was no blue screen and no crash dump.

Event 41 and Event 6008 do not explain the original freeze. In this case, they mostly confirm the obvious: Windows did not shut down cleanly because I eventually held down the power button.

Thanks, Windows.

The more useful clue was what was missing. There was no normal Windows bugcheck or crash dump pointing toward a conventional blue-screen failure.

The Secure-Boot-Update task

The task that eventually became interesting was:

1
Task Scheduler Library\Microsoft\Windows\PI\Secure-Boot-Update

Microsoft documents Secure-Boot-Update as part of Windows’ Secure Boot certificate servicing.

Windows is transitioning PCs away from Microsoft’s older 2011 Secure Boot certificates and toward newer 2023 certificates.

This is not simply Windows replacing a file somewhere under C:\Windows.

Secure Boot trust information lives in UEFI firmware. Microsoft’s servicing process can involve updating UEFI variables containing Secure Boot keys and certificates.

In simplified form:

1
Windows boots
2
      ↓
3
Secure-Boot-Update runs
4
      ↓
5
Windows attempts Secure Boot certificate servicing
6
      ↓
7
Windows communicates with UEFI firmware
8
      ↓
9
Something about this old firmware becomes extremely unhappy
10
      ↓
11
Hard freeze

I cannot prove which individual firmware operation causes the hang.

It could involve a Secure Boot database update, certificate servicing, a UEFI variable write, or another part of the process.

What I can say much more confidently is that running this task was associated with the freeze, and disabling it made the problem disappear.

Why exactly five minutes mattered

A computer that freezes “sometimes” is miserable to diagnose.

A computer that freezes at almost exactly the same amount of uptime after every boot is practically leaving clues.

In this case, the machine repeatedly froze at around 5 minutes and 8 seconds.

That timing also appears in other reports.

A Microsoft Q&A thread titled “Windows 11 PC Freezes After Precisely 5 Minutes” describes remarkably similar symptoms:

Windows works normally for about five minutes
the machine completely freezes
Event Viewer provides little useful information
Safe Mode works
disabling Secure-Boot-Update stops the problem

One person in that discussion reported that manually triggering the task immediately reproduced the freeze. The original poster also noted a five-minute startup delay in the task configuration.

Similar reports exist for both Windows 10 and Windows 11.

That does not mean every Windows computer that freezes five minutes after boot has a Secure Boot problem.

It does mean that if you have this combination:

Windows freezes about five minutes after boot + Safe Mode works + no useful crash dump

then Secure-Boot-Update is worth investigating.

Secure Boot was already giving clues

This computer also had some interesting Secure Boot state information.

Windows reported:

1
UEFICA2023Status = NotStarted

TPM-WMI Event ID 1801 indicated that updated Secure Boot certificates had not yet been applied to the device firmware.

The system was also in Microsoft’s:

1
Under Observation - More Data Needed

classification.

Microsoft uses that classification for hardware and firmware combinations where it is still gathering Secure Boot rollout data.

That does not mean Microsoft has declared the hardware broken.

It means there is not enough evidence to treat this firmware configuration as one that can confidently complete the newer Secure Boot servicing process.

On a Dell from 2013 running Windows 11, this did not make me feel dramatically more adventurous.

The fix I actually used

I disabled only:

1
\Microsoft\Windows\PI\Secure-Boot-Update

Using Task Scheduler

Open Task Scheduler.
Open Task Scheduler Library.
Browse to Microsoft > Windows > PI.
Right-click Secure-Boot-Update.
Choose Disable.

Using the command line

Run an elevated Command Prompt or Terminal:

1
schtasks /change /tn "\Microsoft\Windows\PI\Secure-Boot-Update" /disable

I did not delete the task.

I did not manually change Secure Boot keys.

I did not disable Secure Boot in the BIOS.

Result

After disabling Secure-Boot-Update, the machine booted normally.

Five minutes passed.

Then six.

Then considerably more.

The complete AMD graphics driver stack remained installed and active.

Before the change, the freeze had been extremely repeatable. After the change, it disappeared.

That is considerably more convincing than the traditional troubleshooting method of changing six unrelated things, rebooting, and declaring victory.

My practical conclusion is:

The Windows Secure-Boot-Update task was triggering the freeze on this machine, most likely because of an incompatibility between current Secure Boot certificate servicing and the older Dell UEFI firmware.

I cannot identify the exact low-level firmware operation that hangs the machine, so I’m not going to invent one.

This is not exclusively a Windows 11 problem

My computer is running Windows 11 on hardware that was never designed or supported for Windows 11.

That almost certainly doesn’t help.

However, similar Secure-Boot-Update freezes have also been reported on older computers running Windows 10.

So the broader issue appears to involve older hardware or firmware encountering newer Windows Secure Boot certificate servicing.

Running Windows 11 on unsupported hardware is one particularly entertaining way to encounter that combination, but apparently not the only one.

What about disabling Secure Boot instead?

Some people with similar symptoms report that disabling Secure Boot in the BIOS or UEFI also stops the freezing.

That is plausible.

Microsoft says devices with Secure Boot disabled do not receive the new Secure Boot certificates in firmware.

Windows 11 can also run with Secure Boot turned off. Microsoft’s Windows 11 requirement is that a computer be Secure Boot capable, not necessarily that Secure Boot remain enabled at all times.

But that is not the workaround I used.

I prefer the narrower change.

Disabling:

1
Secure-Boot-Update

leaves Secure Boot itself enabled and retains the protection provided by the machine’s existing Secure Boot trust configuration.

Turning Secure Boot off disables that boot-time verification entirely.

Microsoft specifically recommends not disabling Secure Boot just because a device cannot install the newer certificates. Leaving the existing Secure Boot configuration intact is more secure than turning Secure Boot off altogether.

So while disabling Secure Boot has been reported as another workaround, I did not test or implement that solution on this machine.

There is a tradeoff

Secure-Boot-Update exists for a reason.

Microsoft’s older Secure Boot certificates are expiring, and Windows is moving systems to newer certificates so future boot components and revocation protections can continue to be trusted.

Disabling this task prevents that servicing from progressing.

Microsoft says a machine that cannot install the newer certificates does not suddenly stop working. The concern is a gradual loss of future boot-level security protections.

For a normal, supported Windows computer that contains important data, I would want to solve that properly.

This is not that computer.

This is an old Dell that my kids are going to play games on until somebody installs enough Minecraft mods to make reinstalling Windows seem easier than finding the problem.

The machine will probably be wiped repeatedly.

There is nothing irreplaceable on it.

If a future Windows upgrade breaks it, I will reinstall it.

That makes the tradeoff acceptable to me, for this machine.

It should not be mistaken for general advice to disable Windows security servicing on computers you actually depend on.

BitLocker and BIOS changes

Disabling the scheduled task itself should not require changing the firmware configuration.

That is another reason I prefer it over experimenting directly with Secure Boot.

However, if you decide to troubleshoot further by:

updating the BIOS or UEFI
resetting TPM settings
changing Secure Boot configuration
enabling or disabling Secure Boot
modifying Secure Boot keys

make sure you have your BitLocker or Device Encryption recovery key first.

BitLocker uses the TPM and measurements of the trusted boot environment to determine whether the machine still looks like the machine it encrypted.

Firmware, BIOS, UEFI, and boot-configuration changes can cause BitLocker to enter recovery mode and request the recovery key on the next boot.

Losing access to an otherwise healthy Windows installation because you were trying to fix a five-minute freeze would be an impressive escalation.

Check it again after Windows updates

Because Secure-Boot-Update is a Windows-managed task, I would not assume this workaround will remain untouched forever.

I could not find authoritative Microsoft documentation saying that every Windows feature update specifically resets this particular task from disabled to enabled.

So I would not make that claim.

But major Windows servicing and feature upgrades can replace or recreate system components and tasks.

The practical rule is much simpler:

If the five-minute freeze ever returns after a major Windows update, check Secure-Boot-Update first.

Look here:

1
Task Scheduler Library
2
→ Microsoft
3
→ Windows
4
→ PI
5
→ Secure-Boot-Update

If it is enabled again, you have a very good place to start.

Re-enabling the task

If I eventually want to test whether the underlying problem has been fixed, I can re-enable the task through Task Scheduler.

Or:

1
schtasks /change /tn "\Microsoft\Windows\PI\Secure-Boot-Update" /enable

At that point I would expect the five-minute freeze to be possible again unless something in Windows or the firmware has changed.

Given the age of this particular Dell, I am not holding my breath on the firmware part.

The actual lesson

Yes, you can run Windows 11 on a lot of computers Windows 11 was never supposed to run on.

Most of the time, it works considerably better than it has any right to.

Sometimes you end up debugging a modern operating system trying to replace Secure Boot certificates inside firmware designed when the PlayStation 4 was new.

And then the computer freezes every five minutes.

Play stupid games.

Win extremely precisely timed prizes.

Sources and further reading

Microsoft documentation

Similar reports

These are community reports rather than authoritative documentation, but they helped confirm that this wasn’t just one particularly creative Dell.