File Explorer takes eight seconds to open a folder: finding the shell extension doing it

A user double-clicks a folder on a mapped drive. The window opens, the file list is blank, the green progress bar crawls across the address bar, and eight seconds later the files appear. Local folders are instant. The network is fine. Nothing is in any log. The help desk closes the ticket as "network latency" and it comes back next week.

This post is about the real cause, which is almost never the network. File Explorer loads third-party code into its own process and calls that code once per file in the folder you just opened. One badly-behaved piece of that code makes every folder open slow, and Explorer never tells you which one it was.

The problem: eight seconds to open a folder, and no log line to show it

Start with what a shell extension actually is, because the term gets used loosely.

File Explorer is explorer.exe. It does not know how to draw an icon for a CAD file, read the author out of a Word document, or show a green tick on a synced folder. Windows lets software vendors supply that knowledge as a shell extension handler: a Component Object Model (COM) object, packaged as a DLL, registered in the registry against a file type or against the whole shell.

COM is just Windows' way of letting one program call code inside another program's DLL through an agreed set of functions, called an interface. The important word here is in-process. Most shell extension handlers are loaded into the Explorer process itself, not into a separate sandbox. Microsoft's own registration guidance states it plainly: "Because Shell extension handlers are in-process servers, you also must create an InprocServer32 subkey under that GUID subkey".

So when a folder opens, Explorer is executing code written by OneDrive, by your PDF reader, by your archive tool, by your privilege-management agent, and by whatever the finance team installed in 2019. It executes that code on the thread that is drawing the window.

Three things make this a performance problem rather than a design curiosity.

1. The calls are per item. Open a folder with 400 files and Explorer may ask every registered overlay handler about every one of those 400 files.
2. The calls are serialised. Explorer's folder views run on a single-threaded apartment (STA), so a handler that blocks for 20 milliseconds on a network round trip blocks everything behind it.
3. There is no per-handler telemetry. Windows does not write "handler X took 4.2 seconds" anywhere. That absence is the whole reason this class of ticket goes unsolved.

The symptom set is consistent enough to recognise. Folders on a mapped drive or a Distributed File System (DFS) path are slow while local folders are fine. The first open of a folder is slow and the second is quick, because a cache got warm. Explorer occasionally goes fully white for a few seconds. Right-clicking is slow too - though that specific path is a separate topic, covered in the companion post on Windows 11 context menu handlers, and deliberately out of scope here.

Why it happens: Explorer runs other people's code in its own process

Here is the chain, in order, from the moment a user double-clicks a folder to the moment the list is painted. Each numbered step can call third-party code.

1. explorer.exe asks the shell for a folder object. The implementation lives in shell32.dll and windows.storage.dll.
2. The folder object enumerates items. For a file system folder that is a directory enumeration. For a mapped drive it is Server Message Block (SMB) traffic. For a sync client's folder it may be a namespace extension, which is third-party code doing the enumeration itself.
3. For each item Explorer needs an icon. It checks for an icon handler registered against that file type, which can return a per-file icon instead of the generic one.
4. For each item Explorer asks every registered icon overlay handler whether it wants to badge that item. It does that by calling IShellIconOverlayIdentifier::IsMemberOf and passing the item's path.
5. In a view that shows thumbnails, Explorer calls the thumbnail provider for the file type, which usually has to open and read the file.
6. For any column beyond name, size and date, Explorer calls the property handler for that extension to read metadata out of the file.
7. Hovering an item calls the infotip handler. Opening Properties calls every property sheet handler registered for that type, for all files, and for folders and drives.
8. Selecting a file with the preview pane open activates the preview handler. Unlike the others, that one is hosted out-of-process in prevhost.exe.

Steps 3 to 7 all execute inside explorer.exe. Step 8 does not, which is exactly why preview handlers are rarely the cause of a slow folder open and are frequently blamed anyway.

Where each handler type is registered

Every handler family has its own registration location. You cannot inventory shell extensions from one key, and that is the single biggest reason people miss the culprit. The per-file-type handlers live under a shared parent:

The predefined objects are the ones that hurt, because they apply to everything: * (all files), AllFileSystemObjects, Folder, Directory, Drive, Network, NetShare and NetServer. A property sheet handler registered under * runs for every file in the system.

Those last three are GUID-named subkeys rather than friendly names, which is why a registry search for the word "thumbnail" finds nothing. Note also that a modern registration puts the CLSID in the subkey name, while the older documented form puts a friendly name in the subkey and the CLSID in its default value. Any inventory has to handle both.

