topic Re: E89.25 Preboot-Loop in Endpoint

E89.25 Preboot-Loop

FloydG — Fri, 14 Aug 2026 07:30:20 GMT

Dear CheckMates,

I could not find any knowledge articles related to this issue.

We started installing E89.25 on over 100 devices last week. We are upgrading from E89.05 with preboot and FDE enabled.
Before the rollout, we ran the 'BootModeReport.ps1' script mentioned in SK185123. Everything was correct.

However, four of the 100 devices were unable to boot after the upgrade.
The preboot literally loops: Login screen -> Entering credentials -> Login screen...
Windows won't appear, no matter what we do.

Tweaking the BIOS settings, such as disabling secure boot, doesn't change the behaviour. Selecting various entries in the boot menu had no effect either. The only way we found to boot Windows was to decrypt the entire drive using a recovery USB. Then we noticed in Windows that Endpoint hadn't upgraded to E89.25. We need to uninstall E89.05 and then start with E89.25.

This issue is problematic/deadlock for remote workers.
We paused rollout for now.

Has anyone experienced the same issue and found an easier solution?

OS: Windows 11 24H2
Device: Dell Latitude Series
UEFI 2023
Secure Boot State: InProgress (E89.25 is required for it to succeed).

Re: E89.25 Preboot-Loop

Chris_Atkinson — Mon, 17 Aug 2026 07:59:44 GMT

Are you familiar also with sk185067 and are you already discussing with Support?

Re: E89.25 Preboot-Loop

FloydG — Mon, 17 Aug 2026 09:58:33 GMT

I don't think sk185067 apply for our issue, since we do not face BSOD/RSOD or similar.
And since we move to E89.25, those issues should be fixed:

"Workaround

Note: This issue has been fixed in Endpoint Security Client 89.25, For more information, see sk184929.
This workaround is only required for devices running versions earlier than 89.25."

Not support case open yet.

Re: E89.25 Preboot-Loop

Benjamin_John — Mon, 17 Aug 2026 12:23:52 GMT

Running into a similar scenario.

We are upgrading to E89.25 using SCCM. Some of the machines are failing the upgrade with "Product: Check Point Endpoint Security -- Error 26801.Failed to stop driver (vsdatant). Restart of the computer may help to resolve this issue."

After rebooting, it appears 89.25 is installed (per the version number shown on the pre-boot screen). When trying to login at the pre-boot screen, the laptop just cycles back to the pre-boot screen repeatedly.

I wasn't aware of SK185123, but I'm pretty sure our machines are all on BCDBOOT.

I did open a support case, but I don't think I'm going to get anywhere with the tech....

23H2

Dell

Re: E89.25 Preboot-Loop

FloydG — Mon, 17 Aug 2026 13:36:26 GMT

Good to hear. Please let me/us know when support replied.

Re: E89.25 Preboot-Loop

Benjamin_John — Mon, 17 Aug 2026 14:06:28 GMT

Don't really think my case is going to get resolved. Support basically said to make sure I'm following best practices.

We also encrypt our desktops (no pre-boot screen). On desktops where the failure happened, it's stuck at the "Secured with Dell SafeBios screen"

Precision 3460.

My laptop which it happened on was a Precision 3581.

Re: E89.25 Preboot-Loop

FloydG — Mon, 17 Aug 2026 14:14:12 GMT

Whats your fix/workaroud? Also decrypt entire drive?

Re: E89.25 Preboot-Loop

Benjamin_John — Mon, 17 Aug 2026 14:53:12 GMT

Most likely, haven't got that far yet.

Is there anyway to find out if you are getting the same upgrade error? Should be listed in the application log on the failed machine.

I noticed that if I try to re-run the application (sccm) after the failure, (but before the reboot) it upgrades without issue.

Re: E89.25 Preboot-Loop

jorgeluiznim — Mon, 17 Aug 2026 16:51:35 GMT

With the E89.25 release notes (sk184929) this comes together, and it points to a specific cause rather than boot mode alone.

Root cause (sk184929, item EPS-63819). Starting with E89.25, FDE only supports devices that boot Windows through the standard UEFI boot order. Devices that load the Windows Boot Manager directly are not supported until the manufacturer provides a BIOS/UEFI update, and on those devices the FDE upgrade is blocked. That lines up exactly with the sk185123 symptom “the firmware does not start the Check Point pre-boot environment”, which is the preboot loop you are seeing.

