ActiveX component can't create object - dll

I have just installed a third party app on my Windows Server 2008 server
and I get the
ActiveX Component can't create object
message when I try to access using a CreateObject in VBScript.
It is definitely installed and exists under "Programs and Features". Does anyone have a list of things that I can check to figure out what is going on?
I have now tried to register the DLL using regsvr32.exe /i bob.dll as suggested but I get this error:
The Module "Bob.dll" was loaded but the entry-point DllRegisterServer was
not found.
Make sure that "Bob.dll" is valid DLL or OCX file and then try again.
I should note that this is a 32-bit application on a 64-bit machine at
this point. It also works fine on my machine which is Windows XP 32-bit.

It turns out to get this application working under VBScript, I had to do two things.
Run RegAsm.exe to register the DLLs.
Run the C:\Windows\SysWOW64\cscript.exe to run my VBScript.
If these don't work, check out the other answer here about enabling 32-bit applications in IIS.

It's also worth checking that you've got "Enable 32-bit Applications" set to True in the advanced settings of the DefaultAppPool within IIS.

The app is trying to create a COM Object and even if that COM DLL exists, it may depend on another DLL which isn't installed. You can use DependencyWalker to find out if this is the case.

Check your browser settings.
For me, using IE, the fix was to go into Tools/Internet Options, Security tab, for the relevant zone, "custom level" and check the ActiveX settings. Setting "Initialize and script ActiveX controls not marked as safe for scripting" to "Enable" fixed this problem for me.

Also when you register the component make sure you use the 32-bit version of regsvr32.exe.
If you simply run regsvr32.exe in a elevated prompt, it will default take the standard 64-bit version (which oddly enough is located in C:\Windows\System32)
The version I believe you need is located in C:\Windows\SysWow64\regsvr32.exe

It really looks as though the object you are referencing is not registered on the system. I know you said it's installed, but that doesn't necessarily mean it's registered. To confirm this, search for the progID that you used in your registry.
Example for this code:
set objFSO = CreateObject("Scripting.FileSystemObject")
I would search for Scripting.FileSystemObject in the registry. Then I would look at registry key above the found value, for InProcServer32 value. This will give you the path to the ActiveX file that it was registered from (for Scripting.FileSystemObject the file is "c:\windows\system32\scrrun.dll").
If you can't find your progID in the registry, then it's not registered on your system which is your problem. If it's not registered you need to find out what file registers it, which is usually an .ocx or a .dll in the same folder path of your third party app, and then register these file(s). Here is the command to register a file:
regsvr32 /i "c:\windows\system32\scrrun.dll"
Even if you find the progID value in the registry and it references a file that is present on your system, you may still want to try re-registering the file. I have found that sometimes the registration got broken somehow somewhere and it was easier to re-register the files then it was to fix the issue.

If its a 32 bit COM/Active X, use version 32 bit of cscript.exe/wscript.exe located in C:\Windows\SysWOW64\

I know this is an old thread, but has anyone checked if their Antivirus is blocking Win32API and Scripting on their systems? I have CylanceProtect installed on my office system and i found the same issues occurring as listed by others. This can be confirmed if you check the Windows Logs in Event Viewer.

I also meet the same error in vbscript.
Set objFSO = CreateObject("Scripting.FileSystemObject")
Solution:
Open command line, run :
regsvr32 /i "c:\windows\system32\scrrun.dll"
and it works

I've had the same issue in a VB6 program I'm writing, where a Form uses a ScriptControl object to run VBScripts selected by the User.
It worked fine until the other day, when it suddenly started displaying 'Runtime error 429' when the VBScript attempted to create a Scripting.FileSystemObject.
After going mad for an entire day, trying all the solutions proposed here, I began suspecting the problem was in my application.
Fortunately, I had a backup version of that form: I compared their codes, and discovered that inadvertently I had set UseSafeSubset property of my ScriptControl object to True.
It was the only difference in the form, and after restoring the backup copy it worked like a charm.
Hope this can be useful to someone. Up with VB6! :-)
Max - Italy

I had the same issue with Excel, I was trying to use a 32 COM DLL with an Excel 64 bits version and I got this error. I rebuild the COM dll to a 64 bits version and the error disappears. So be sure that your COM dll has the same architecture (x86 vs x64) than your application.

I had this problem too. I was trying to run an old 32-bit dll in a 64 bit system. I got it working by copying the .dll to the C:\Windows\SysWoW64\ directory and running this:
%systemroot%\SysWoW64\regsvr32 "C:\Windows\SysWoW64\thenameofyourdll.dll"
And also enabling IIS to run 32 bit apps