The shell-wide handler families sit somewhere else entirely, under this parent:

Namespace extensions deserve a paragraph of their own, because sync clients use them heavily. A namespace extension is code that pretends to be a folder. Microsoft's documentation calls the registration a junction point: create a subkey named for your CLSID under the virtual folder's NameSpace key and Explorer shows your folder there. The same document describes two file-system variants. One is a real folder named MyFolder.{Extension CLSID}. The other is a read-only system folder whose hidden Desktop.ini carries a CLSID= line in its [.ShellClassInfo] section. If enumeration of such a folder is slow, it is slow because the vendor's code is slow. There is no file system underneath to blame.

The icon overlay limit, and what happens past it

This is the one hard number in the whole feature area, so it is worth getting exactly right. Microsoft's support article on the subject states that there "are currently 15 slots allotted for icon overlays, 4 of which are reserved by the system", that past 11 registered handlers "only the first 11 icon overlays that are provided by icon overlay handlers are added to the system image list", and that "The remaining icon overlay handlers aren't used."

The Windows SDK reference for SHLoadNonloadedIconOverlayIdentifiers confirms the ceiling from the API side. A newly registered overlay loads only if "the system has not already reached its upper limit of fifteen icon overlays".

So: 15 total, 4 system, 11 available to everyone else, and handler number 12 onwards is dead weight. It is registered, its DLL may still get loaded, and its badge will never appear.

Two more documented facts about overlays matter for performance work. First, Microsoft's own guidance is that "Software developers shouldn't rely solely on icon overlay handlers", which tells you how much the platform cares about them. Second, and much more useful in the field: "icon overlay handlers aren't used under folders that are synchronized with cloud file system, such as OneDrive and OneDrive for Business. The handlers aren't even executed under such folders." A missing badge inside a OneDrive folder is therefore expected behaviour, not a fault.

Mapped drives, offline files and the handler that phones home

Now the interaction that produces the eight-second folder. A handler that reads the local disk costs microseconds. The same handler pointed at a Universal Naming Convention (UNC) path costs a network round trip, and it pays that cost once per file.

Microsoft documented this exact failure mode in KB 829700, which is still published. The stated cause is that "Windows Explorer tries to obtain detailed information about the remote share and about the file that you are opening. This operation may take a long time over a slow connection." The resolution suppresses three specific property sheet handlers registered under the all-files key, named CryptoSignMenu, {3EA48300-8CF6-101B-84FB-666CCB9BCD32} (OLE DocFile Property Page) and {883373C3-BF89-11D1-BE35-080036B11A03} (Summary Properties Page). It does that by adding a SuppressionPolicy DWORD of 0x100000 to each, plus a Flags DWORD of 0x00100c02 under the Explorer\SCAPI key.

That article is written against Windows 7 Service Pack 1. All three of those handler subkeys still exist on the Windows 11 device used for this post, verified by reading the keys directly. The mechanism has not gone away.

Offline Files, also called client-side caching, adds its own layer. It ships both an icon overlay handler and a property sheet handler on Directory, both implemented in cscui.dll, plus the CscService service behind them. When a share drops into offline mode, code that used to answer instantly starts answering from the cache, or waiting on it. Thumbnails on network folders have their own documented switch, and it defaults in the safe direction: Microsoft's policy text says File Explorer "displays only icons and never displays thumbnail images on network folders by default".

Approved, Blocked, and who wins between HKCU and HKLM

There is a documented allow-list mechanism and it is off unless you turn it on. The Group Policy setting "Allow only per user or approved shell extensions" writes a value named EnforceShellExtensionSecurity. Its documented description is unambiguous about the two locations it then honours: an entry under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved for handlers approved machine-wide, or one under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved for per-user ones.

With the policy off, the Approved list is decoration. On the test device 34 CLSIDs sit in the machine Approved list, every one of the nine registered overlay handlers is absent from it, and all nine load anyway.

Precedence between hives is documented behaviour of HKEY_CLASSES_ROOT itself rather than of the shell. HKCR is a merged view of HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes, and "The user-specific settings have priority over the default settings." A per-user handler registration therefore beats the machine one for the same CLSID. That is how one user ends up slow while the rest of the fleet is fine, and it is why any inventory has to read both hives.

There is also a Shell Extensions\Blocked key beside Approved. On the test device it holds exactly one value, whose data reads like "<third-party photo utility>: Blocked by {6AF39996-9C88-459B-9282-DA18B14E4402}", which is an application-compatibility shim blocking a known-bad extension. The key is worth reading during triage, but be honest about its status. It is observed on live devices and it is not documented by Microsoft as a supported administrative control. Do not build policy on it.

