OLE_E_ENUM_NOMORE (0x80040002) — Fix Missing Data

OLE_E_ENUM_NOMORE (0x80040002) means the enumerator ran out of items — often from a broken or uninstalled COM object, not a crash. Here's how to fix it.

Quick answer: OLE_E_ENUM_NOMORE is a status return, not a crash — the enumerator simply has nothing left to hand you, usually because a COM object it depends on is missing, unregistered, or corrupt. Fix the COM registration and the error goes away.

I know this error is infuriating. You click something in a legacy app, or run a script that enumerates WMI classes, or open an old VB6 tool, and boom — 0x80040002. The message sounds apocalyptic ("cannot enumerate any more because the associated data is missing"), but it usually means something mundane: a DLL that used to be registered on this machine isn't anymore. I've seen it happen after a Windows 10 22H2 in-place upgrade that quietly dropped a vendor's shell extension, and after users manually uninstalled a piece of software that left its COM registration behind. Outlook add-ins and ERP clients that enumerate their plugins are the worst offenders.

What's actually happening

COM (Component Object Model) enumerators are the little loops that say "give me the next item, then the next, then the next." When the source of those items — a registry key, a typelib, a plugin list — is gone or unreadable, the enumerator returns OLE_E_ENUM_NOMORE instead of an item. It's the polite way of saying "I've got nothing." The error is a red flag that the data source vanished mid-flight, not that Windows itself is broken.

Fix it: step by step

Work through these in order. Most people are done by step 3.

Identify the failing app or script. Open Event Viewer (eventvwr.msc) and look under Windows Logs > Application for the timestamp matching your error. The source name tells you which COM server is complaining. Write that name down — it's your target for the rest of this.
Check the COM registration for that component. Open regedit.exe and look for the CLSID the app referenced. In most cases you'll land here:
```
HKEY_CLASSES_ROOT\CLSID\{YOUR-GUID-HERE}\InprocServer32
```
If that key is missing or the (Default) value points at a DLL that no longer exists on disk, you've found your culprit.
Re-register the DLL. Open an elevated Command Prompt and run regsvr32 against the file. For 64-bit DLLs on a 64-bit Windows, use the 64-bit regsvr32 (it's the default). For 32-bit DLLs, use the SysWOW64 copy:
```
regsvr32 "C:\Path\To\Your\Component.dll"

:: For 32-bit DLLs on 64-bit Windows
C:\Windows\SysWOW64\regsvr32.exe "C:\Path\To\Your\Component.dll"
```
You should get a "DllRegisterServer succeeded" popup. If you get an error, the DLL is almost certainly missing or corrupt — reinstall the parent application.
Repair the parent application. If you can't find the DLL, reinstall the software that owns it. For Office add-ins, hit Control Panel > Programs > Microsoft Office > Change > Quick Repair. For ERP clients and other vendor apps, use their own repair option first — don't just reinstall over the top.
Flush the COM cache and restart. Windows caches COM registrations in memory. A reboot clears it. If you're scripting this, restart the machine after the regsvr32 step — it saves you chasing ghost errors for an hour like I did the first time.
Test again. Re-run whatever triggered the error. If it works, you're done. If not, move to the alternatives below.

If that doesn't fix it

Sometimes the DLL is fine but its dependencies aren't. Try these in order.

Run a System File Check and DISM

Corrupt system COM components (especially oleaut32.dll and combase.dll) throw the same error. Run these from an elevated prompt:

sfc /scannow

DISM /Online /Cleanup-Image /RestoreHealth

Reboot after DISM finishes. This has saved me twice on machines that had bad Windows updates.

Rebuild the Windows Search index (if the app enumerates shell items)

Explorer extensions and file-picker dialogs use the Shell enumerator. If the error only happens when browsing files, the index is your problem. Open Control Panel > Indexing Options > Advanced > Rebuild. It takes a while. Go get coffee.

Check whether you're hitting a 32/64-bit mismatch

This trips people up constantly. A 32-bit app cannot see a COM object registered only for 64-bit, and vice versa. If you registered the DLL once, register it the other way too:

C:\Windows\System32\regsvr32.exe "C:\Path\To\Component.dll"
C:\Windows\SysWOW64\regsvr32.exe "C:\Path\To\Component.dll"

Both commands should succeed. If one fails, that tells you which architecture the DLL actually is.

Last resort: uninstall and reinstall cleanly

Uninstall the parent app, delete any leftover folders in Program Files and ProgramData, then reinstall. Back up config first — vendor apps love to nuke your settings.

Prevention: don't let it come back

The single biggest cause I've seen is people manually deleting program folders instead of uninstalling properly. That leaves orphaned CLSID entries in the registry pointing at nothing, and the next time any app touches them, you get 0x80040002. Always use Programs and Features, or the vendor's own uninstaller. Also, before you run Windows Feature Updates on production machines, note which legacy apps install COM components — those are the ones that silently break after an upgrade. A ten-minute inventory before patch Tuesday saves you a four-hour firefight later.

If you're writing code that consumes these enumerators and you keep hitting this, check whether the source returns S_FALSE before you expect more items. OLE_E_ENUM_NOMORE is often a signal that you called Next() on an exhausted enumerator — not a bug in the source at all. Handle it as an end-of-list, not an exception.