explorer.exe registry-Key handle-leak runaway (millions of handles, one CPU core pegged, desktop-icon flicker) on 25H2 Win10-taskbar — reliably triggered by a font-metrics WM_SETTINGCHANGE, stopped by uninstalling EP

[doitamd]

Before reporting your issue

• I have confirmed that this issue does not happen when ExplorerPatcher is not installed
• I do not have "register as shell extension" enabled
• I have tried my best to check existing issues

Repro ExplorerPatcher versions

26100.8457.70.4 (latest). Same behaviour on earlier 26100.8457.70.x this month.
Installed from ep_setup.exe from the GitHub releases page.

Repro Windows Versions

Windows 11 Pro, 25H2, build 26200.9278, x64

Third-party tweak software installed

• Open-Shell 4.4.198 (Classic Explorer toolbar + Classic Start menu)
• ATOK (third-party IME)
• Baidu Netdisk shell extension
• PikPak + WinFsp virtual drive
• Virtual Desktop Streamer (adds an AppInit_DLL, for VR; unrelated)

Display: one 4K 3840x2160 monitor at 150% scaling.

Note: the control test below (EP removed) was run with ALL of the above still installed and unchanged — only ExplorerPatcher was uninstalled.

Describe the bug

With the Windows 10 taskbar enabled (OldTaskbar=2) on 25H2, explorer.exe intermittently enters a loop where it leaks Key-type handles (visible in Process Explorer / handle.exe / (Get-Process explorer).HandleCount).

The leaked handles almost all point at:

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion (OS build lookup)
• HKLM\…\Explorer\CommandStore (context-menu rebuild)

Growth is 100–700 handles/sec and, left alone, climbs into the millions. While it is leaking:

• one CPU core is pegged (~90%) by explorer.exe
• desktop icons flicker continuously (a redraw loop)
• the whole shell (menus, window creation) is sluggish

Restarting explorer.exe clears it instantly and does not re-trigger it by itself.

Triggers

1. Spontaneously, ~3–4 minutes after a clean boot.
2. Reliably by any font-metrics / WindowMetrics WM_SETTINGCHANGE broadcast — e.g. BetterClearTypeTuner → Apply, or changing the UI fonts. rundll32 user32.dll,UpdatePerUserSystemParameters alone only adds ~300 handles; the font-metrics broadcast produces the full runaway.

EP config: OldTaskbar=2, FileExplorerCommandUI=1, UseClassicDriveGrouping=1. DisableImmersiveContextMenu and ClassicThemeMitigations were both 1; setting both to 0 stops the spontaneous post-boot ignition (trigger 1) but not the WM_SETTINGCHANGE trigger (trigger 2).

