Retrieving the COM class factory for component with CLSID failed due to the following error: 80040154

Question

0.00/5 (No votes)

See more:

This desktop app is trying to use a Third party TypeLib in vb.net and when trying to instantiate this object:

VB

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:

C#

[
  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

Fingerstyler

Updated 30-Nov-11 14:31pm

Eduard Lu

v2

Add a Solution

Comments

[no name] 30-Nov-11 20:32pm

EDIT: Updated "pre" tag

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

barneyman · Answer 1 · 2011-11-30T12:55:00

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?

Posted 30-Nov-11 12:55pm

barneyman

Comments

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:
HKCR\Interface\
HKLM\SOFTWARE\Classes\Interface\

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 (sysinternals.com) 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. 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 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> [
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 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 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.