File Explorer (and every modern open/save dialog) becomes progressively slower over time

Question

File Explorer (and every modern open/save dialog) becomes progressively slower over time

dagboer 20

Summary

File Explorer, and every "modern" file dialog (Chrome's Save As, Photoshop's Open/Save, native Explorer windows) get progressively slower over days/weeks of use — navigating between folders takes multiple seconds. This has followed me across three different PCs over roughly ten years, always tied to the same workload: downloading 60+ zip files daily, extracting thousands of images, working with them, then deleting them.

Crucially: Notepad's Save As dialog stays instantly fast in the exact same folders, even when set to "All files" (so it's not a file-type filtering difference). Paint's Save As dialog, however, is just as slow as Explorer — so it's not simply "legacy comdlg32 vs. IFileDialog."

I'm not looking for generic tips (cache clearing, SFC/DISM, defrag) — I've been through all of those. I have an ETL trace from WPR and need help reading it, or suggestions for what to look at next.

System

Fresh, high-end PC (a few months old) — same symptom returns despite fast NVMe/CPU

Windows 11, build 26100.8875

Workload: ~60+ zip archives extracted daily (image files), worked on, then deleted

Symptom: slow to open/navigate folders, especially anywhere touching the workflow's folders — but eventually spreads to feeling universal

What I've already ruled out (with testing, not just changing and assuming)

SearchIndexer / Windows Search service: Fully disabled the service, confirmed process no longer runs. No change to symptom. (ProcMon did show SearchIndexer hammering FSCTL_READ_USN_JOURNAL with 2–6 second calls repeatedly over a 10-minute capture — real finding, but disabling Search entirely did not fix the Explorer slowness itself.)

Shell extensions: Went through the full ShellExView list. Disabled all non-Microsoft ones (Adobe CoreSync icon overlays x3 + context menu, Adobe Acrobat BHOs/toolbar, WPS Office preview handlers) and then all OneDrive icon overlay handlers (7 of them) plus Microsoft's own Photo Thumbnail Provider, IPropertyStore Handler for Images, and all Media Foundation property handlers (MF AC3/ADTS/ASF/AVI/MKV/MP3/MPEG/MPEG-4/WAV, 3D Builder thumbnail/preview, WMP Rich Preview Handler). No change.

Icon cache / thumbnail cache: Killed explorer.exe via taskkill /f, deleted iconcache_*.db and thumbcache_*.db from %localappdata%, restarted explorer. No change.

Shellbags: Cleared HKCU\...\Shell\Bags and BagMRU, forced NotSpecified folder type. Helped slightly at first but degraded again.

NTFS-level tweaks: disablelastaccess, disable8dot3, ran defrag /U /V, chkdsk /scan — no meaningful change.

Windows Defender real-time protection: Disabled temporarily, tested — no change.

Network: Disconnected entirely (wifi off), tested — no noticeable change. (Also ruled out a secondary external HDD as a factor — disconnected it, no change.)

USN journal size: Checked with fsutil usn queryjournal C: — standard 32MB, journal wraps frequently given the daily file churn (First/Next USN gap of ~600,000+), but increasing size wasn't pursued since disabling Search entirely already eliminated USN read pressure without fixing the core symptom.

CPU usage during the hang: Watched Resource Monitor / Task Manager during a slow folder open — explorer.exe does NOT spike in CPU. "Analyze Wait Chain" shows nothing.