Key point for the units that passed BootModeReport but still looped: the BootModeReport tool (sk185123) reads the boot mode recorded by FDE. A device can report Compatible (BCDBOOT) and still be one of the firmware configurations that E89.25 no longer supports per EPS-63819. So a clean BootModeReport does not rule this out.

@FloydG (your 4 Dell Latitude / UEFI 2023 units):

Update the Dell BIOS/UEFI to the latest on the exact failing models and re-test. This is the action Check Point calls for on firmware-affected devices, and sk120667 also notes that some Dell/HP/Lenovo UEFI firmware do not honor third-party bootloaders.
Check whether your deployment uses FAST_INSTALL or ATM mode (isATM=1). sk184929 warns this can render the device unbootable and require the FDE USB recovery procedure, which is what you had to do.
For firmware that is not yet compatible, E89.25 is designed to raise a Blade Status message asking for admin consent to move those specific machines from Check Point Encryption to BitLocker Management until the firmware is fixed. Worth checking if that message appeared in your console.

Hibernation + Secure Boot (you have Secure Boot “In Progress”). Per sk185067, the Microsoft Secure Boot certificate updates (KB5062713 / KB5087420) rewrite bootmgfw.efi, and if a device hibernates mid-process the EFI System Partition can be corrupted and the device fails to boot. The E89.25 release notes list disabling hibernation as a required action during the Secure Boot update. On affected FDE devices:

powercfg /h off
powercfg /a   (confirm Hibernate is not listed as available)

@Benjamin_John (SCCM, Error 26801 “Failed to stop the driver (vsdatant)”): that is the upgrade failing to unload a driver, so it half-applies and the reboot lands in a bad state, which matches your finding that re-running the install before the reboot completes it cleanly. sk184929 lists a related fix (AHTP-33884, the cpepmon.sys minifilter not unloading), but vsdatant is a different driver, so I would:

Clear any pending reboot before starting (26801 is classic for a locked / pending-reboot driver).
Do not force the reboot on a failed or partial install. Gate the reboot on the Check Point install returning success and the client actually reporting 89.25 in Windows, not just the preboot banner.
Use BootModeReport in silent mode as a pre-check in the task sequence and hold any device that is not exit code 0:
```
powershell -ExecutionPolicy RemoteSigned -WindowStyle Hidden -File .\BootModeReport.ps1 -Silent

0 = Compatible   1 = Incompatible   3 = Unknown   4 = FDE-managed BitLocker
```
(keeping in mind Compatible still does not guarantee EPS-63819 firmware support).

Recovery for already-stuck units. A full decrypt via USB recovery works but is heavy. If you only need data off a unit, the FDE Drive Slaving Utility unlocks the disk from another Check Point machine using the recovery file, without decrypting the whole drive. To get a unit booting again, since the client is half-upgraded, the clean path is the one you found: decrypt, uninstall 89.05, clean install 89.25. On firmware that is not yet supported, the expected end state is BitLocker Management until the OEM BIOS update lands.

For TAC: open a case on the failing units referencing sk184929 (EPS-63819), sk185123 and sk185067, with the upgrade log (the 26801) and the FDE logs attached. Ask directly whether your specific Dell models are on the “not supported until firmware” list and what the Dell BIOS timeline is, since the units that pass BootModeReport but still loop are most likely stuck there.

Hope this helps narrow it down.

Re: E89.25 Preboot-Loop

Benjamin_John — Mon, 17 Aug 2026 21:03:21 GMT

I can confirm that we have the latest BIOS installed and using BCDBOOT.

It happened on my Precision 3581 which had the latest BIOS.

Not forcing a reboot either, but can't control when the user may reboot. We would have to keep watching the SCCM status every minute to see which machine failed and re-run the install.

Re: E89.25 Preboot-Loop

FloydG — Tue, 18 Aug 2026 08:58:56 GMT

Hi. Thanks for detailed instructions.

- The affected devices have current BIOS, since we keep them all on the same version. There are plenty with same BIOS version and Dell model who went through upgrade without issues.
- BootModeReport says compatible on the failed devices.
- Hibernation/standby is disabled on all devices by policy.
- We are not using FAST_INSTALL or ATM-Mode. Just the initial client and typing server address manually.
- We do not use SCCM etc. - we push updates by SmartEndpoint

Regarding secure boot and certificate changes, I am confused if this really match our issue, because: Decrypting the disk will fix the boot procedure. Decryption won't fix "bootmgfw.efi" on their own, right? After decrypting we should face BSOD, boot errors etc., but not a working windows system.

