Oct 2026 Windows update issue (KB5126646) – LSASS Semaphore handles still climbing after EpmapSavedContextCap fix. Normal?

Environment: 2-node DAG, Exchange SE (SU11), Windows Server 2025 with KB5126646, hybrid with EXO.

We hit the known issue twice (\~24h apart): MapiExceptionMdbOffline (ec=1142), Win32 0x6D8, DBs showing "Mounted" but Test-MAPIConnectivity failing, queues stuck to the DBs, passive copies going Failed. A reboot fixed it temporarily each time.

While troubleshooting I noticed lsass.exe handles were very high at the time of failure:

\- Active node: \~44,000 handles

\- Passive node: \~37,000 handles

handle64 -s -p lsass.exe shows almost all of it is Semaphore handles (\~27,000 Semaphore out of \~32,000 total).

Today I applied Microsoft's workaround on both nodes:

reg add "HKLM\\SOFTWARE\\Microsoft\\Rpc" /v EpmapSavedContextCap /t REG\_DWORD /d 65536 /f

\+ reboot (proper DAG maintenance mode). Value confirmed 0x10000.

After the reboot, the LSASS Semaphore count is still climbing at about the same rate as before the fix:

\- 14:33 – Semaphore 7,433 (total 12,324)

\- 14:36 – Semaphore 8,251 (total 13,205)

\- 14:44 – Semaphore 9,975 (total 15,016)

Roughly 200–340 per minute during business hours.

Questions:

1. Has anyone else seen the LSASS Semaphore handle growth with this issue? Does it keep growing for you after the EpmapSavedContextCap fix, or does it level off?

2. Is this growth actually what leads to the Store outage, or is it a separate side effect and the registry fix addresses the real failure (endpoint mapper) regardless?

3. For those who had to raise the limit further – what value did you use, and how long until it recurred at 65536?

We also didn't track LSASS handles before the October update, so I have no baseline for what's normal on these servers. Any numbers from your environments would help.

Thanks