ProcMon: Captured with filters for Duration > 0.5s and Duration > 0.1s on Explorer.EXE during confirmed slow folder opens — zero results. No file system or registry operation exceeds those thresholds during the hang. (ProcMon did catch SearchIndexer's USN journal reads as noted above, and NotifyChange handles held open by Explorer windows — both expected/normal.)

New local user account (test only, not a real fix): Created a new local account, same machine, same disk — folders were fast, comparable to a fresh install. This tells me it's something in my user profile/registry hive, not the disk, not the OS install itself, not hardware.

Old machine's Guest account: Same result historically — Guest account was always fast even when my main profile had degraded.

Updates that (temporarily) fixed this in the past

On my previous PC, the following Insider Preview builds each coincided with the slowdown disappearing (back to "fresh install" speed) — I never found a common root cause in the changelogs, but listing them in case the pattern means something to someone who knows the File Explorer/shell codebase:

Windows 11 Insider Preview 10.0.26120.2200 (ge_release_upr)

Windows 11 Insider Preview 10.0.26200.5603 (ge_release_upr)

Windows 11 Insider Preview 10.0.26220.5770 (ge_release_upr)

Windows 11 Insider Preview Build 26300.7733 (Dev Channel)

Worth noting: it was NOT every update that helped — most updates (including plenty of others in the same 26xxx range) did nothing for the slowdown. Only these specific ones coincided with a fix, which suggests they contained a genuine shell-related change rather than just the general "fresh restart" effect (a plain restart never fixed it for me).

The interesting new lead

Notepad → Save As: instantly fast, even navigating the exact same "slow" folders, even set to "All Files (.)" so it's not skipping image files.

Paint → Save As: slow, same as Explorer.

Explorer++ (portable alternative file manager): stays fast even as native Explorer degrades — but it doesn't help for saving from a browser, and it's unstable/crashes often, so it's not a real solution.

So it's not simply "old comdlg32 dialog vs. new IFileDialog" (since Paint is old-style too and still slow). Something specific to Notepad's implementation avoids whatever the bottleneck is.

ETL trace

Captured with:

wpr -start GeneralProfile -filemode
[reproduced the slow folder navigation]
wpr -stop C:\trace.etl

I don't have WPA installed (no ADK) and would rather not install a large SDK just to read one file. Ran tracerpt for a text summary — it only gives aggregate event counts, not a per-process/per-thread breakdown, so I couldn't isolate the culprit myself. Happy to share the trace.etl or generate a tracerpt -o trace.xml -of XML dump if someone can point me to what to filter for.

One data point from the summary: 539,049 Thread/CSwitch-type events and 63,636 FileIo events over a 44-second capture — high context-switch volume, but I don't know how to attribute it to a specific process/thread without WPA.

What I'm hoping for

Any idea what could make Notepad's dialog immune to this while everything else (including old-style Paint) is affected

Guidance on what to look for in the ETL trace (which WPA graph, which column) that would show a blocked call not visible to ProcMon/CPU monitoring

Whether this points to something in the user hive (HKCU) specifically, given the fresh-account test

Thanks for reading this far — I know it's long, but I wanted to save people from suggesting the ten things I've already tried.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hello,

Based on everything you’ve tested and the ETL trace details, the key finding is that the slowdown is profile-specific and not tied to hardware, disk, or the OS installation itself. The fact that a new local account restores Explorer responsiveness immediately points to something persisting in your user hive (HKCU) or profile-level shell state. The elevated context-switch volume in your trace without corresponding high CPU usage suggests Explorer is blocking on a thread synchronization or waiting on a property handler rather than performing heavy I/O. That explains why ProcMon doesn’t show long-duration calls - the bottleneck isn’t a file system or registry operation but a thread wait inside the shell’s dialog handling.

The difference between Notepad’s Save As and Paint’s Save As is significant. Notepad uses a minimal IFileDialog implementation without image property handlers or thumbnail generation. Paint and Explorer invoke the full shell namespace stack, which includes property store handlers for images, thumbnails, and metadata. Even though you disabled many handlers, the degradation over time suggests that something in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer (particularly under Shell Folders, TypedPaths, or the Bags/BagMRU keys) is accumulating state that forces Explorer to walk through handlers inefficiently. Clearing ShellBags gave temporary relief, which aligns with this theory.

At this point, the most effective diagnostic step is to analyze the ETL trace with Windows Performance Analyzer (WPA) rather than tracerpt. You’ll want to load the trace, open the “CPU Usage (Precise)” graph, and filter by explorer.exe. Then expand by thread and look at the “Waits” column. If you see long waits on ntdll!NtWaitForSingleObject or kernelbase!WaitForMultipleObjectsEx, cross-reference the stack to see if it involves propsys.dll, shlwapi.dll, or image property handlers. That will confirm whether the slowdown is due to blocked property store calls. If so, the root cause is almost certainly profile corruption in HKCU related to property handlers or accumulated shell state.

Unfortunately, there isn’t a permanent fix documented by Microsoft yet. The Insider builds you listed temporarily resolved the issue because they contained shell-related changes that reset or bypassed the problematic code path. Until Microsoft ships a stable fix, the only reliable workaround is to periodically reset the user profile hive by creating a new account or exporting/importing only essential HKCU keys. If you want to avoid a full profile rebuild, you can try renaming HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer to Explorer.old and letting Windows regenerate it, but be aware this will reset folder views, pinned Quick Access, and other Explorer customizations.

I recommend capturing a WPA trace as described and, if you can isolate the blocked call, submitting it through Feedback Hub with the trace attached. That gives the shell team the exact data they need to reproduce and patch the issue.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

HP.