Related

.net objects for 32 or 64 bit Excel?

I have a VB.net project that builds and registers a COM library that I can open and use in Excel on my development machine. That machine happens to have 32-bit Excel. On my other machine Excel installed in 64-bit and will not open the library, 429.
Other threads have suggested that the code itself is likely fine, as long as I compile under "Any".
Is that correct? Is code compiled for "any" generally able to run on 32 and 64-bit?
The same threads suggest that the only real problem is the tlb/registration, and point to articles that suggest manually calling regasm to avoid this.
Is this correct?
If so, am I supposed to have two tlb files? Or two COM libs? Or just one?
Ok, it's working. I still don't understand why this solution works, but here it is:
compile the DLL using the "Any CPU" setting
turn OFF COM registration, it doesn't hurt but it will just confuse things later
add two lines to your VS project's post-build:
"%Windir%\Microsoft.NET\Framework\v4.0.30319\regasm" "$(TargetPath)" /tlb:DCFPropery32.tlb
"%Windir%\Microsoft.NET\Framework64\v4.0.30319\regasm" "$(TargetPath)" /tlb:DCFPropery64.tlb
copy the DLL and TLB's to the target machine
determine the bit-ed-ness of the target machine's office:
http://www.howtogeek.com/howto/24259/
run the correct version (32 or 64) of regasm on that machine with the following switch:
FOR 32-BIT OFFICE
c:\windows\microsoft.net\frameworks[version number]\regasm [path to dll] /codebase
FOR 64-BIT OFFICE
c:\windows\microsoft.net\frameworks64[version number]\regasm [path to dll] /codebase
open Excel on the target platform and navigate to the VBA editor's References dialog. Browse… to the location of the files, and select the correct bit-edness version of the TLB for your platform.
And hopefully that works for all of you too!
This solution is far from ideal. For one, Microsoft keeps moving the location of regasm, so there's no simple way to script this. For another, I have no idea idea why I need to call /codebase, but it appears to have something to do with the naming of the files. Finally, this means that all such work will require at least a little manual work on each and every machine you want to run it on, or you'll need to go through the trouble of making an installer!

Class not registered Error

