IClassFactory failed due to the following error: 800a0153 - com

I'm trying to reference a com component and it is throwing the below error.
Creating an instance of the COM component with CLSID {xxx} from the IClassFactory failed due to the following error: 800a0153.
Specifically the error gets thrown when I try to instantiate an object. I checked that
The project being built for x86 processors which it is
The com object is registered using regsvr32, and is available in the registry.
I can also see the methods in the object browser, so I know .net is finding it.
Any ideas on what I'm missing?

This is an error code that's specific to the component. If you don't have documentation that explains what the code might mean then you'll need support from the vendor.

As noted in my comment to Hans' answer, this error code is FACILITY_CONTROL, which is supposed to relate to OLE/ActiveX controls, and has an error code which lies in the standard range (i.e. for Microsoft use) defined in OleCtl.h, but is not documented in the Win32 header files so is probably internal to a Microsoft product such as Visual Basic.
Can you tell us anything else about the COM component you are trying to use?
If the COM component was written using Visual Basic, I think it's probable that what you are seeing is equivalent to the Runtime Error 339 which users of Visual Basic see if they try to reference an OCX control which has some of its dependencies missing. You might look at the dependencies of the COM server's DLL/EXE using Depends.exe and see whether you have them all present on your machine.

Back when I had to do a lot of COM work, I used COM Explorer quite a bit from these guys:
http://download.cnet.com/COM-Explorer/3000-2206_4-10022464.html?tag=mncol;lst
I had to install it last year to debug a bizarre COM registration issue with Office plugins.
Also, I have no affiliation with these guys whatsoever (and it looks like the company might be toast anyway).

Related

Giving a VB.net DLL reference in web API

I am developing a API. I even have a dll which is written in VB. Can i give a reference of this dll to my web API project? I want to use methods n properties present in this dll. It can save my lot of time.
Finally solved.
So the answer to my own question is, 'YES' we can use reference of a dll which is in VB to a web API project.
I was getting an error while debugging the code was because of a silly mistake. I had to pass an entire connection string whereas i was passing only dbName of the connection string because of which that conversion error.
Thank You.

How can i see If an object is destroyed in a DLL without using Visual Studio

The main software that we built is built using VB6 (old school, I know). We're having some problem for viewing a report using ActiveReports. We did many Debug DLLs and were unable to find why the problem happen. Note that restarting the server solves the issue, which brings us to think that the problem is resource related.
Is there a way I can see how much memory is being used by a DLL? I would like to see if an object in that dll might not be released correctly.
I tried using the performance monitor, but this is not as precise as needed.
Is there anything i could use to monitor a Dll's usage?
We are just doing it the hard way and monitoring a server running multiple instances of the DLL.

VS6 COM App Crashing with Potential Memory Integrity Error

We're porting an old Visual Studio 6 application to Windows 7. The application heavily uses COM and the old RogueWave database interface. We're having a very random sever crash which looks like some sort of memory integrity problem. The crash occurs in the COM application. The application is started using COM, after starting up it tries to connect to the database. One of the following will occur:
1) Sometimes the COM application will have a sever crash
2) Sometimes it will work
3) Sometimes it will not be able to connect to the database and never will even with retries.
4) Sometimes when calling the RogueWave database creation, it does not return.
When starting the COM application several times in a row it will display any number of these symptoms.
At this point I have not been able to identify what is causing the instability.
The application will also crash when started normally, not using COM, but crashes less frequently.
Previously I saw a problem with identical symptoms in another area of this product. I was able to identify that the symptoms were tied to calls into a dll which were returning a CString that was created as a local variable. The dll is built using _AFXDLL preprocessor definition. After removing the calls to this dll this problem no longer occurs. This problem was occurring in many places.
At first I thought that this problem was caused because the dll was not built as an AFX EXTENSION DLL, but after reading through the documentation the _AFXDLL preprocessor definition will also build the dll as an AFX_EXTENSION_DLL. I'm used to using the _AFXEXT preprocessor directive to build AFX_EXTENSION dlls.
The COM application that is now crashing does not use this DLL. There is another DLL used by the COM application that has 1 exported function that returns a CString created as a local variable. This exported function is not called during the database connection.
Anyone have any ideas what would be causing this apparent memory integrity crash in a COM application? Thank you in advance for your help.
This turned out to be caused by a bug in the Oracle 10g express client dll.

VSTO2010: Reference to class 'RibbonBase' is not allowed when its assembly is linked using No-PIA mode

When I try to compile my VSTO Outlook addin, I get this error:
Reference to class 'RibbonBase' is not
allowed when its assembly is linked
using No-PIA mode
Can't seam to find a solution to it online.
Any idea?
Thanks!
Mojo
Certain COM libraries, including this one, do not support No-PIA mode.
Change Embed Interop Type to false in the properties of the reference.
I can't swear that what I'm about to offer would fix the RibbonBase issue, but I received exactly the same error message with respect to a class I was trying to use in Access, and found myself reading this question & answer, so I'd like to offer my solution as I suspect strongly that it might also fix the RibbonBase problem.
The issue is one of referencing a CLASS rather than an Interface. If you search for "is not allowed when its assembly is linked using No-PIA mode" in http://msdn.microsoft.com/en-us/library/h8c469ey.aspx, you can see where I get this from.
It kind-of makes sense - I can see that making the interfaces available gives a better object design (by separating interface from implementation) and would also reduce the meta-data required.
In Access, I was trying to reference ControlClass, and when I switched to using just "Control" (it's interface) then all worked fine for me.
From what I've read, I believe that SLaks solution, while it will undoubtedly work, it will require the Interop assemblies to be instelled on the machine that the solution is deployed on, where as switching to an interface (if possible) then allows you to deploy without the Interop assemblies. For me, that makes my suggestion more attractive, if it could be applied in the case of "RibbonBase".

CLR \ CLI Com Object Out of process Server

How do you register a COM object written in Managed C++ to be SingleUse? Regasm does not appear to have the option. I am guessing it may be a s simple as defining an attribute in AssemblyInfo.cpp but I can't find it.
I have written a VB6 ActiveX EXE and it works as I want it to - that is every request for an Interface creates a new running Server.
Do I have to resort to wrapping my Managed C++ COM in VB6? There has to be an easier way.
It looks like Serviced Components holds the key to my problem.
http://oreilly.com/catalog/comdotnetsvs/chapter/ch10.html
Once I derive from ServicedComponent in the System.EnterpriseServices namespace, do a regsvcs on the dll and then change the pooling in dcomcnfg to be greater than one - it all works. Another issue is to have the Managed C++ component being regsistered compiled with /clr:pure not just /clr. I have yet to complete the project but sample projects I built on the way indicate it should work this way. I think I will wrap my Managed C++ solution in a C# assembly...
Now that i have nearly finished the project one more thing...You need to be on a Server O\S to get the pooling to work.
Thanks for your guidance...
How to use single or multiple instances of an OLE object in MFC by using Visual C++
http://support.microsoft.com/kb/141154
This might give you some clues:
Using Managed Controls as ActiveX Controls http://blogs.msdn.com/andreww/archive/2008/11/24/using-managed-controls-as-activex-controls.aspx