ActiveX component can't create object

Question

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.

Prurigo

Answer 1

It turns out to get this application working under VBScript, I had to do two things.

1. Run RegAsm.exe to register the DLLs.
2. 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.

Prurigo

Nice save! I was banging my head on this one for the last 20 minutes. I'm somewhat frustrated by the lack of helpful error messages from the 32 bit interpreter. – Applesauce

@JeroenLandheer, make it more like 2 hours :P – Lakeshialakey

If someone would wonder "why cscript instead of wscript?" as I did: cscript is just like wscript, but Wscript.Echo outputs to the console and not as message box. – Sidonie

@Gordyll where can I find RegAsm.exe ? – Interlaminate

The other thing is to ensure bit compatibility. My compiler was using "Any CPU" and in fact the MS Office application was 64 bit, per client requirement. After that it worked fine without requiring registry (that can be set at compile time in visual studio). – Esculent

@Interlaminate RegAsm.exe can be found under C:\Windows\WinSxS\ directory. On my system it is C:\Windows\WinSxS\x86_regasm_<some alphanumaric value>\RegAsm.exe – Zone

Answer 2

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.

Romaromagna

I agree with @LeeEnglestone. It is in Advances Settings > (General) > Enable 32-Bit Applications – Paton

Answer 3

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.

Buskus

Answer 4

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.

Gooseberry

but that will make it work in your browser... you can't expect all users will do this in order to use your web, so isn't it a bit useless? – Openhanded

For many applications it would be useless. But for example in our environment our browser application is only used in our company-- so we have control over the settings. (It's an old program, not necessary optimal but it works.) – Parker

Answer 5

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

Tomtoma

Thanks for the reminder; had similar situation as the OP and your comment helped me. – Crevice

Answer 6

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.

Leaseback

Answer 7

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

Overtake

Answer 8

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.

Ism

thanks for putting this we recently started cylance and its causing issues on our macros – Leclaire

Answer 9

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

Trigeminal

Answer 10

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

Pancake

Answer 11

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.

Whodunit

Answer 12

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

Son