Running an application from Visual Studio 2012 on 64-bit computers, displays the following error message:
Retrieving the COM class factory for component with CLSID {F2D4F4E5-EEA1-46FF-A83B-A270C92DAE4B} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
I am using Inventor packandgo dll library in visualstudio.
Anyone know what is the error?
My problem and the solution
I have a 32 bit third party dll which I have installed in 2008 R2 machine which is 64 bit.
I have a wcf service created in .net 4.5 framework which calls the 32 bit third party dll for process. Now I have build property set to target 'any' cpu and deployed it to the 64 bit machine.
When Ii tried to invoke the wcf service got error "80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG"
Now Ii used ProcMon.exe to trace the com registry issue and identified that the process is looking for the registry entry at HKLM\CLSID and HKCR\CLSID where there is no entry.
Came to know that Microsoft will not register the 32 bit com components to the paths HKLM\CLSID, HKCR\CLSID in 64 bit machine rather it places the entry in HKLM\Wow6432Node\CLSID and HKCR\Wow6432Node\CLSID paths.
Now the conflict is 64 bit process trying to invoke 32 bit process in 64 bit machine which will look for the registry entry in HKLM\CLSID, HKCR\CLSID. The solution is we have to force the 64 bit process to look at the registry entry at HKLM\Wow6432Node\CLSID and HKCR\Wow6432Node\CLSID.
This can be achieved by configuring the wcf service project properties to target to 'X86' machine instead of 'Any'.
After deploying the 'X86' version to the 2008 R2 server got the issue "System.BadImageFormatException: Could not load file or assembly"
Solution to this badimageformatexception is setting the 'Enable32bitApplications' to 'True' in IIS Apppool properties for the right apppool.
The problem is that the DLL is registered on the 32 bit version of the windows registry, and the application is using the 64 bit version.
Solution: Go into the Project Properties, Compile tab and click "Advanced Compile Options...". Change "Target CPU" to x86, click OK, save and try again.
Source:
http://www.theogray.com/blog/2009/10/comexception-regdbeclassnotreg-on-64-bit-windows
Has worked for me with an VB 6 COM DLL invoked from a .Net 4 Winforms application
Somewhere in the code you are using, there is a call to the Win32 API, CoCreateInstance, to dynamically load a DLL and instantiate an object from it.
The mapping between the component ID and the DLL that is capable of instantiating that object is usually found in HEKY_CLASSES_ROOT\CLSID in the registry. To discuss this further would be to explain a lot about COM in Windows. But the error indicates that the COM guid is not present in the registry.
I don't much about what the PackAndGo DLL is (an Autodesk component), but I suspect you simply need to "install" that component or the software package it came with through the designated installer to have that DLL and appropriate COM registry keys on your computer you are trying to run your code on. (i.e. go run setup.exe for this product).
In other words, I think you need to install "Pack and Go" on this computer instead of just copying the DLL to the target machine.
Also, make sure you decide to build your code appropriate as 32-bit vs. 64-bit depending on the which build flavor (32 or 64 bit) of Pack And Go you install.
I had the same problem. I tried lot of ways but at last solution was simple.
Solution:
Open IIS, In Application Pools, right click on the .net framework that is being used.
Go to settings and change 'Enable 32-Bit Applications' to 'True'.
In 64 bit windows machines the COM components need to register itself in HKEY_CLASSES_ROOT\CLSID (64 bit component) OR HKEY_CLASSES_ROOT\Wow6432Node\CLSID (32 bit component) . If your application is a 32 bit application running on 64-bit machine the COM library would typically look for the GUID under Wow64 node and if your application is a 64 bit application, the COM library would try to load from HKEY_CLASSES_ROOT\CLSID. Make sure you are targeting the correct platform and ensure you have installed the correct version of library(32/64 bit).
Long solved I'm sure but this might help some other poor soul.
This error can ocurre if the DLL you are deploying in the install package is not the same as the DLL you are referencing (these will have different IDs)
Sounds obvious but can easily happen if you make a small change to the dll and have previously installed the app on your own machine which reregisters the dll.
I had run into the same problem. I added reference of Microsoft.Office.Interop.Excel COM component's dll but Office was not installed on my system it wont give compile time error. I moved my application to another system and ran it..it worked successfully.
So, I can say in my case it was the system environment which was causing this issue.
I had this problem and I solved it when I understood that it was looking for the Windows Registry specified in the brackets.
Since the error was happening only in one computer, what I had to do was export the registry from the computer that it was working and install it on the computer that was missing it.
I was getting the below error in my 32 bit application.
Error: Retrieving the COM class factory for component with CLSID
{4911BB26-11EE-4182-B66C-64DF2FA6502D} failed due to the following
error: 80040154 Class not registered (Exception from HRESULT:
0x80040154 (REGDB_E_CLASSNOTREG)).
And on setting the "Enable32bitApplications" to true in defaultapplicationpool in IIS worked for me.
For me, I had to install Microsoft Access Database Engine 2010 Redistributable and restart my computer.
This happened to me when I startup eclipse for a workspace and not other workspaces. In that workspace I had a *.ts file opened with "JS editor". Error occurred in spite of having correct file association in Preferences. Other *.ts file opened without error. To get around this, in "Open Resource" (ctrl-shift-r), I used the "Open With" button and selected "JS Editor", and the file opened without problem. After that eclipse knows the editor to use for that file. I solved the problem for one particular file type, but solution probably applies to all file types. Hope this helps someone. Thanks for reading
Check if the MS Office and MS Excel is installed on that server.

Non-activeX DLL in a VB6 application fails to load in Outlook 2010

