Status: implemented and run as a read-only audit on the lab ZBook. We did not replace Explorer, disable Search, unload a file filter, stop a service, change a driver, or edit the registry.

A useful idea with a dangerous shortcut

A slow right-click menu feels like an Explorer problem. It may come from Explorer itself, but it can also come from an add-on that Explorer loads when you click. Storage tools, cloud apps, security products, and backup software can all add work.

The tempting fix is to remove every add-on. That would be fast to try and hard to trust. One of those parts may protect files, encrypt data, create backups, or provide a feature the customer needs.

So we changed the order of work. First, list the parts. Next, record the slow action. Then isolate one measured candidate.

What we built

The new PowerShell tool has two jobs.

  1. Audit: record common File Explorer context-menu handlers, loaded file-system minifilters, the configured Windows shell, and available Windows Performance Recorder profiles.
  2. Trace: record one short, automatic ETW trace with a Microsoft WPR profile while the user repeats a slow action.

ETW means Event Tracing for Windows. It is Windows' built-in way to record which processes, drivers, and system events were active during a problem. The trace stops on its own after a set time.

# Read-only inventory
.\experiments\EXP-023\Invoke-LatencySurfaceAudit.ps1

# Preview a 30-second trace without starting it
.\experiments\EXP-023\Invoke-LatencySurfaceAudit.ps1 Trace -WhatIf

# Capture the trace from an administrator PowerShell window
.\experiments\EXP-023\Invoke-LatencySurfaceAudit.ps1 Trace

The script records structured JSON evidence. It also checks file versions and signatures when a classic Explorer handler points to a DLL. Local user paths are shortened in the saved report to avoid exposing the account name.

One claim we corrected

You can replace the Windows shell on some editions, but Microsoft's supported Shell Launcher feature is made for special-purpose devices such as kiosks. Microsoft lists Enterprise, Education, and IoT Enterprise support.

This lab ZBook runs Windows 11 Pro. We are not treating a direct Winlogon\Shell edit as a normal performance tweak. The profiler records the current shell and keeps Explorer in place.

The first audit found a real follow-up candidate

The read-only run recorded 33 common context-menu registrations. Twenty-eight resolved to files with valid signatures. Four built-in pin registrations do not use the same in-process DLL pattern, so this audit does not judge them.

One registration named OptaneContextMenu, with class ID {AD7EBB13-617D-3270-8FA8-46583499C4FB}, points to a file that is no longer present. That makes it a clean candidate for a separate test. It does not prove the missing file slows the menu.

WPR and its general profile were available. The non-administrator minifilter query returned Access Denied. The tool preserved that result instead of reporting that the laptop had zero filters. An administrator audit is still needed for that part.

What we know—and what we do not

Documented facts

  • Explorer can call registered shell extension handlers during shell actions.
  • File-system minifilters can observe, change, or stop file I/O.
  • Microsoft supplies fltmc.exe to list minifilters.
  • WPR includes general, file-I/O, and minifilter recording profiles.

Lab measurements

  • 33 common context-menu registrations were recorded.
  • 28 resolved files had valid signatures.
  • One Optane registration pointed to a missing file.
  • WPR was available; minifilter enumeration remained incomplete.

Hypothesis

A handler or minifilter that appears in a repeated slow-path trace may be a better target than broad Windows “debloat.” The stale Optane registration is the first narrow candidate.

Unresolved questions

  • Does the Optane registration appear in a slow context-menu trace?
  • Which minifilters are loaded when the audit runs as administrator?
  • How much overhead does each WPR profile add?
  • Does one isolated change improve repeated median results?

Safety and compatibility

EXP-023 is observation-only, so it has no apply or rollback action. The bounded WPR session is canceled if capture fails. No persistent configuration is created.

A later change will be a different experiment. It must capture the exact original registration, support a dry run, apply one change, verify the result, survive the expected restart or sign-in cycle, and restore the original state exactly.

A loaded minifilter remains required until its owner, purpose, dependencies, support rules, and trace cost are known. We will not unload antivirus, encryption, backup, recovery, storage, or management filters just because they appear in a list.

What comes next

We will record the same context-menu action several times with a controlled power and thermal state. We also need to measure the recorder's own overhead.

If the stale Optane registration appears in the slow path, the next experiment will capture its exact registry state, disable only that registration, repeat the trace, and roll it back. If it does not appear, we keep it as an interesting stale entry and move to the component that the trace actually shows.

Sources

All sources were retrieved July 28, 2026.

Project links

Back to all development updates