E_NOINTERFACE (0x80004002): Fix No Such Interface Supported

E_NOINTERFACE means a COM object doesn't support the interface you're asking for. Usually a corrupted shell extension or broken registration is the culprit.

You double-click a folder, right-click a file, or try to open Photos, and Explorer just hangs or throws 0x80004002 - E_NOINTERFACE (No such interface supported). No preview pane. No thumbnails. Sometimes the whole desktop flashes and rebuilds itself. The common thread: whatever you were doing needed Windows to hand off to a COM object — a shell extension, a thumbnail handler, a context menu item — and that object answered the door but claimed it doesn't implement the interface Windows asked for.

What's actually happening here

Windows is built on COM. When Explorer wants a thumbnail, it doesn't call a function called MakeThumbnail. It asks the registered thumbnail handler, "Do you support IThumbnailProvider?" via QueryInterface. If the handler says no — or lies and says yes but the vtable is broken — you get E_NOINTERFACE. The object exists (otherwise you'd get REGDB_E_CLASSNOTREG instead), but the specific interface you need isn't there.

That mismatch almost always comes from one of three things:

A third-party shell extension got half-installed, upgrade-broke, or was uninstalled badly, leaving a stale registry entry pointing at a DLL that no longer implements the interface.
A DLL was replaced by a different version (a dropper, a cracked app, a botched update) that registered the same CLSID but dropped interfaces the old version had.
32-bit vs 64-bit confusion — a 32-bit shell extension registered in the 64-bit hive, or vice versa. Explorer loads it, asks for the interface, and gets a failure.

Real trigger: Dropbox, Adobe Acrobat, and older versions of 7-Zip have all shipped shell extensions that break after an in-place upgrade. You install the new version, the old CLSID stays in HKCR\CLSID, and Explorer keeps loading the ghost.

The fix, in order

Identify what's crashing. Open Event Viewer and look at Windows Logs > Application. Filter for source Application Error and look for explorer.exe faults with a module name. That module name is your culprit DLL. Nine times out of ten, it's in C:\Program Files or %LOCALAPPDATA% and has a vendor name.
Kill the suspect shell extension with autoruns. Download Sysinternals Autoruns (use autoruns64.exe on 64-bit Windows). Go to the Explorer tab. Every context menu handler, property sheet, and thumbnail provider lives here. Uncheck anything that matches the module from step 1, or anything from a vendor you recently updated. Reboot. If the error stops, you found it.
Re-register the DLL if it's a Microsoft one. Some E_NOINTERFACE cases come from a built-in handler whose registration was wiped by a cleaner tool or a rogue "optimizer." For the common ones:
```
regsvr32 /s "%SystemRoot%\System32\thumbcache.dll"
regsvr32 /s "%SystemRoot%\System32\shell32.dll"
regsvr32 /s "%SystemRoot%\System32\windows.storage.dll"
```
Run from an elevated command prompt. If any of those return 0x80004005 or 0x8002801c, you've got a bigger problem (usually permissions on the DLL, or a system file that needs sfc /scannow).
Rebuild the thumbnail cache. A corrupted thumbnail database frequently surfaces as E_NOINTERFACE when Explorer asks the cache for an IThumbnailCache interface that isn't there anymore. Close Explorer, then:
```
taskkill /f /im explorer.exe
del /f /q "%LOCALAPPDATA%\Microsoft\Windows\Explorer\thumbcache_*.db"
del /f /q "%LOCALAPPDATA%\Microsoft\Windows\Explorer\iconcache_*.db"
start explorer.exe
```
Don't skip the taskkill. Windows holds those files open and the del will fail silently otherwise.
Run SFC and DISM. If re-registering built-in DLLs fails or the error keeps coming back after a reboot, a system component is genuinely damaged:
```
sfc /scannow
dism /online /cleanup-image /restorehealth
sfc /scannow
```
Yes, run SFC twice — once before DISM to see the damage, once after to repair against the fixed component store. The order matters, and Microsoft's own docs bury that.

If it still fails

Check HKCR\CLSID directly. Search for the CLSID tied to whatever handler you suspect (the module name from Event Viewer usually gets you there via a quick search through HKCR\CLSID\{...}\InprocServer32). If the (Default) value points to a file that doesn't exist, you've found a stale registration — delete the whole CLSID key. Back it up first with reg export; do not skip that step.

Also test with a fresh local user account. Shell extension problems are per-user in some cases — HKCU registrations load alongside HKLM ones, and a broken HKCU entry won't show up in Autoruns' Explorer tab unless you switch to the user profile view. New profile, same crash? It's HKLM or a system file. New profile, no crash? It's something in HKCU\Software\Classes\CLSID, and you can now narrow the search.

If Explorer still throws E_NOINTERFACE with a clean profile, no third-party extensions, and a verified component store, look at your antivirus. Bitdefender and older Kaspersky builds install a shell handler for context-menu scanning that has shipped broken in more than one update cycle. Disable it for a boot and see.