@Benjamin_John - I checked the log you mentioned:

Product: Check Point Endpoint Security -- Error 26801.Failed to stop driver (vsdatant). Restart of the computer may help to resolve this issue.
Product: Check Point Endpoint Security -- Installation operation failed.

Shorly after, the device is restarting. And there we go with loop.
When we talk about preparing the upgrade (clear pending reboot, do not force...), I am disappointed about the Endpoint Client not taking care of it. As I mentioned, we upgrade by automatism from server/client, NOT sccm.

Re: E89.25 Preboot-Loop

Benjamin_John — Tue, 18 Aug 2026 12:37:30 GMT

@FloydG At least our errors match up even though I'm doing it thru SCCM and you are doing it thru the console.

It looks like the install fails and leaves FDE in a bad state/partially installed after reboot.

I noticed that the Check Point Full Disk Encryption and Windows Boot Manager are missing from the boot menu after the reboot.

CheckPoint needs to fix this mess!

Re: E89.25 Preboot-Loop

jorgeluiznim — Tue, 18 Aug 2026 13:25:25 GMT

Thanks both, that narrows it down a lot, and it changes my read. Given what you have ruled out (latest BIOS on the same model that upgrades fine elsewhere, BootModeReport Compatible, hibernation disabled, no FAST_INSTALL or ATM, and it happens on both the SmartEndpoint console path and SCCM), I would drop the firmware and the Secure Boot / ESP angle for your case.

@FloydG your logic is right: if decrypting yields a working Windows rather than a BSOD or boot error, then bootmgfw.efi is not corrupted, so this is not the sk185067 ESP-corruption path. The OS boot chain is fine, it is the FDE / preboot layer that is left in a bad state.

The signature that now lines up across both of you is the real lead:

Product: Check Point Endpoint Security -- Error 26801. Failed to stop the driver (vsdatant). Restarting may help...
Product: Check Point Endpoint Security -- The install operation failed.
(device reboots, then the preboot loop)

So the upgrade aborts when it cannot stop the vsdatant driver, the machine reboots with FDE half-applied, and the boot entries end up broken. @Benjamin_John your observation that both the Check Point Full Disk Encryption and the Windows Boot Manager entries disappeared from the boot menu after the reboot is the mechanism of the loop: the failed upgrade tore down the boot entries and did not put them back.

Here is the angle I would take to TAC, because I think it points at a specific defect. The E89.25 release notes (sk184929) list this as resolved:

AHTP-33884: Resolved an issue where upgrade or uninstall could fail because
the cpepmon.sys minifilter driver did not unload successfully.

You are hitting the identical pattern, but with vsdatant instead of cpepmon.sys. That strongly suggests the same “driver fails to unload during upgrade” defect class was fixed for one driver and not the other. I would quote AHTP-33884 and your 26801 vsdatant log to TAC and ask directly whether there is a hotfix or an open bug for the vsdatant unload-on-upgrade failure on E89.25. The intermittency (same model and BIOS, some succeed) fits a driver-unload race rather than anything environmental.

One concrete way to pin this down, since the model and BIOS are identical and some machines pass: grab a cpinfo from a machine that upgraded to 89.25 cleanly, and a cpinfo from one of the failed machines after you recover it, then compare the two. With the hardware and BIOS matching, the delta is where the answer most likely is (driver and service state, pending operations, FDE state, registry). It also hands TAC a clean good-versus-bad pair to work from. The Check Point CPInfo Analysis MCP (@chkp/cpinfo-analysis-mcp) is handy for pulling the health, service and config details out of those side by side.

On the “the client should handle pending reboots itself” point @FloydG , I agree, and since you upgrade from the server/console rather than SCCM you do not have an easy pre-check gate. As a stopgap only, a clean reboot right before the client pulls the upgrade lowers the odds of the driver being in a state it cannot stop, but that is a mitigation, not a fix, and the client should be doing this.

For the units already stuck, the decrypt, uninstall 89.05, clean install 89.25 path you found is the reliable recovery. @Benjamin_John since your boot entries vanished, from WinRE you can sometimes rebuild the Windows Boot Manager entry with bcdboot before reinstalling, but the clean decrypt and reinstall is the safer route.

Net: for your environments this reads as a client-side vsdatant unload-on-upgrade failure, not firmware or Secure Boot. A good-versus-bad cpinfo comparison plus the AHTP-33884 parallel is what I would put in front of TAC.