TYPE_E_TYPEMISMATCH 0x80028CA0 Fix for Windows

You ran a script or app, and instead of doing its job it spat out TYPE_E_TYPEMISMATCH (0x80028CA0). Annoying, but it's one of those errors that has a handful of very specific causes — and once you know them, you'll fix it in five minutes.

The fix

Don't start reinstalling Windows or running sfc /scannow. That won't help here. The error is a COM type mismatch — a program is handing a COM object a value it wasn't expecting. Work through these steps in order.

1. Check the calling code first

If you wrote the script or macro, this is almost always your bug. COM is pedantic about types. Passing a string where a variant of a specific subtype is expected, or passing a null/empty value to a parameter that wants a real object, throws 0x80028CA0 immediately.

Common real-world trigger: an Excel VBA macro that calls CreateObject("Scripting.FileSystemObject") and passes a Range object where a string file path is expected. Or a VBScript that reads a registry value expecting DWORD but gets a REG_SZ.

Add explicit casts. In VBScript use CStr(), CLng(), CInt(). In VBA declare your variables with the right type instead of Variant everywhere:

Dim filePath As String
filePath = CStr(Worksheets("Sheet1").Range("A1").Value)
Set fso = CreateObject("Scripting.FileSystemObject")
Set ts = fso.OpenTextFile(filePath, 1)

That one cast has fixed more 0x80028CA0 tickets than anything else.

2. 32-bit vs 64-bit COM registration

If the script works on a colleague's machine but not yours, check bitness. A 32-bit ActiveX DLL registered on a 64-bit Windows box won't be visible to 64-bit callers, and vice versa. The mismatch surfaces as a type error because COM can't bind the interface properly.

:: For 64-bit DLL
regsvr32 "C:\Path\To\Your.dll"

:: For 32-bit DLL on 64-bit Windows
C:\Windows\SysWOW64\regsvr32.exe "C:\Path\To\Your.dll"

Run the command prompt as Administrator. If you get a different error after registering, you at least know the registration worked and you're chasing a separate problem.

3. Missing or broken dependencies

Some COM components depend on others. If the underlying DLL is missing or was unregistered by an overzealous "PC cleaner" app, you'll get 0x80028CA0 instead of the more obvious "class not registered." Check with Process Monitor from Sysinternals — filter on Result = NAME NOT FOUND and look at what DLL the process was trying to load right before the error.

4. Damaged type library cache

Rare, but it happens after a botched Windows Update. Clear the TypeLib cache and re-register:

regsvr32 /u "C:\Path\To\Your.dll"
regsvr32 "C:\Path\To\Your.dll"

If that doesn't stick, reboot before re-registering. COM caches aggressively and sometimes only a fresh boot clears the stale reference.

Why this actually works

TYPE_E_TYPEMISMATCH is a low-level HRESULT that COM raises when IDispatch::Invoke can't coerce your argument into the type the method signature expects. It's not a "file not found" or "access denied" — it's a contract violation between caller and callee. Fixing the caller's data types, or making sure the caller and the registered COM server are the same bitness, restores that contract. Nothing else does.

That's why random fixes like DISM, sfc, or reinstalling Office don't touch it. They don't change the caller's arguments or the COM registry bitness.

Less common variations

Locale and decimal separator issues. A script running under en-US that passes "1.5" to a COM method expecting a double will succeed. Run the same script under de-DE where the locale expects "1,5", and you can get a type mismatch. Set the culture explicitly in your calling code or use CDbl() with a known culture.
Passing Nothing / null to a required parameter. VBScript's Nothing and VBA's Null are not the same, and neither is a valid object for most COM calls. Guard with If Not obj Is Nothing Then before invoking.
Stale Office PIA (Primary Interop Assembly). If you've upgraded Office but the PIA in the GAC is from the previous version, .NET callers get 0x80028CA0. Uninstall the old PIA and install the matching one.
Antivirus blocking a proxy/stub DLL. Some EDR products block the loading of COM surrogate DLLs. The load silently fails and the type error surfaces. Check your endpoint protection logs around the timestamp of the error.
ODBC driver bitness mismatch. A 64-bit app calling a 32-bit ODBC driver on a 64-bit OS triggers this in some drivers. Install the matching driver architecture.

Prevention

Declare types. Don't rely on Variant auto-coercion in VBScript or VBA — it's the number one source of this error. If you inherit a script that's full of untyped variables, add Option Explicit at the top and fixed declarations as you touch each function. It'll save you hours later.

Standardize on one bitness across your environment. If your COM add-ins are 32-bit, keep them 32-bit. Document which regsvr32 to use for each DLL. Put it in a README next to the installer — future-you will thank present-you.

And keep a copy of Process Monitor installed on your admin workstation. Every time you hit 0x80028CA0 on a machine you don't own, that tool tells you which DLL failed to load in about 30 seconds. Beats guessing.