I have a VB6 app that utilizes a non-activeX DLL (non-registering).
It's declared via the classic Public Declare Function "Function Name" Lib "Library.DLL" syntax.
On my dev machine (XP) it works fine but when I deploy to Vista or Win7 I'm constantly greeted with a Run Time Error 48 - File Not Found for the DLL in question.
I have tried copying that DLL to every directory I can think of including every environment path on the test machine and the app path too.
These are all 32-bit test environments so it's not a SysWow64 issue.
Possibly throwing a wrench into the mix is the fact that the application in question is an Outlook COM Addin.
I managed to install VB6 on Win7 and was able to run a tiny sample app that utilizes this DLL (outside of the Outlook process) so I know it works PROVIDED the DLL is located in App path. If I call App.Path from my DLL when I run it on the test environment it shows, to no surprise, my installation directory however the DLL is there.
I tried turning off UAC. I tried making the App.Path directory permissions open to everyone, still no dice.
According to the details you give, it looks like placing the DLL in the path of standard Add-in locations would help.
I believe the first place a DLL search looks is the directory that the EXE loaded from, so your DLL's App.Path won't be used.
Are you sure that you tried installing this DLL into System32? Into Windows?
Aside from that you should be ble to create a PATH (messy) or an isolation manifest for the calling code (VB6 if I'm following you) that specifies DLL Redirection to a relative path (i.e. a subfolder under the folder with your VB6 code in it).
See Dynamic-Link Library Search Order
You may want to check the DLL's own dependancies. You will get the same error if it couldn't load the DLL in question or some DLL 20 levels deep in the dependancy chain.

On Windows7, regsvr32 doesn't write to HKCR\CLSID

I have created a new simple COM object in Visual Studio 2008 using the ATL-wizard. The object has a single class and simple methods. The ATL-wizard did generate .rgs-files for my class.
When I run regsvr32 Simple.dll on my XP machine the class is registered, information shows up in HKCR\Simple.SimpleObject and in HKCR\CLSID\{guid} as I expect.
However, on my 64bit Windows 7 machine it's not the same. I run regsvr32 as administrator the parts in HKCR\Simple.SimpleObject show up. But the part in HKCR\CLSID never gets there. And hence I cannot create new instances. (Being desperate I have tried both regsvr32 in System32 and in SysWOW64, same effect.)
Why dont regsrv32 put data into HKCR\CLSID?
HKCR is an alias for HKLM\Software\Classes but it doesn't show everything. Look in HKLM\Software\Wow6432Node\Classes\CLSID for the registered {guid}. Which is where c:\system32\syswow64\regsvr32.exe writes them.
You did mention that you already tried that. There's something really wrong with that, you cannot arbitrarily run either version of Regsvr32.exe and get the same DLL registered. A 32-bit DLL cannot be loaded in a 64-bit process. In other words, there's no way for the 64-bit version of Regsvr32.exe to register a 32-bit COM server. And the other way around. Why you didn't get an error message is unguessable from here, the only sane explanation is that you somehow didn't actually run the right version of Regsvr32.
To really debug this, use SysInternals' ProcMon utility. Its trace shows you how the ATL registrar is writing the keys in the registry.
32bit applications and components are getting redirected to a different part of the registry. If you are browsing the registry with the 64bit version of regedit you will not find it at the location you expect.
Therefore your component should register itself in HKEY_CLASSES_ROOT\Wow6432Node\CLSID.
In this registry path it should be visible to all 32bit applications.
See also:
Windows 64-bit registry v.s. 32-bit registry
David Broman's CLR Profiling API Blog: WOW64 and Your Profiler
We just had a similar issue here, Regsvr32 was not reporting an error, but nothing appeared to be written to the registry.
Running 'As Administrator' seemed to do the trick.

Register COM reference to 64-bit Windows 7 machine

I am writing a C# program that interface with COM object through COM interop.
I have a third-party program that register itself as the COM server when I execute the Application. This works fine in 32-bit Windows Vista and I can interface with the interop just fine. (The reference show up in "COM" tab from Visual Studio when you click "Add Reference")
However, the reference does not show up in "COM" tab on my 64-bit Windows 7 machine after I execute the application. Any thoughts, why would this happen? I actually tried using regsvr32.exe to register the application manually but it didn't work either (error message saying "entry-point DllRegisterServer was not found)
You are not going to be able to use it as long as it doesn't show up in the COM tab. The regsvr32.exe utility is for DLLs, this however sounds like an EXE. If it is a DLL then it needs to be registered with the 32-bit version of regsvr32.exe, the one in c:\windows\syswow64. If it is an EXE then the normal way to get it to register itself is by running it with the /regserver command line option.
Mumble.exe /RegServer
Additionally, if this is a DLL or an EXE for which you don't have a 64-bit proxy/stub then you'll have to force your app to run in 32-bit mode. Project + Properties, Build tab, Platform Target = x86.
If all else fails, you really do need support from the vendor of this program. Surely they'll have an update available that is verified to work properly on 64-bit operating systems. If they are no longer around, running this in a virtual machine is always a possibility.
If it is a managed dll then you might try using RegAsm
REGASM AssemblyName.dll /tlb:AssemblyName.tlb
You may find this helpful as I needed to recompiled and build 64 bit proxy stub for the COM server from C++ myself and it kept failing when trying to register the server using /regserver. Here is and thread from miscrosoft that helped me resolved this issue. Basically you need to use this instead /RegServerPerUser, but go through the thread if you get into this situation after the answers from above.
http://social.msdn.microsoft.com/Forums/en/vcprerelease/thread/11f01ceb-52a4-438f-b7ef-727ce7a3e191