Defender's part in this, which is smaller than the folklore

Antivirus gets blamed for slow Explorer reflexively. The documented mechanism is narrower than the folklore. Microsoft Defender Antivirus documentation states that "If real-time protection is turned on, files are scanned before they're accessed and executed", and that "If the device performing the scan has real-time protection or on-access protection turned on, the scan also includes network shares."

Defender does not scan a folder listing. It scans files when something opens them. That matters here because a thumbnail provider or a property handler opens the file to do its job. Two hundred files with a thumbnail provider that reads each one is two hundred file opens that real-time protection will inspect, over SMB if the folder is remote.

The scheduled-scan settings are separate and both default to disabled. "Scan files on the network" maps to the -DisableScanningNetworkFiles parameter of Set-MpPreference, and "Run full scan on mapped network drives" maps to -DisableScanningMappedNetworkDrivesForFullScan. Neither of those governs on-access scanning, so neither is the lever for this problem.

How to verify: inventory the handlers, then narrow to one

The order matters. Inventory first, so you know what exists. Narrow second, so you know which one is slow. Skipping straight to "disable things until it feels better" is how fleets end up with sync clients half-uninstalled.

Step 1: count the icon overlay handlers

This is the cheapest check and it has a documented pass mark. The command below reads the shell-wide overlay key and prints each subkey name with the CLSID stored in its default value. It writes nothing.

Read the output as a budget, not a list. Nine rows means two slots of headroom. Fourteen rows means three handlers on the device are doing nothing but consuming a DLL load.

Step 2: run the companion inventory script

Counting overlays is one family out of seven. The companion script walks all of them, resolves every CLSID to its backing DLL, tests whether that DLL still exists, checks the Approved and Blocked lists, and reports the Authenticode signature. It is read-only and it fails loudly rather than printing a clean result after a failed read.

Three findings in that output are worth acting on immediately. A handler whose DLL path no longer exists means Explorer attempts a COM activation that must fail before it can move on. A non-Microsoft handler registered under * or AllFileSystemObjects means it runs for every file. A handler whose ThreadingModel is not Apartment is contradicting Microsoft's stated requirement for shell extension handlers, which the documentation warns "can cause intermittent failures, deadlocks, or crashes that are difficult to diagnose".

Step 3: look at what is actually registered, in Registry Editor

Sometimes you want to see it with your own eyes, particularly to confirm which hive a handler came from. Open regedit.exe and navigate to the overlay key.

To follow a CLSID to its DLL, search for that GUID under HKEY_CLASSES_ROOT\CLSID and read the InprocServer32 default value. Check HKEY_CURRENT_USER\Software\Classes\CLSID first if the problem affects one user, because that hive wins.

Step 4: the system files involved, so you know what you are looking at

When you take a trace or read a stack, these are the binaries you will see. Everything below was verified present on a Windows 11 Enterprise device reporting build 26200, with shell binaries from the 26100 servicing branch.

Step 5: Event Viewer - be honest about what is and is not there

There is no event log entry that says a shell extension was slow. Microsoft publishes no per-handler performance event ID for File Explorer, and pretending otherwise sends people hunting for a log line that does not exist. What does exist is a set of channels that give you context, plus one generic event that fires when a handler takes Explorer down with it.

The channels below all exist on a stock Windows 11 device. Note carefully which of them Microsoft documents event IDs for, because most of the useful ones it does not.

Step 6: log files - there are none, so trace instead

File Explorer writes no text log. There is no explorer.log, no CBS-style file to grep, and no diagnostic switch that produces one. That is a genuine N/A, and the documented substitute is Event Tracing for Windows (ETW).

Windows Performance Recorder is the supported way to capture it. The general profile is documented and enough for this job.

Two other Microsoft tools shorten this considerably. Sysinternals Autoruns has an Explorer tab that lists registered shell extensions with publisher and image path, and can hide Microsoft entries so only third-party handlers remain. Sysinternals Process Monitor filtered to explorer.exe shows the file and registry operations a handler performs while the folder opens, including the UNC paths it touches. If a handler is doing SMB round trips per file, Process Monitor shows it in seconds.

Two file-based artefacts are worth knowing even though they are caches rather than logs. The per-user thumbnail cache lives as thumbcache_*.db files under %LocalAppData%\Microsoft\Windows\Explorer, and network folders can also cache into hidden thumbs.db files, which is the thing the documented policy below turns off.

