Fix CO_E_CANTDETERMINECLASS (0x800401F2) – Class not found

You're writing a script in VBScript or PowerShell, or maybe an old COM-based app crashes with 0x800401F2. The exact error text is Class of object cannot be determined. I've seen this most often when trying to instantiate a COM object like WScript.Shell or ADODB.Connection and the CLSID entry under HKCR\CLSID is missing, corrupted, or points to a DLL that doesn't exist anymore.

What's actually happening here

COM works by looking up a human-readable ProgID (like Excel.Application) in the registry. That ProgID contains a CLSID value, which is a GUID. COM then goes to HKCR\CLSID\{that-GUID} to find the path to the DLL or EXE that hosts the object. If that CLSID key is missing, or the InprocServer32 value points to a deleted file, COM throws CO_E_CANTDETERMINECLASS. The system literally can't figure out which class you're trying to create because the registration is broken.

Real-world trigger: You install a new version of Microsoft Office but leave the previous version's COM entries orphaned. Or a registry cleaner removes what it thinks is a dead CLSID. Then any app trying to use Outlook.Application fails with this error.

The fix: Re-register or restore the CLSID

You have two paths. Start with the simple one.

Re-register the DLL or EXE with regsvr32
This is the first thing to try. Open an elevated Command Prompt (right-click Run as administrator) and run:
```
regsvr32 /u path\to\problematic.dll
regsvr32 path\to\problematic.dll
```
Replace path\to\problematic.dll with the actual DLL that hosts the object. For example, for WScript.Shell it's %windir%\system32\wshom.ocx. The /u unregisters, then the second command re-registers. This rebuilds the CLSID entries from the DLL's embedded type library.

Why this works: The DLL contains a DllRegisterServer function that writes the correct CLSID, ProgID, and InprocServer32 keys. If the DLL is intact but the registry got corrupted, this rewrites everything fresh.
Manually check and fix the registry
If regsvr32 succeeds but the error persists, the problem is likely a mismatched GUID. Use regedit to go to:
```
HKEY_CLASSES_ROOT\ProgID\CLSID
```
where ProgID is the human name you're using (e.g., Word.Application). Copy the Default value (a GUID). Then go to:
```
HKEY_CLASSES_ROOT\CLSID\{that-GUID}
```
Check that the key exists and has at least InprocServer32 with a valid path. If the key is missing entirely, that's your culprit.

If you know the correct GUID from a working machine, you can export that key from the working machine and import it. Or you can search the registry for the ProgID and manually create the missing CLSID key structure. I'd only do this if you're comfortable with regedit and have a backup.
Repair or reinstall the application
When the COM object is part of a larger product (Office, Visual Studio, SQL Server Management Studio), a repair install often fixes the COM registration tables. Run the installer setup.exe and choose Repair. This is brute-force but reliable.

What to check if it still fails

Check for 32-bit vs 64-bit mismatch. If your script is 32-bit and the DLL is 64-bit (or vice versa), COM won't find it. Use %windir%\syswow64\regsvr32 for 32-bit DLLs on a 64-bit system.
Check for permission issues. The CLSID registry key might exist but the user account lacks read access. Right-click the CLSID key in regedit, Permissions, and verify that Everyone or the target user has Read.
Check the error log. Use Event Viewer > Windows Logs > Application. Filter by Source 'COM' or 'DCOM'. You'll often see a specific event that names the missing CLSID.
Test with a different ProgID. If you're creating SomeApp.Object, try SomeApp.Application instead. Sometimes the ProgID is wrong but the CLSID is fine.

Bottom line: 0x800401F2 is almost always a registry registration problem. Start with re-registration, move to manual registry inspection, and fall back to a repair install. Don't waste time reinstalling Windows for this.