COM and .NET errors after Office architecture migration
Symptoms
After you migrate Microsoft Office architecture from 32-bit to 64-bit, you experience errors if a COM application or a .NET Framework client is used. These possible errors include, but are not limited to, the following:
TYPE_E_CANTLOADLIBRARY
TYPE_E_LIBNOTREGISTERED
TYPE_E_ELEMENTNOTFOUND
The errors usually occur if the COM application or .NET client is running as a 32-bit process.
Example
These errors might occur when the following code is run in 86-bit PowerShell:
$xl = New-Object -ComObject Excel.Application
$xl.Visible = $True
Cause
The errors are caused by orphaned registry subkeys that are created by the migration.
Resolution
To fix this problem, use either of the following methods.
Method 1: Delete orphaned subkeys automatically
To detect and remove the orphaned subkeys, run this script from the following GitHub location:
Method 2: Delete orphaned subkeys manually
If the PowerShell script from Step 1 doesn't delete the orphaned subkeys, you can also check for orphaned entries manually. The affected device might have orphaned subkeys that resemble the following example:
HKEY_CLASSES_ROOT\WOW6432Node\TypeLib\GUID\1.9\0\Win32
Note: In this example, GUID is a string that is specific to the subkey.
The subkey will have a value that points to a missing Office executable in the Program Files (x86) file path. For example:
C:\Program Files (x86)\Microsoft Office\Root\Office16\EXCEL.EXE
There should also be an adjacent subkey that points to the correct 64-bit Program Files location.