Explorer.exe High Memory Usage? Shell Extensions Are Often the Hidden Cause

Updated February 2026 — Windows 11 24H2

You open Task Manager and notice that explorer.exe is consuming 500 MB, 1 GB, or even more of RAM. Over time, the memory usage keeps climbing, never releasing. Your system becomes sluggish, windows take longer to open, and eventually Explorer may crash or restart entirely.

While there are many possible causes for high explorer.exe memory usage, one of the most common and least understood is memory leaks in third-party Shell Extensions. Every shell extension DLL loaded into Explorer shares the same process memory space, and a single leaking extension can consume gigabytes of RAM over the course of a workday.

This guide explains how to identify, diagnose, and fix shell extension memory leaks using professional-grade tools.

Why Shell Extensions Cause Memory Leaks

Shell extensions are in-process COM servers — DLL files that execute inside explorer.exe. Unlike standalone applications, they do not have their own memory space. When a shell extension allocates memory (for caching thumbnails, building menu structures, reading file metadata, etc.) and fails to release it properly, that memory is attributed to explorer.exe in Task Manager.

Common Leak Patterns

1. Thumbnail Cache Leaks: Extensions that generate file previews (PDF viewers, image processors) often cache thumbnails in memory without implementing proper eviction.

2. Context Menu Handler Leaks: Every time you right-click a file, context menu handlers allocate memory for menu items, icons, and help strings. If they do not clean up after the menu closes, memory accumulates.

3. Icon Overlay Leaks: Overlay handlers (OneDrive, Dropbox, TortoiseSVN) continuously poll file status. If they allocate strings or handles for each poll without releasing them, the leak compounds over thousands of files.

4. Property Sheet Leaks: Extensions that add custom tabs to file properties dialogs may leak GDI handles or COM references.

5. COM Reference Counting Errors: COM objects use AddRef/Release for memory management. A single missed Release call means a COM object stays in memory forever.

Diagnosing the Leak

Step 1: Confirm Explorer.exe Is the Problem

Open Task Manager → Details tab → Sort by Memory (private working set). If explorer.exe shows abnormally high memory (more than 200 MB for normal usage), continue investigation.

Step 2: Use Process Explorer for Deep Analysis

Process Explorer (Sysinternals) provides far more detail than Task Manager:

1. Download Process Explorer from the Microsoft Sysinternals website.
2. Run as Administrator.
3. Find explorer.exe in the process list.
4. Double-click it to open the Properties dialog.
5. Go to the .NET Assemblies tab to check for managed code leaks.
6. Go to the Threads tab — look for threads with high Cycles Delta (these are actively consuming CPU alongside memory).
7. Click View → Lower Pane View → DLLs to see all loaded DLLs.

Step 3: Identify the Leaking DLL

In Process Explorer’s lower pane (showing DLLs loaded by explorer.exe), look for:

• Unusually high “Private Bytes” for a specific DLL
• DLLs from third-party vendors (not Microsoft) with large memory footprints
• DLLs that grow over time — take a snapshot now, wait 30 minutes, and compare

Step 4: Use Performance Monitor for Tracking

Set up a Performance Monitor counter to track explorer.exe memory over time:

1. Open Performance Monitor (perfmon.msc).
2. Click the + button to add a counter.
3. Select Process → Working Set - Private → Instance: explorer.
4. Let it run for 30-60 minutes. A steadily climbing graph confirms a memory leak.

Step 5: Use UMDH (User-Mode Dump Heap) for Precise Leak Detection

For advanced users, UMDH from the Windows Debugging Tools can identify exactly which allocation is leaking:

:: Enable stack traces for explorer.exe
gflags.exe /i explorer.exe +ust

:: Take an initial snapshot
umdh -pn:explorer.exe -f:snapshot1.log

:: Wait 30 minutes, then take another snapshot
umdh -pn:explorer.exe -f:snapshot2.log

:: Compare the snapshots to find growing allocations
umdh snapshot1.log snapshot2.log -f:diff.log

The diff log will show which functions are allocating memory that is never freed, pointing directly to the leaking shell extension.

Fixing Memory Leaks

Fix 1: Disable the Leaking Extension

Once you have identified the problematic DLL, disable it using ShellExView:

1. Open ShellExView as Administrator.
2. Find the extension matching the leaking DLL (search by filename).
3. Press F7 to disable.
4. Restart Explorer: Options → Restart Explorer.
5. Monitor memory usage for 30 minutes to confirm the leak is stopped.

