You double-click an embedded Excel sheet inside a FoxPro form and Windows throws OLE_E_NOCACHE (0x80040006) — There is no cache to operate on. Nothing crashed. Nothing warned you. The OLE object just refuses to load, and every forum answer tells you to reinstall Office. Don't do that yet.
This error means the OLE storage cache that's supposed to shadow your embedded object is missing or corrupt. The COM layer asked for a cached rendering of the object and got nothing back. That's it. The fix comes down to where the cache broke, and there are three places it usually does.
Cause 1: Corrupted OLE cache folder (most common)
This is the culprit in roughly 8 out of 10 cases I've handled. Windows keeps a per-user OLE cache under your AppData folder, and it goes stale after a botched Office update, a forced reboot during a save, or a profile migration. FoxPro 9.0 and older Visual Basic 6 apps are especially sensitive because they read that cache directly instead of regenerating it.
Close every Office app, FoxPro, Visual Studio, and anything hosting an embedded object. Then kill the folders below. Windows rebuilds them next time you open an OLE container.
%LOCALAPPDATA%\Microsoft\Windows\INetCache
%LOCALAPPDATA%\Microsoft\Windows\Temporary Internet Files
%APPDATA%\Microsoft\Windows\Recent
%TEMP%
You can also flush it from a command prompt without clicking through Explorer:
rmdir /s /q "%LOCALAPPDATA%\Microsoft\Windows\INetCache"
taskkill /f /im dllhost.exe
The dllhost.exe kill matters. That's the COM Surrogate, and it holds cached OLE handles in memory. If you delete the folders without killing it, the stale handle comes right back and you'll swear the fix didn't work. Reboot after if you want to be certain.
Cause 2: Broken COM/OLE registration
If clearing the cache didn't help, the OLE server itself has lost its registration. This shows up after a bad Office repair, after uninstalling an old Office version alongside a new one, or when a third-party app like CorelDRAW X7 or X8 gets installed side-by-side with a newer build. You'll see the error consistently on the same document, on any user account, on any machine.
Re-register the OLE libraries. Run Command Prompt as Administrator and hit these in order:
regsvr32 /i ole32.dll
regsvr32 /i oleaut32.dll
regsvr32 /i comcat.dll
regsvr32 actxprxy.dll
regsvr32 shdocvw.dll
Now the app-specific part. If you're in FoxPro, you likely need to re-register the VFP OLE server:
regsvr32 /i "C:\Program Files (x86)\Microsoft Visual FoxPro 9\vfp9ole.dll"
CorelDRAW users, register the Corel OLE handler instead:
regsvr32 /i "C:\Program Files\Corel\CorelDRAW Graphics Suite X8\Programs\CorelOLE.dll"
Adjust the path to match your install. If regsvr32 returns 0x80070005 (Access Denied), you're not running as admin. That one trips people up constantly.
Cause 3: Missing or unregistered OLE server application
The document references an OLE server that isn't installed anymore. Someone embedded a Word 2013 equation object, then IT rolled the machine to Office 365 and quietly removed the old COM registration. Or a client sent you an .frx with an embedded snapshot from an app you don't have. When COM can't find the server, it can't build the cache, and you get 0x80040006 instead of a clearer "class not registered" message.
Check what's actually embedded. In FoxPro, open the table, browse the memo field, and look at the OLE class in the properties. In Excel or Word, right-click the broken object and pick Convert to see what type it claims to be. Then confirm the server is registered:
reg query HKCR\CLSID /f "Excel.Sheet" /s
If nothing comes back, the OLE server isn't registered and no amount of cache clearing will help. Reinstall the source application, or convert the embedded object to a static image if you just need it to display. In FoxPro you can do that programmatically:
APPEND GENERAL MyField FROM "logo.bmp" CLASS "Paint.Picture"
For stubborn cases where the same document breaks for every user on the network, the file itself is damaged. Open it on the machine that last successfully edited it, export the embedded objects, and rebuild the container. Copying the broken file around won't fix the cache — it just spreads the problem.
What doesn't work (so skip it)
- Reinstalling Office. Kills an hour of your day and reboots the machine twice. Doesn't touch the OLE cache folder or COM registration state.
- Running sfc /scannow. System file integrity has nothing to do with a per-user OLE cache. I've seen it fix OLE_E_NOCACHE exactly zero times.
- Clearing browser cache. Different cache entirely. The INetCache folder is shared with IE, so people try this. It doesn't help.
- Disabling UAC. Doesn't matter. The error is a COM lookup failure, not a permissions prompt.
Quick reference
| Cause | Symptom | Fix |
|---|---|---|
| Stale OLE cache folder | Error on first open, sometimes intermittent | Delete %LOCALAPPDATA%\Microsoft\Windows\INetCache, kill dllhost.exe, reboot |
| Broken COM registration | Same document fails for every user | regsvr32 /i ole32.dll oleaut32.dll, then re-register the app's OLE DLL |
| Missing OLE server | Error after Office upgrade or app uninstall | Reinstall the source app, or convert embedded object to static |
Start with the cache folder deletion — it's free, it's fast, and it fixes the majority of cases. Only move to registration and server checks if the error survives a reboot. And if you manage machines in bulk, script that folder cleanup to run weekly. It'll save you a ticket queue full of these.