I was using an application and it was working perfect. After some months of not using it, I tried to run it and it doesn't work. It shows a message box saying that it cannot instance a COM object.
Do any know how to track errors in COM objects?
You can use ProcessMonitor and try to find the registry key that may be incorrect.
The other option is to use http://www.moduleanalyzer.com, it intercepts CoCreateInstance showing all created COM objects and the return values.
Run Depends tool on COM object DLL to verify it has all the necessary dlls, re-register the COM dll/exe.
Any HRESULTS from debugging/logs? Any changes in apartment models?
You cannot change the apartment type once you've set one. So if the object cannot use one of the models and you try to CoCreate it, it will fail. That's why you never call CoInit from inside DLL main thread.
Related
I am using pywin32 to register a COM object. The COM object get registered and it is avaialable in the registry editor at Computer\HKEY_CLASSES_ROOT\CLSID{B7B60366-B784-451F-BD6A-E7E733DB4E63}.
The problem is that the path in InProc32 includes only pythoncom37.dll. The only way can make the object work is to rename the inproc folder, so that it searches for LocalServer by default.
I believe several problems in the behavior of this object are connected to it not being ran as inproc, hence I really want to get it to run as inproc.
Any Ideas why this is the case? What can I do to change it?
I've been trying to implement following scenario:
Application [C++] uses CoCreateInstance on registered COM class (CReg/Reg.dll)
CReg class uses CoCreateInstance on regfree/SxS COM class (CFree/Free.dll).
CoCreateInstance returns REGDB_E_CLASSNOTREG.
Problem doesn't seem to be with manifests, because if I try to instantiate CFree directly via application, object is created with no problem.
I have checked and scenario above triggers Activation Context of CReg (I have checked with sxstrace) and even manifest of the CFree is loaded successfully (!) which should effect in correct regfree COM. If I change manifest of the CFree then Activation Contexts fails (which I believe is proof for me that it was correctly triggered and loaded before the change).
Is scenario with using registered COM [CReg] not possible to access CFree object? If it is possible, are there some special work in order to load it properly?
EDIT
With Joe's help, we worked out that the problem is where Free.dll is located.
Main application is (for example) in C:\Proj\App, both Reg.dll and Free.dll are in C:\Proj\Libs. Is there possibility to load regfree Free.dll which is in different location than application? Problem is that I can't place it in application directory or in application child directory (it has to be in external location).
I have tried to use ISOLATION_AWARE_ENABLED preprocessor definition on Reg.dll project, to trigger Activation context from Reg.dll directory. Manifest from Free.dll is loaded properly (sxstrace logs that) but CoCreateInstance call is still returning REGDB_E_CLASSNOTREG. This blog article points that it may be possible with this definition (but is not giving definite answer on this matter).
Anyone can help me solve this problem or at least point to the documentation that may give me an answer, whether it is possible or not, to load regfree dll from an external location?
I have a .NET COM DLL that I want to unregister. I do:
regasm.exe /u ConfigManager.dll
When I look with COM-ole viewer app I still see in type libraries section an entry for ConfigManager( specifies the path to ConfigManager.tlb there). How can I make sure I deregister for good any entries of ConfigManager.dll COM ?
I ask this because I have a nasty error where it seems that ConfigManager clients do not see some types from ConfigManager and want to make sure I deregister and register again ConfigManager
You just need a typelib registration utility. TypeLibs are not specific to .NET so you can find these kinds of ones anywhere.
Here's a simple one:
http://www.vbaccelerator.com/home/vb/utilities/Type_Library_Registration_Utility/VB6_Register_TypeLib_Utility.asp
I prefer to use TlbExp instead of the /tlb option of RegAsm to get a typlelib without automagically registering it. That way I can explicitly register (or unregesiter) the typelib.
i worte a dll of com object
i registered it
where can i find this dll now in my machine
(when we register dll to where the nachine copy the dll)
and more question if i try to use this com object in powerShell everything thong work well
if i try to use it in javaScript i get exception
any idea??? why??
Registering a COM DLL does not copy the DLL. It just adds registry keys which COM uses to locate your DLL. For example, for every class a key "HKEY_CLASSES_ROOT\CLSID{your class ID}" is added. A lot of the time the path to your DLL is stored as the default value in a subkey such as "InprocServer32" (actual name depends on how your class is configured to be activated).
JavaScript cannot access COM objects, or even local files for that matter, because JavaScript is executed inside an isolated environment set up for security reasons.
As Richard Walters stated, registering a COM object does not copy it anywhere. Usually I am lazy and rather than looking up long GUIDs in REGEDIT, I search for the DLL's name using the Find feature.
Since you mentioned PowerShell, can I assume you are trying to use Javascript within the Windows Script Host? If so, knowing what the exception is might help. An example on how to do this though:
var xml = new ActiveXObject("Microsoft.XMLDOM");
xml.load("foo.xml");
Of course replace Microsoft.XMLDOM with information from your COM object.
The equivalent PowerShell would be:
$xml = New-Object -ComObject Microsoft.XMLDOM
$xml.load("foo.xml")
I wrote an application that loops through a set of records and prints two things.
One is a report from SSRS wich works correctly.
The other is a drawing that uses a COM object to print. The COM object randomly fails and causes the program to quit.
Is there a way to stop it from killing the entire program when the COM Object fails? I have tried catch every exception at every level and it still does not work.
Do you have the code of COM object that you are calling. If you have code then check whether there any exit command on failure.
Are you using the COM object from multiple threads? You should only access the COM object from a single thread with a message pump. In my experience this can cause weird instability which cannot be trapped via a try-catch.
It sounds like the issue maybe with the com object itself and not your code. If this is the case then if the com object does not throw an error then you will not be able to catch one.
Kind Regards
Tony Smith-Brewster