Fix 2: Update the Application

Many memory leaks are fixed in newer versions of the parent application. Contact the vendor or check for updates:

Fix 3: Increase Virtual Memory (Temporary Band-Aid)

If you cannot identify or disable the leaking extension immediately, increasing your page file can prevent crashes:

1. Open System Properties → Advanced → Performance Settings → Advanced → Virtual Memory → Change.
2. Set a custom size: Initial = Physical RAM, Maximum = 2x Physical RAM.

Warning: This does not fix the leak — it only delays the crash. Find and disable the leaking extension as soon as possible.

Fix 4: Scheduled Explorer Restart

As a workaround, you can schedule Explorer to restart periodically to reclaim leaked memory:

# Create a scheduled task that restarts Explorer every 4 hours
$action = New-ScheduledTaskAction -Execute "cmd.exe" -Argument "/c taskkill /f /im explorer.exe & start explorer.exe"
$trigger = New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Hours 4)
Register-ScheduledTask -TaskName "RestartExplorer" -Action $action -Trigger $trigger -Description "Restart Explorer to reclaim leaked memory"

GDI and Handle Leaks

Memory leaks are not the only concern. Shell extensions can also leak GDI handles and USER handles, which have system-wide limits.

What Happens When Handles Run Out

Windows has a default limit of 10,000 GDI handles and 10,000 USER handles per process. When these limits are reached:

• Windows can no longer create fonts, brushes, or pens — UI rendering breaks
• Dialog boxes fail to appear
• Explorer may display a blank desktop
• The system can become effectively unusable

How to Monitor Handle Usage

In Task Manager:

1. Click View → Select Columns.
2. Enable GDI Objects and USER Objects.
3. Watch these values for explorer.exe over time.

Normal values: 200-500 GDI objects, 100-300 USER objects. Suspicious: Over 2,000 of either, especially if climbing.

Identifying the GDI Leaker

Use GDIView (by NirSoft) to see exactly which types of GDI objects are accumulating:

1. Download GDIView.
2. Filter by Process: explorer.exe.
3. Look for rapidly increasing counts in Bitmap, Font, Brush, or Pen categories.

Prevention: Best Practices for Extension Developers

If you are a developer writing shell extensions, follow these guidelines to avoid creating memory leaks:

1. Use Smart Pointers

Replace raw new/delete with std::unique_ptr or Microsoft::WRL::ComPtr:

// BAD - manual reference counting, easy to forget Release()
IShellItem* pItem;
SHCreateItemFromParsingName(path, NULL, IID_PPV_ARGS(&pItem));
// ... if error occurs before Release(), you leak

// GOOD - automatic release via ComPtr
ComPtr<IShellItem> pItem;
SHCreateItemFromParsingName(path, NULL, IID_PPV_ARGS(&pItem));
// Automatically released when ComPtr goes out of scope

2. Implement Proper IContextMenu::QueryContextMenu Cleanup

Always match every allocation in QueryContextMenu with deallocation in InvokeCommand or during handler destruction.

3. Cache Wisely

If caching thumbnails or metadata, implement a Least Recently Used (LRU) eviction policy with a maximum cache size:

class ThumbnailCache {
    std::list<std::pair<std::wstring, HBITMAP>> m_items;
    std::unordered_map<std::wstring, decltype(m_items)::iterator> m_lookup;
    static constexpr size_t MAX_ENTRIES = 100;

    void Evict() {
        if (m_items.size() >= MAX_ENTRIES) {
            auto& oldest = m_items.back();
            DeleteObject(oldest.second);  // Free the GDI bitmap
            m_lookup.erase(oldest.first);
            m_items.pop_back();
        }
    }
};

4. Test with Application Verifier

Enable Application Verifier on explorer.exe during development:

appverif.exe -enable Heaps COM Handles -for explorer.exe

This catches leaks, invalid heap operations, and COM reference counting errors at development time.

When to Suspect a Shell Extension vs. Other Causes

Not all explorer.exe memory usage is caused by shell extensions. Here is how to differentiate:

Summary

High explorer.exe memory usage is often caused by memory leaks in third-party shell extension DLLs. To diagnose and fix:

1. Confirm the issue with Task Manager and Process Explorer
2. Identify the leaking DLL using Process Explorer’s DLL view
3. Track the leak over time with Performance Monitor
4. Disable the offending extension with ShellExView
5. Update the parent application to a patched version
6. Monitor GDI and USER handles to prevent system-wide failures