This looks like the known Windows FileExplorerCommandSource::GetCommand() refcount leak (~140 Key handles per Explorer window open/close on 23H2/24H2, ref https://bugs.fish/) being driven in a loop by EP whenever it rebuilds the context-menu CommandStore / re-detects the OS version on those broadcast events.

Expected outcome

explorer.exe handle count stays stable when a WM_SETTINGCHANGE / font-metrics change is broadcast; no CPU-bound redraw loop; desktop and taskbar icons do not flicker.

Actual outcome

A single BetterClearTypeTuner Apply (GDI contrast change — confirmed to change HKCU\…\Desktop\FontSmoothingGamma, so the broadcast really fires) sends explorer.exe straight into the runaway: measured 12,000 → 13,600 handles in 15 s, one core pegged, desktop icons flickering. If not interrupted the handle count reaches the millions.

Control test — full EP uninstall. Uninstalled EP completely (ep_setup.exe /uninstall, exit 0; C:\Program Files\ExplorerPatcher gone, no EP DLL in explorer.exe, only the inert HKCU\SOFTWARE\ExplorerPatcher config key left). Rebooted. Everything else left in place.

	EP installed (both flags = 0)	EP uninstalled
idle after boot	plateau ~5–6k handles; sporadic multi-thousand bursts	plateau ~3.3k; one one-time bump to ~5.9k around boot+4 min, then flat — capped, cleared by a single explorer restart, no recurrence in 25+ min
BetterClearTypeTuner Apply (GDI contrast 1800), clicked repeatedly for 2.5 min	instant full runaway (above)	nothing — handles flat ~3.3k (actually drifting down), explorer CPU +1.3 s over 137 s (~1 %), no flicker

So the exact operation that reliably triggers the runaway with EP installed is completely inert once EP is removed.

Additional info

• Possibly the same root cause as Taskbar icons are blinking/refreshing in Win10 style mode #4667 (taskbar icons blinking in Win10-taskbar mode, also 25H2 / build 26200; display scaling was raised there as a factor — I run 150 %). My case additionally shows the registry-Key handle leak and the reproducible font-metrics trigger.
• Recovery: taskkill /f /im explorer.exe (or "Restart Explorer") always clears it and does not re-trigger by itself.
• I can reproduce the WM_SETTINGCHANGE trigger on demand and collect the EP console log / an ETW trace / a handle stack (!htrace) if that would help — just say what to capture.

[pyrates999]

what do you mean by this?

Installed from ep_setup.exe (not the Microsoft Store build).

There is no build of EP on the Microsoft Store. The only place you can download ep_setup.exe from is here: https://github.com/valinet/ExplorerPatcher/releases

[doitamd]

@pyrates999 — that line only meant it wasn’t a repackaged/third-party build; install was the normal ep_setup.exe from the GitHub releases page. Edited it to remove the confusion.

Second confirmation, independent boot. After the control test above I reinstalled EP 26100.8457.70.4 (GitHub releases; config auto-restored from the leftover HKCU\SOFTWARE\ExplorerPatcher key) since I rely on the Win10 taskbar. On the next clean boot, with explorer.exe left completely untouched:

• at explorer.exe uptime 1.2 min: ~51 s CPU already consumed, climbing at ~1.4 cores, 2 threads pegged (Running); handle count oscillating ~3,800 (the CPU-spin form this run — no monotonic leak); desktop icons flickering.

So the spontaneous post-boot ignition (trigger 1) fired faster than the “~3–4 min” I originally reported, with DisableImmersiveContextMenu / ClassicThemeMitigations at their restored values.

Uninstalled EP again (ep_setup.exe /uninstall, exit 0). explorer.exe (auto-restarted by the uninstaller) went flat within ~1 min: CPU +0.8 s over 88 s (~1 %), handles drifting down 3,700 → 3,450. The lone ~5.5k-handle / ~1-core bump around explorer-start + 3 min (the “EP uninstalled” column of the table) appeared once and cleared permanently with a single explorer restart.

Offer still stands: EP console log / ETW trace / !htrace on the WM_SETTINGCHANGE trigger — say what would be most useful.

[pyrates999]

Please uninstall the third party software to see if any of it is causing this:

• Open-Shell 4.4.198 (Classic Explorer toolbar + Classic Start menu)
• ATOK (third-party IME)
• Baidu Netdisk shell extension
• PikPak + WinFsp virtual drive
• Virtual Desktop Streamer (adds an AppInit_DLL, for VR; unrelated)

[doitamd]

@pyrates999 — no need for that uninstall sweep, and thanks for the pointer. I found the actual cause, and it was none of the third-party shell software either.

Closing this — ExplorerPatcher was not the root cause. I want to leave an accurate record so nobody else chases EP over this.

Root cause: a corrupted DACL on HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.ts\UserChoice (and the same on .png).

The key had an empty ACL (O:BA D:AI, owner Administrators, zero Allow ACEs), so Explorer running as the normal user could not read it. Explorer treats an unreadable UserChoice as tampering and tries to reset the association — but it cannot delete the key either, so it retries forever:

• FileAssociations\ResetCount and Explorer\GlobalAssocChangedCounter were each written ~70 times per 6 seconds (~13 resets/sec), cumulative ResetCount reached 1,654,955.
• Every reset broadcasts an association-change notification, which re-enumerates every open view plus the desktop, which re-examines the 4,484 .ts files in the folder, which fails again.
• xperf showed ~610,000 registry operations in 6 seconds, 49% of Explorer's CPU in kernel registry code.

That is what produced the "handle growth + one core pinned + desktop icon flicker" I originally reported.

Why I blamed EP. EP amplifies that storm rather than causing it. With EP loaded, each association-change broadcast also re-initialises EP's hooks, which walks HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion and the CommandStore, so the per-reset cost multiplied and the key-handle count exploded. Uninstalling EP made the machine look flat, which is why my A/B test pointed the wrong way — removing the amplifier hid a storm that was still running underneath.

Control test after fixing the DACL. I repaired the ACL on the two UserChoice keys, reinstalled EP 26100.8457.70.4, and did a clean boot with EP and Open-Shell both loaded, Explorer untouched for 20 minutes:

	before (EP, broken DACL)	after (EP, DACL repaired)
Explorer CPU	~1.4 cores pinned at boot+1.2 min	max 2%, avg 0.4%
CPU over the window	51 s in the first 1.2 min	5.9 s in 20 min
Handles	oscillating, previously into the millions	3,014–3,272
Running threads	2 constantly	0
ResetCount	+13/sec	+0

Same EP build, same shell extensions, same machine. The only change is the DACL. EP is staying installed here.

Apologies for the noise, and thanks for looking. If it is useful to anyone: the fastest diagnostic for this class of problem is to watch whether HKCU\Software\Microsoft\Windows\CurrentVersion\FileAssociations\ResetCount climbs while a folder is open. Note that UCPD.sys blocks writes to UserChoice from reg.exe and PowerShell even when elevated, so defaults have to be re-set through the Windows UI afterwards.