Click here to Skip to main content
12,953,263 members (83,537 online)
Rate this:
Please Sign up or sign in to vote.
See more:
This desktop app is trying to use a Third party TypeLib in 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:
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
Updated 30-Nov-11 14:31pm
Eduard Lu 30-Nov-11 20:32pm
EDIT: Updated "pre" tag

1 solution

Rate this: bad
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?
Fingerstyler 30-Nov-11 21:06pm
That CLSID won't be found in the registry.
barneyman 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 1-Dec-11 10:55am
The legacy code is running on the same machine.
Fingerstyler 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:

What to do??
barneyman 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 ( on the legacy app, and watch for its registry reads in HKCR/CLSID
Fingerstyler 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. 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 2-Dec-11 21:24pm
vb might be loading it out of proc - so dllhost.exe will be the calling process
Fingerstyler 6-Dec-11 11:05am
If that is true, is there anymore that i can do?
barneyman 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 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> [
helpstring("ICALWorkitemWorkstepList Interface"),
interface _ICALWorkitemWorkstepList : IDispatch {
[id(0x80013001), propget]
HRESULT Count([out, retval] long* retval);
[id(0xfffffffc), propget]
HRESULT _NewEnum([out, retval] IUnknown** retval);
[id(0x80013002), propget]
[in] long lOrdinal,
[out, retval] _ICALEnumItem** retval);
coclass CALWorkitemWorkstepList {
[default] interface _ICALWorkitemWorkstepList;
Fingerstyler 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 there anything next?
Fingerstyler 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)

    Print Answers RSS
Top Experts
Last 24hrsThis month
OriginalGriff 6,429
CHill60 3,490
Maciej Los 3,103
Jochen Arndt 1,975
ppolymorphe 1,920

Advertise | Privacy | Mobile
Web02 | 2.8.170525.1 | Last Updated 30 Nov 2011
Copyright © CodeProject, 1999-2017
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