File Explorer became slow after I installed a program

A recently installed application can change how File Explorer behaves.

Desktop applications can add Shell extensions — components that integrate with Explorer to provide functions such as right-click menu commands, icons, previews, drag-and-drop behavior, or property pages. Microsoft documents several kinds of Shell extension handlers and when Explorer calls them. ^[R1]

That makes a recent installation relevant when Explorer suddenly becomes slow.

But timing alone is not enough.

The first question is:

Did the new application add an Explorer extension that is actually involved when the slowdown occurs?

What can an application add to File Explorer?

Microsoft documents Shell extension handlers for actions including:

• shortcut or context menus;
• drag and drop;
• icons;
• icon overlays;
• property sheets;
• thumbnails and other file-type behavior. ^{[R1] [R2]}

A context-menu extension, for example, can be queried whenever Explorer builds the right-click menu for a matching file type. ^[R2]

Microsoft's Sysinternals Autoruns also reports Explorer Shell extensions installed on the system, alongside other automatic integration points. ^[R3]

So an application can affect Explorer even when the application's own window is closed.

Why can a Shell extension make Explorer slow?

Many classic Shell extensions run inside the Explorer process.

Microsoft warns that Shell extension handlers are in-process COM components loaded directly into Explorer or another process hosting the Shell. A crash or hang in an extension can therefore crash or hang Explorer itself. ^[R1]

This is why a third-party Explorer integration is a stronger suspect when the slowdown happens during the exact action that invokes it.

Examples include:

• right-clicking a file becomes slow;
• opening a folder containing a certain file type hangs;
• thumbnails take unusually long to appear;
• Explorer pauses when displaying file properties;
• the problem began immediately after software added Explorer integration.

That is still a hypothesis until it is reproduced.

Correlation after an install is useful, but not proof

Suppose Explorer became slow yesterday and a cloud-storage application was installed the same day.

That is useful timeline evidence.

It does not establish that the application caused the problem.

Explorer can also be affected by storage pressure, network locations, search/indexing, damaged system files, updates, or other software already installed.

Microsoft's general File Explorer troubleshooting guidance includes checking Windows updates, restarting the device, storage/resources, and system-file problems. ^[R4]

The recent application should therefore become a candidate to test, not an automatic uninstall target.

Identify the actual extension

Before changing anything, identify what Explorer integration the application installed.

Microsoft's Autoruns utility includes Explorer Shell extensions in its inventory and can hide signed Microsoft entries to help focus on third-party additions. ^[R3]

Useful evidence includes:

• extension name;
• publisher;
• DLL or package path;
• installation or registration time where available;
• the kind of Explorer action it handles;
• whether that action matches the observed slowdown.

For example:

Explorer pauses for eight seconds only when right-clicking .zip files.
A third-party context-menu handler for .zip was added with yesterday's application install.

That is much stronger evidence than:

Explorer is slow and an app was recently installed.

Should I disable the extension?

If one third-party extension strongly matches the symptom, temporarily disabling that specific integration can be a useful diagnostic test.

Do not disable all Explorer extensions at once.

Microsoft's documentation shows that different handlers provide different functions. Removing or disabling one may remove context-menu commands, overlays, previews, or other application features. ^[R1]

After disabling the suspected integration, reproduce the same Explorer action.

If the slowdown disappears and returns when the extension is restored, the causal evidence becomes much stronger.

Should I uninstall the whole application?

Not necessarily.

If the application provides a setting to disable its Explorer integration, that is usually a smaller change than removing the entire product.

If the integration is essential to the application and repeatedly makes Explorer unstable, updating, repairing, or uninstalling the application may become appropriate.

The key is to avoid treating every program installed near the start of the problem as guilty.

What should I do now?

1. Reproduce the Explorer slowdown and note exactly what action triggers it.
2. Check whether the problem began after a recent application installation or update.
3. Identify any Explorer/Shell extensions installed by that application.
4. Confirm that the extension type matches the slow action — for example, a context-menu handler for a right-click delay.
5. Restart the PC and install pending Windows updates before attributing a persistent Explorer problem to one extension.
6. If one third-party extension is a strong match, disable only that integration where a supported mechanism exists.
7. Repeat the exact same Explorer action and compare the result.
8. Re-enable the extension if the slowdown remains unchanged.
9. If disabling it fixes the problem, check for an application update, repair option, or setting that removes the Explorer integration.
10. Uninstall the whole application only if the integration cannot be corrected and you no longer need the software or the performance problem outweighs its value.

The goal is to establish a chain of evidence:

recent change → specific Explorer extension → matching action → reproducible slowdown → improvement when isolated

rather than assuming that every recent installation is responsible.