Fix DISP_E_TYPEMISMATCH 0x80020005 in Windows

Yeah, this error is a pain — especially when it kills a script right before a deadline. But it's fixable, and usually in under five minutes.

The Quick Fix: Re-register the DLL

The culprit here is almost always a COM object that got its registration scrambled — either by a Windows update, a bad install, or a leftover from an uninstall. When the type library can't be read correctly, you get 0x80020005.

Here's what you do:

1. Open Command Prompt as Administrator. Press Win + X and pick "Command Prompt (Admin)" or "Terminal (Admin)".
2. Run these commands one by one:

regsvr32 /u vbscript.dll
regsvr32 /i vbscript.dll
regsvr32 /u jscript.dll
regsvr32 /i jscript.dll

That handles the scripting engines. But if your error is in an Office app — Excel is the biggest offender — you also want to re-register the Microsoft Script Control:

regsvr32 /i msstkprp.dll

Now, test your script again. If that didn't clear it up, reboot and try once more. Sometimes the re-registration doesn't take effect until a restart.

Why This Works

Here's the technical side, short and sweet. DISP_E_TYPEMISMATCH means the COM dispatch engine got a data type it didn't expect. For example, you sent a string when the method wanted an integer, or a null when it wanted a date. But here's the kicker: the error often isn't your code — it's the type library that's missing or corrupt. When the type library is broken, COM can't even figure out what types it's supposed to accept, so it throws a mismatch on anything.

Re-registering the DLL rebuilds the registry entries that point COM to the type library. It's like giving the system a fresh map.

Less Common Variations

Not every case is a DLL issue. Here are a few other spots where I've seen this error show up, and how to handle each.

1. WMI Queries in PowerShell or VBScript

If your script uses GetObject("winmgmts:") or Get-WmiObject, you might see this when the WMI repository is corrupted. The fix is to rebuild it:

winmgmt /salvagerepository
winmgmt /resetrepository

Run those from an admin command prompt. The first tries to salvage what's there, the second wipes it clean and rebuilds from scratch. You'll lose any custom WMI stuff, but that's rare for most people.

2. Excel COM Add-ins

If you're getting this in Excel when calling a custom function, check if you have any COM add-ins enabled. Disable them all via File → Options → Add-ins → COM Add-ins and see if the error goes away. If it does, re-enable them one by one to isolate the bad apple.

3. Automation with XMLHTTP or MSXML

When using MSXML2.XMLHTTP in VBA or JavaScript, this error shows up if you're passing a date object or a locale-specific variable. The fix isn't a re-register — it's to explicitly convert your variables. For example, use CStr() or CDbl() before making the call.

Dim strDate As String
strDate = Format(Date, "yyyy-mm-dd")
http.send strDate

Prevention: Keep It From Coming Back

Here's the thing — this error is a symptom, not a disease. To avoid it in the future:

• Don't install random shell extensions or context menu tweaks. They often mess with COM registrations.
• Use the official installers for Office and scripting tools, not portable versions. Portable apps skip registry setup, which can leave gaps.
• Run a `sfc /scannow` after any major Windows update. It catches corrupted system files that can break type libraries.
• Be explicit with data types in your scripts. Always declare variables with Dim and use CLng, CStr, etc. when mixing types. It's boring but it works.

One more thing — if you're on a 64-bit system and calling a 32-bit COM object, you're in for a mess. The error will keep coming back. You need to compile your script as 32-bit or use a 64-bit compliant object. I've lost hours to that one.

That's it. Try the re-register first, reboot, and if it's still there, check the variations. You'll get it sorted.