Several HP Windows PCs started blue-screening after a recent update. The EFI System Partition appears full on affected devices. Is that likely related, and what would you check before trying to clear or resize it?
Could a full EFI partition be causing these HP update blue screens?
Asked by
kiln__Fox
Answers
A nearly full EFI System Partition is a plausible cause, especially if the update needs to add or replace boot files. But the timing alone does not prove it is the cause. Check the stop code, update history, and available space on affected machines, and compare with devices that updated successfully.
Be careful with scripted cleanup. The partition contains boot-critical files, so removing the wrong files can leave a machine unable to start. Use a supported procedure for the specific Windows and device configuration, and test it on a recoverable machine before deploying broadly.
Reply to this answer
If the EFI partition is genuinely out of space, increasing its capacity may be a more durable fix than repeatedly deleting files. First confirm the partition layout and whether there is adjacent unallocated space. Resizing can be awkward when other partitions sit between it and free space, so do not assume a single command or script will work safely on every model.
Test the exact process across the different disk layouts in your fleet, back up important data, and make sure recovery media is available. The update may have exposed a sizing problem, but confirm the failure mechanism before treating partition size as the only explanation.
Reply to this answer
I would also check whether the update involves Secure Boot certificate changes or requires a firmware update. Those were raised as possible factors, but they are separate from the EFI space issue and should not be treated as confirmed causes without checking the release details and the affected machine's firmware state.
Compare the update and firmware status on one affected device and one unaffected device. That gives you a better lead than changing boot partitions first.
Reply to this answer
Keep the response narrow at first. Pick one failed device, record the exact error, and try the least disruptive supported recovery option. Some reports described recovery through System Restore and a retry, while another device needed reimaging, so results may differ.
Once you know which systems share the same partition layout or firmware, you can decide whether a targeted repair is enough or whether a broader change is justified.
Reply to this answer
Add your answer
Answers are reviewed before publication.
kiln__Fox:
That makes sense. I will verify the stop codes and test on a machine with a recovery path before changing the fleet.