What’s DISP_E_BADVARTYPE?
You’re working in an old Access database, a custom VB6 app, or maybe a macro in Excel, and boom — DISP_E_BADVARTYPE (0X80020008) - Bad variable type. The COM subsystem is telling you one thing: something passed a variable type it doesn’t understand. Could be a missing type library, a corrupt DLL, or a registry entry pointing to a version of a file that no longer exists.
I had a client last month — small logistics company — their entire inventory app crashed with this every time they tried to print a label. Turned out an old .ocx file got orphaned after a Windows update. So yeah, this is real.
Step 1: The 30-Second Fix — Repair Your Office or App
Most of the time, this error comes from a corrupted installation of Microsoft Office or whatever software you're running the macro or script in. Office’s own repair tool catches 80% of these.
- Close all Office apps.
- Go to Control Panel > Programs > Programs and Features.
- Find Microsoft Office (or your specific app’s entry — like Visual Studio or a third-party tool).
- Right-click it and select Change > Quick Repair. If that doesn’t work, run Online Repair (takes longer but deeper).
If you’re not using Office — say it’s a custom VB6 app — try reinstalling that app instead. But hold off on the nuclear option until you try step 2.
Step 2: The 5-Minute Fix — Re-Register COM DLLs and OCX Files
If the quick repair didn’t kill the error, the problem is likely a misregistered COM component. The error code 0X80020008 often means a type library (a .tlb, .dll, or .ocx file) has a bad or missing entry in the registry.
Here’s what to do:
- Open an elevated Command Prompt (search CMD, right-click, Run as Administrator).
- Run these commands one at a time, pressing Enter after each:
regsvr32 /u mscomctl.ocx
regsvr32 mscomctl.ocx
If your error is tied to a specific app, check its install folder for .ocx or .dll files. For example, I once fixed a QuickBooks error by re-registering qbocx.ocx in its own folder:
cd "C:\Program Files (x86)\Intuit\QuickBooks 2020"
regsvr32 qbocx.ocx
But honestly, the most common culprit is mscomctl.ocx (Microsoft Common Controls) — that thing breaks on every Windows update. Re-register it and test.
Step 3: The 15+ Minute Fix — Clean Registry Orphans and Fix Type Library GUIDs
Still stuck? This is where you get your hands dirty. The registry has stale entries pointing to type libraries that got deleted or moved. You need to find and remove them.
First, download Microsoft’s Process Monitor (Procmon) — it’s free and will tell you exactly which registry key is failing. Here’s how:
- Run Procmon as admin.
- Start your app or macro that triggers the error.
- In Procmon, filter for Result is NOT SUCCESS and Path contains .tlb or .dll.
- Look for a registry key like
HKCR\TypeLib\{GUID}that returns NAME NOT FOUND or PATH NOT FOUND.
Once you find the bad GUID, open regedit and navigate to:
HKEY_CLASSES_ROOT\TypeLib\{GUID}\1.0\0\win32
Check if the (Default) value points to a file that still exists. If not, update it to the correct path (like C:\Windows\System32\mscomctl.ocx). If the whole {GUID} key is dead, back it up and delete it.
Another common spot: HKEY_CLASSES_ROOT\Interface — same idea. A stale interface GUID pointing to a missing type library will cause this error.
After cleaning, reboot and test. I’ve seen this fix accounting apps, old CAD software, and even a medical billing system that hadn’t been touched since 2010.
What Not to Waste Time On
- Don’t reinstall Windows. Overkill. This is a COM configuration problem, not a broken OS.
- Don’t run a registry cleaner like CCleaner. Those tools are too blunt — they might remove valid entries. Do it manually.
- Don’t ignore Windows updates. Sometimes an update removes or replaces a DLL. Check your Update history and see if the error started after a specific patch.
Real-World Example
Last week, a client’s Access 2019 database would crash with 0X80020008 when running a VBA form. Quick Repair didn’t help. I checked Procmon and foundHKEY_CLASSES_ROOT\TypeLib\{F5BE8B10-0B17-11D2-B0B9-00C04FC31A34}was pointing to a missingmscomctl.ocxpath. I re-registered the OCX and updated the registry path. Two minutes later, the form loaded fine.
If none of these steps work, the app itself might be so old that its COM components are incompatible with your current Windows version. In that case, consider virtualization (a Windows 7 VM) — but that’s a whole other conversation.