0x80029C4A (TYPE_E_CANTLOADLIBRARY)

Question

After installing my application (the installation log looks fine), a particular client (US Military) received the following error when trying to start my application:
System.InvalidCastException: Unable to cast COM object of type 'Microsoft.Office.Interop.Word.ApplicationClass' to interface type 'Microsoft.Office.Interop.Word._Application'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{00020970-0000-0000-C000-000000000046}' failed due to the following error: Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)).
Based on other responses I have read on this error, it looks like the registry may be corrupted by Anti-virus script blocking software or by multiple instances of Office installed.  Indeed the client is running the Symantec software. Are there other causes I should be aware of?
Is there something my code can do to get around this?  I don’t want to have them reinstall Office, as to them it is working fine (i.e. they can start Word and Outlook manually just fine).

Answer 1

Hi Guys!
I've been struggling with a similar problem for about 3 days solid now, and finally after an intense amount of googling and lots of trial and error, I have managed to solve it, I hope the same solution can be applied to your problems.
First off, some basic background info. This problem arose for me after uninstalling Office 2007 and going back to Office 2003 due to the Office 2007 PIA's not being able to communicate correctly and provide backwards compatibility with Office 2003. Upon reinstallation none of my COM calls to any Office COM DLL would work, every call would return the error that is mentioned in the post i.e. CANTLOADLIBRARY, with a long CLSID number e.g. {A5EDEDF4-2BBC-45F3-822B-E60C278A1A79}. I deduced that this must have been due to Office 2007 leaving a bad trail of uninstalled registry key entries...
This CLSID is the key to solving the problem.
First off copy the CLSID from the error window that appears in VB.NET. Access the registry via Start, Run, Cmd, RegEdt32, enter. Once the registry editor loads up, do a search (ctrl F3) on that specific CLSID (I didn't include the braces, but it shouldn't matter). The registry should find a key located under the HKEY_CLASSES_ROOT -> CLSID subkey. Expand this key and you should see 3 nodes: ProxyStubCLSID,ProxyStubCLSID32 and the important one - TypeLib. Essentially what is happening is that when you make the COM call to a specific Office assembly. The assembly opens up the registry and finds this key which gives it the CLSID of the TypeLib it must call in order to initiate a call to the COM.
Under the TypeLib key copy the (Default) Entry (It should be another long CSLID key). Now the easiest way to find this new key entry relating to the CLSID, is to go back up to the root key, HKEY_CLASSES_ROOT and look for the TypeLib subkey. I did this by simply pushing "T" on the keyboard till I got to the all the "T's" on the level below the HKEY root. Once you find this key, highlight the key and do a search (Ctrl F3) from this key for the TypeLib CLSID that you copied earlier. Once you find it, expand it and see if there are multiple versions of the typelib i.e. 8.3, 8.4, 8.5. You want to eliminate the the later versions that are pointing to non-existant TypeLib's. To do this, expand the Version key (ie. 8.3), then expand the "0" key, then the win32 key and check the value of the default entry. This value should be a file path. Mine was pointing to a tlb file in an Office12 directory (Office 2007), that obviously didn't exist since I uninstalled 2007. Simply delete this key, and now when the COM interface attempts to locate the latest TypeLib it will find one that does indeed exist, and will hopefully run error free. Well at least it did for me.
Hope this solves some of your guys problems.
Cheers!