Step 7: services and scheduled tasks in the path

Step 8: split Explorer into separate processes to isolate the blame

Folder Options carries a setting called "Launch folder windows in a separate process". With it on, a folder window that hangs takes its own process down instead of the desktop and taskbar - which makes it far easier to see, in Task Manager, that the hang belongs to a folder window and not to the shell in general.

The fix: shrink what Explorer loads, in the right order

There are four levers, and they are not equal. In order of how much they help and how little they break:

1. Remove or update the offending product. A handler that does network I/O per file is a vendor bug, and vendors do fix them.
2. Stop Explorer asking handlers to do expensive things over the network, using documented thumbnail and shortcut-icon policies.
3. Bring the overlay handler count back inside the documented budget.
4. Turn on the Approved-list policy so only approved or per-user handlers run at all.

Lever 1 and 2: the documented File Explorer policies

Four policies genuinely apply to this problem. All four are ADMX-backed, which matters for how you deploy them.

The first two and the thumbs.db one write into a policy key under the user hive, and the shortcut-icon one writes into a machine policy key. Those parents are:

Group Policy Editor: enable the Approved-list policy

1. Press Windows and R, type gpedit.msc and press Enter. In a domain, do this in the Group Policy Management Console against a test Group Policy Object instead.
2. Expand User Configuration, then Administrative Templates, then Windows Components.
3. Select File Explorer.
4. In the right pane, double-click Allow only per user or approved shell extensions.
5. Select Enabled and click OK.
6. Sign the test user out and back in. The setting is read at shell start, not applied live.
7. Confirm the value landed by reading EnforceShellExtensionSecurity under the user policy key. The companion script prints it in its header.

While you are in the same node, set the two thumbnail policies:

1. Double-click Turn off the display of thumbnails and only display icons on network folders. Leave it Not Configured or set it to Enabled. Setting it to Disabled is what turns network thumbnails on, and that is the setting to hunt for if someone did it years ago.
2. Double-click Turn off the caching of thumbnails in hidden thumbs.db files and select Enabled if your users work on network shares.
3. Under Computer Configuration, the same File Explorer node holds Allow the use of remote paths in file shortcut icons. Confirm it is not Enabled.

Intune: the same settings, and where they actually live

These are ADMX-backed policies exposed through the Policy CSP area ADMX_WindowsExplorer and ADMX_Thumbnails, so the Settings Catalog carries them under the administrative templates tree.

1. Sign in to the Microsoft Intune admin center at intune.microsoft.com.
2. Go to Devices, then Configuration, then Create, then New policy.
3. Platform: Windows 10 and later. Profile type: Settings catalog. Click Create.
4. Name the profile something a future engineer will understand, such as W11-Explorer-ShellExtension-Hardening.
5. On the Configuration settings tab click Add settings.
6. In the settings picker, search for shell extensions. Select the category Administrative Templates > Windows Components > File Explorer (User) and tick Allow Only Per User Or Approved Shell Extensions.
7. Search for thumbnails and tick Turn Off The Caching Of Thumbnails In Hidden Thumbs Db Files from the same File Explorer (User) category.
8. Set each added setting to Enabled, then click Next.
9. Assign to a pilot group. Because the settings are user-scoped, assign to a user group, not a device group.
10. Click Next, then Create, and check the per-setting status on the profile after the next check-in.

If your tenant's settings picker does not surface a given ADMX policy, the custom OMA-URI route works and is documented. Use a Custom profile:

1. Create a Templates profile of type Custom.
2. Add a row with OMA-URI ./User/Vendor/MSFT/Policy/Config/ADMX_WindowsExplorer/EnforceShellExtensionSecurity.
3. Data type String. ADMX-backed policies require the SyncML enable payload, not a bare 1 - the Policy CSP documentation calls this out explicitly and links a worked example.
4. Repeat for ./User/Vendor/MSFT/Policy/Config/ADMX_Thumbnails/DisableThumbsDBOnNetworkFolders if you need it.
5. Assign to the same pilot user group and confirm the result on a device.

Lever 3: get the overlay count back under 11

There is no policy for this, and that is a real gap worth stating plainly. Windows offers no Group Policy setting and no Configuration Service Provider (CSP) to cap, order or disable individual icon overlay handlers. Your options are the product's own configuration - most sync clients have a setting for status icons - or uninstalling what you do not need.

What to do with the inventory:

1. Run the companion script and read the overlay verdict. It prints the registered count against the documented budget and, when you are over, lists which handlers are at risk of never loading.
2. Identify handlers from software nobody uses any more. Those are pure cost.
3. For each remaining vendor, check whether the product has a supported switch for its status badges.
4. Re-run the script after each change. Overlay loading is evaluated at shell start, so sign out and back in between measurements.

Lever 4: what to do about the network path itself

If the inventory is clean and the folder is still slow only over SMB, check the Offline Files layer and the handlers that specifically target network objects. CscService should be Stopped unless you deliberately use Offline Files. Property sheet handlers registered under Network, NetShare and NetServer only ever run against network objects, so a handler there is a strong suspect for a problem that appears only on mapped drives.

And if you land on KB 829700's own remedy, understand what you are agreeing to. It is a registry write to keys owned by Windows, it depends on the Approved-list policy being enabled, and it was published for a much older platform. Test it in a ring, document it, and prefer the vendor fix where one exists.

Proof it worked: a real inventory from a managed Windows 11 device

The output below is a genuine run of the companion script on the Windows 11 Enterprise device used to research this post (reported build 26200), with nothing invented. Identifiers that could name a person or an organisation have been replaced; the CLSIDs, counts and file paths are as printed.

Two things in that output are worth reading twice. First, seven of the nine overlay slots in use belong to one product. Microsoft's own support article says OneDrive "currently registers five icon overlay handlers"; this device has seven, so the real budget is tighter than the documentation's worked example. Second, the leading spaces on those subkey names are visible in the sort order, and they are not a formatting artefact of this post.

The full run widens the picture considerably.

Eight hundred and nine handler registrations, on an ordinary managed laptop, with 172 file extensions carrying a property handler and 121 carrying a thumbnail provider. That is the scale of third-party code Explorer is entitled to call. It is also why "reinstall the sync client" is such a poor first move: the odds that the one handler you guessed is the slow one are not good.

A clean bill of health looks like the run above: zero missing DLLs, zero unsigned non-system handler DLLs, nothing in the Blocked list, and an overlay count inside the documented budget. A device with the problem this post describes typically shows one or more of: an overlay count of 12 or higher, a handler registered under * whose DLL sits in a vendor folder that was uninstalled, or a property sheet handler under Network and NetShare from a product nobody remembers deploying.

The script itself is on GitHub in the Windows 11 scripts repository, under the folder named for this post's slug. It parses cleanly on Windows PowerShell 5.1 and PowerShell 7, contains no non-ASCII characters, performs no write against any device setting, and exits 1 with an explicit warning if any registry read fails - because an inventory that quietly skipped a key it could not read is worse than no inventory at all.

References

• Creating Shell Extension Handlers - the handler catalogue: icon, property sheet, thumbnail, infotip, metadata, copy hook, icon overlay.
• Registering Shell Extension Handlers - handler subkey names, predefined shell objects, and the Apartment threading model requirement.
• How to Register Icon Overlay Handlers - the exact ShellIconOverlayIdentifiers key path.
• Icon overlay handlers aren't displayed - 15 slots, 4 reserved, only the first 11 load, and overlays are not executed under cloud-synced folders.
• SHLoadNonloadedIconOverlayIdentifiers - the documented upper limit of fifteen icon overlays.
• How to Register a Preview Handler - the {8895b1c6-...} subkey, the PreviewHandlers list, and the Prevhost.exe surrogate AppID.
• Registering and Distributing Property Handlers - the PropertySystem\PropertyHandlers key, in-process versus indexer invocation, and the guidance against network lookups.
• Specifying a Namespace Extension's Location - NameSpace junction points, the virtual folder names, and the Desktop.ini variant.
• HKEY_CLASSES_ROOT Key - the merged view and the rule that user-specific settings have priority.
• Policy CSP - ADMX_WindowsExplorer - EnforceShellExtensionSecurity, EnableShellShortcutIconRemotePath and NoCacheThumbNailPictures with their scopes and registry values.
• Policy CSP - ADMX_Thumbnails - DisableThumbnails, DisableThumbnailsOnNetworkFolders and DisableThumbsDBOnNetworkFolders.
• Slow network performance on remote network computer (KB 829700) - Explorer querying the remote share, the SuppressionPolicy values, and the tie to EnforceShellExtensionSecurity.
• Configure scanning options for Microsoft Defender Antivirus - real-time protection scanning files before access, including network shares.
• Introduction to Windows Performance Recorder - capturing the ETW trace that actually names the slow module.
• Autoruns for Windows and Process Monitor - Microsoft tooling for listing shell extensions and watching what they touch.