I asked Claude to help me write up my findings in my environment about why I think it's a Check Point issue, which I have pasted below. You can reproduce my steps in your environment.
1) Capture a memory dump of a hanging application on an affected user's computer- In Task Manager, right click the stuck application, click go to details, right-click the stuck process and choose Create Memory Dump file. It will probably be 1.5 GB or so but will zip to 25% of that size. Transfer it to your admin machine.
2) Load it into Debug Diagnostic Tool and run Crash Analysis. Compare it to what I've found. Do you see cphnt64.dll?
Environment
- Check Point Endpoint Security — issue reproduced on client 89.10, persisted after updating to 89.21
- Affected: Word, Excel, PowerPoint, Outlook — all four apps, across both physical laptops and hybrid-joined VMs
- Onset: correlates with Microsoft Office Current Channel build 16.0.20131.20090 (released ~6/25) — also confirmed on the subsequent 20131.20112 release, so both 2606 builds to date are affected
- OS: Windows 10, build 26200
Symptom:
Office applications become unresponsive intermittently — not a hard crash, a hang. No consistent user action triggers it; presents as a race condition (irregular timing, not reproducible on demand).
Root cause analysis:
Captured procdumps of hung processes for all four apps and ran them through DebugDiag 2's Crash/Hang Analysis. Three of the four (Outlook, PowerPoint, and an earlier Word capture) returned an identical automated finding:
Detected a serious critical section related problem
Lock at cphnt64!lvl+d808 is Uninitialized
Root cause function: cphnt64!CPH_InitHooks
Root cause module: C:\Program Files (x86)\CheckPoint\Endpoint Security\EFR\cphnt64.dll
Thread impact ranged from 15–25% of all threads blocked depending on the app. In each case, the blocked threads were waiting on a critical section inside cphnt64.dll that DebugDiag flagged as never having been properly initialized — classic deadlock-on-uninitialized-lock pattern.
A fourth dump (Excel) showed a related-but-distinct signature: an uninitialized lock inside ntdll!RtlpProcessHeaps rather than directly in cphnt64. Given that other thread stacks in our dumps show cphnt64's hook chain running through heap-related NT calls, we suspect this is a downstream heap corruption effect of the same underlying defect rather than an unrelated issue — but we don't have definitive proof of that link yet.
Why it hits all four Office apps identically:
cphnt64.dll is EFR (Endpoint Forensic Recorder) — it hooks low-level Windows API calls (NtClose, RegCloseKey, NtSetInformationFile, etc.) inside every monitored process for behavioral/ransomware detection. Since the hook is injected the same way into every Office process, a defect in its own internal locking manifests identically across Word, Excel, PowerPoint, and Outlook — they're not independently broken, they're all downstream of the same injected component.
What we ruled out:
- Stale AV definitions — tested on machines with both current and outdated definitions; hangs occurred on both, ruling out a signature-file issue
- Office add-ins — hang signature is consistent across machines with different add-in loadouts
- One machine had not received recent Endpoint policy updates and still hung, initially suggesting Check Point wasn't involved — this turned out to be a red herring; that machine had stale AV definitions but was still running the same EFR component
- Check Point client version — updated affected machines from 89.10 to 89.21; hangs continued with the identical CPH_InitHooks signature, ruling out a client-version-specific bug already fixed upstream
Mitigation attempted, and result:
We disabled Behavioral Protection → Anti-Ransomware Mode as an initial test. Hangs continued. New dumps taken after this change still show the identical CPH_InitHooks uninitialized-lock signature in Outlook and PowerPoint, meaning cphnt64.dll/EFR is still being loaded and initialized despite that blade being off. This strongly suggests EFR is shared infrastructure used by more than just the Anti-Ransomware feature (possibly Behavioral Guard more broadly, Anti-Exploit, or another blade) — we have not yet confirmed which other feature(s) are still invoking it.
Confirmed fix (workaround): Office rollback
Forcing an Office rollback to build 2505, deployed via the Office Deployment Tool (ODT) (not Cloud Update policy), eliminated the hangs entirely on machines where we tested it. Since the hangs persisted through a full Check Point client update (89.10 → 89.21) and only stopped after the Office rollback, this is strong evidence the trigger is specifically something introduced in the 2606 Office builds exposing a pre-existing EFR defect — not something already patched in 89.21. We have not modified any Check Point settings on the rollback-test machines; EFR/cphnt64.dll is fully active on them and they are stable at 2505.
Recommendation for others hitting this:
If you're on Office Current Channel build 16.0.20131.20090 or 20131.20112, and running Check Point Endpoint (89.10 or 89.21), and can tolerate holding back an Office update temporarily, an ODT-deployed rollback to build 2505 is a working stopgap while a permanent fix is developed. Updating the Check Point client alone did not resolve it in our environment. Note: Cloud Update policy rollback was not used/tested — we deployed the rollback via ODT specifically.
Open questions for Check Point / others hitting this:
- Is there a known defect in CPH_InitHooks's critical section initialization tied to this EFR/client build? Confirmed still present in 89.21.
- Which blades besides Anti-Ransomware Mode load cphnt64.dll? We need the full dependency list to know what else to try disabling as an alternative to a full Office rollback.
- Has anyone reproduced this on Office builds other than the two 2606 releases (20131.20090, 20131.20112)?
- Is there a newer EFR engine build (independent of client version 89.21) that addresses initialization races exposed by these Office builds?
TAC case open: 6-0004643260 — will update this thread as we get a response. Posting the technical detail here in case others are hitting the same thing and haven't gotten far enough to isolate the module.
