Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: COM VB.NET
This desktop app is trying to use a Third party TypeLib in vb.net and when trying to instantiate this object:
Dim mycalWWList As New CALWorkitemWorkstepList
 
This error is produced:
Retrieving the COM class factory for component with CLSID{{F86DE171-2A5B-11CF-A2A6-08005AC10759}} failed due to the following error: 80040154
 
Oleview of the type library shows this:
[
  uuid(F86DE171-2A5B-11CF-A2A6-08005AC10759)
]
coclass CALWorkitemWorkstepList {
    [default] interface _ICALWorkitemWorkstepList;
};
 

I have read so much on this error and interoperability in general and so far
1.) retried "regtlib.exe"
2.) tried to regsvr32 any other .dll that shows up in procmon.exe but just produced the entry point not found error.
3.) tried tlbimp rather than just adding reference. tlbimp imported all with out error especially noting the coclass above.
4.) target x86.
4.) the legacy COM objects work fine in the vb6 application.
 
I have read all the similar posts here and nothing has help so far.
 
Would anyone have any further suggestions?
Posted 30-Nov-11 9:46am
Edited 30-Nov-11 14:31pm
v2
Comments
Eduard Lu at 30-Nov-11 20:32pm
   
EDIT: Updated "pre" tag

1 solution

Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

0x80040154 is class not registered ...
 
I'd *guess* the proxy is unavailable
 
what have you got in HKLM_CLASSES/CLSID/F86DE171-2A5B-11CF-A2A6-08005AC10759?
  Permalink  
Comments
Fingerstyler at 30-Nov-11 21:06pm
   
That CLSID won't be found in the registry.
barneyman at 30-Nov-11 21:11pm
   
there's your problem :)
 
Is the legacy code running on the same machine? If it is, then the legacy code is calling another clsid, if it's another machine, look at the registry key on THAT machine, and the should help you identify the DLL or EXE you're missing
Fingerstyler at 1-Dec-11 10:55am
   
The legacy code is running on the same machine.
Fingerstyler at 1-Dec-11 11:45am
   
You gave me the idea (ty barneyman) that i would search for the interface name that belongs to that guid in the registry. It was found in 2 places, however the CLSID has 1 digit different on the first part F86DE170. This leads be to believe that the legacy app does not care completely about the guid but maybe likes the "Data" field that contains the interface name????
Found in:
HKCR\Interface\
HKLM\SOFTWARE\Classes\Interface\
 
What to do??
barneyman at 1-Dec-11 18:02pm
   
The UUIDs under the Interface hive are the IIDs of the Interface itself, and under them are the CLSIDs of the proxies for the interface ...
 
It sounds like the legacy app is NOT using the F86DE171... clsid
 
I'd try two things ...
 
1. do a search through the HKCR\CLSID hive for the DLL name that hosts the class, and see what CLSID that turns up
 
2. Run ProcessMonitor (sysinternals.com) on the legacy app, and watch for its registry reads in HKCR/CLSID
Fingerstyler at 2-Dec-11 12:14pm
   
1. i found the CLSID of the dll that i beleive hosts the class, however,
2. when i run the process monitor:
a. VB6 app with cmdBotton that does no more than "Dim mycalWWList As New CALWorkitemWorkstepList" - i was expecting another registry read in HKCR\CLSID but nothing more appears in that path filter of HKCR\CLSID for process montitor.
 
b. VB.net app with cmdBotton that does no more than "Dim mycalWWList As New CALWorkitemWorkstepList" - right away shows registry result NAME NOT FOUND. Then of course the 80040154 error.
barneyman at 2-Dec-11 21:24pm
   
vb might be loading it out of proc - so dllhost.exe will be the calling process
Fingerstyler at 6-Dec-11 11:05am
   
If that is true, is there anymore that i can do?
barneyman at 6-Dec-11 20:57pm
   
the only thing you can do is try to track down what the legacy app is doing with CLSIDs - sorry
Fingerstyler at 9-Dec-11 15:45pm
   
Thanks barneyman, i just don't 100% understand what i'm seeing with dependency walker and the procmon, but what i do notice is that each class in the COM and .net have interface registered and coclass that is not registered. There are several like this where the first uuid of the interface is in the registry, the coclass uuid is not (henceforth no objects of those classes can be created). Is that any help?
 
<pre> [
odl,
uuid(F86DE170-2A5B-11CF-A2A6-08005AC10759),
helpstring("ICALWorkitemWorkstepList Interface"),
dual,
oleautomation
]
interface _ICALWorkitemWorkstepList : IDispatch {
[id(0x80013001), propget]
HRESULT Count([out, retval] long* retval);
[id(0xfffffffc), propget]
HRESULT _NewEnum([out, retval] IUnknown** retval);
[id(0x80013002), propget]
HRESULT Item(
[in] long lOrdinal,
[out, retval] _ICALEnumItem** retval);
};
[
uuid(F86DE171-2A5B-11CF-A2A6-08005AC10759)
]
coclass CALWorkitemWorkstepList {
[default] interface _ICALWorkitemWorkstepList;
};</pre>
Fingerstyler at 27-Dec-11 15:27pm
   
I have meticulously imported all the keys etc throughout the registry that i manually created to look just like a class that works. This was several .reg files. The .net app still produces the same error as in beginning "80040154". This is more puzzling because now at least the CLSID exists, but so do all other keys/data. I was expecting it to work or prodcue a new error. What's next....is there anything next?
Fingerstyler at 6-Jan-12 13:44pm
   
Actually i did get a new error of 80040111 which is not much help. After much digging i found the documention for legacy app. I did the repair for the add/remove/programs for that module of the legacy app hoping it would fix up the registry but no such luck.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



Advertise | Privacy | Mobile
Web01 | 2.8.140827.1 | Last Updated 30 Nov 2011
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100