Fixing TYPE_E_QUALIFIEDNAMEDISALLOWED (0x80028028) in COM

When This Error Hits

You're automating Excel from VBScript or PowerShell, maybe using CreateObject("Excel.Application"). Everything works on your dev machine, but on a clean Windows Server 2022 or a locked-down corporate desktop, you get 0x80028028. The exact message: "Qualified name disallowed". It usually happens the first time you call a method or property on a COM object — like objExcel.Workbooks.Open or objShell.Run.

Root Cause

The error means COM can't resolve a qualified name (something with a dot) because the type library isn't registered or accessible. Under the hood, COM uses a type library to map dotted names like Workbooks.Open to a dispatch ID. If that type library is missing, corrupted, or has a broken GUID reference, COM throws this error. The culprit here is almost always a missing or mismatched registry entry under HKEY_CLASSES_ROOT\TypeLib. Sometimes it's a 32-bit vs 64-bit mismatch — your script runs in 32-bit mode but the type library is only registered for 64-bit.

The Fix

Step 1: Identify the COM Object

Find the ProgID you're using. For Excel, it's Excel.Application. For Shell, it's Shell.Application. Check the error line in your script — that's your target.

Step 2: Verify Type Library Registration

Open Regedit and go to HKEY_CLASSES_ROOT\TypeLib. Search for the CLSID of your object. For Excel 2016, the GUID is {00020813-0000-0000-C000-000000000046}. If you don't find it under HKEY_CLASSES_ROOT\TypeLib, check HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib. Missing? Reinstall or repair the application. If it's there, note the version number (like 1.9 for Excel 2019).

Step 3: Check the Win32 vs Win64 Key

Inside the type library version key, you'll see win32 and maybe win64 subkeys. Each points to the actual .tlb file. If you're on a 64-bit system running a 32-bit script (common with VBScript on 64-bit Windows), the win32 path must exist and point to a valid file. If it's missing, create it:

1. Right-click the version key (e.g., 1.9) → New → Key
2. Name it win32
3. Set the default value to the full path of the 32-bit type library (e.g., C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE16\MSO.DLL)

Step 4: Switch to Late Binding

If registry edits aren't possible (locked-down environment), rewrite your script to use late binding. Instead of early binding with CreateObject, use GetObject or CreateObject but avoid qualified names. You can't always avoid them — but you can wrap calls in Invoke methods. For VBScript, use objExcel.Application.Workbooks.Open — that's still a qualified name. The real fix is to use a helper function that bypasses type library resolution. Here's a workaround:

Set objExcel = CreateObject("Excel.Application")
Set objWorkbooks = objExcel.Workbooks
objWorkbooks.Open "C:\test.xlsx"

Breaking the dot chain like this often sidesteps the error.

Step 5: Rebuild Permissions

Sometimes the type library is registered but the user account doesn't have read access. Open the .tlb file's security properties (right-click → Properties → Security) and ensure Everyone or Users has Read permission. Also check the registry key permissions under HKEY_CLASSES_ROOT\TypeLib — give Users Read access if missing.

Still Broken?

If the error persists after all that, check for orphaned registry entries. A common scenario: you installed Office 2013, then Office 2019, then uninstalled 2013. The type library GUID for Office 2013 remains in the registry but points to a missing file. Use a tool like Process Monitor to trace the exact registry path COM is trying to access. Filter by Name not found and your script's process name. That'll point you straight to the broken key. Delete it or reinstall the correct Office version.

Also, don't bother with Windows Update or sfc /scannow — they rarely fix this. It's a registry or file path issue, not a system file corruption.