My client has Windows 2012 R2 64-bit running in a virtual machine. I gave the client a 32-bit program compiled with VB6, which is failing on this line:
Set Run.FileSys = CreateObject("Scripting.FileSystemObject")
where Run.FileSys has type Variant. This program has run on many, many systems over the years, but in this case it fails with
Run-time error '429':
ActiveX component can't create object
When the client runs
regsvr32 scrrun.dll
in the SysWow64 folder, it says it was registered successfully. I instructed her to run the following:
reg query "HKEY_CLASSES_ROOT\Scripting.FileSystemObject\CLSID"
reg query "HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings\Enabled"
reg query "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings\Enabled"
It says that the CLSID value is {0D43FE01-F093-11CF-8940-00A0C9054228}, and the "Enabled" keys (which could be used to disable the script host) are not present.
Examining the file SCRRUN.DLL in the SysWow64 folder, its version number is 5.8.9600.17415.
I have access to another instance of Windows 2012 R2, and my program runs without error on this computer. We compared output of Dependency Walker on my computer versus the clients computer. On both computers, the Dependency Walker output looks the same until a certain point in the sequence. Here is a the last part of the output from my computer that works:
Loaded "SXS.DLL" at address 0x681A0000 by thread 1.
Loaded "DWMAPI.DLL" at address 0x73E30000 by thread 1.
Loaded "CLBCATQ.DLL" at address 0x755D0000 by thread 1.
Loaded "SCRRUN.DLL" at address 0x67BB0000 by thread 1.
Loaded "VERSION.DLL" at address 0x74910000 by thread 1.
Here is the same section from the client's computer that has the failure:
Loaded "SXS.DLL" at address 0x72B70000 by thread 1.
Loaded "DWMAPI.DLL" at address 0x724F0000 by thread 1.
Loaded "CLBCATQ.DLL" at address 0x74DE0000 by thread 1.
Loaded "CRYPTSP.DLL" at address 0x747E0000 by thread 1.
Loaded "RSAENH.DLL" at address 0x74710000 by thread 1.
Loaded "BCRYPT.DLL" at address 0x747C0000 by thread 1.
Thread 2 started in "NTDLL.DLL" at address 0x77324A00.
Thread 3 started in "NTDLL.DLL" at address 0x77324A00.
Thread 4 started in "COMBASE.DLL" at address 0x74C8D7E0.
First chance exception 0xC000008F (Float Inexact Result) occurred in "KERNELBASE.DLL" at address 0x75BC4598 by thread 1.
First chance exception 0xC000008F (Float Inexact Result) occurred in "KERNELBASE.DLL" at address 0x75BC4598 by thread 1.
Thread 2 exited with code 0 (0x0).
Thread 3 exited with code 0 (0x0).
Thread 1 exited with code 0 (0x0).
Exited "VB6SCRIPTINGTEST.EXE" (process 0x94) with code 0 (0x0) by thread 4.
So that whereas the program should be loading SCRRUN.DLL, it loads CRYPTSP.DLL and others. The client says that drive encryption is not turned on. My not-really-educated guess is that this is the result of a virus protection inserting itself into the process. The client has MacAfee Virus Scan Enterprise 8.8 running, and does not have authority to turn it off.
The client has just done a test that makes me doubt this hypothesis about the virus scanner. She created her own VBScript, VB6 program, and VB.Net programs that create a Scripting.FileSystemObject. The results are:
- VBScript: Success (I suppose this must be 64-bit?)
- VB6 (32-bit): Failure
- VB.Net, 32-bit: Failure
- VB.Net, 64-bit: Success
So it appears that nothing is blocking the 64-bit version of SCRRUN.DLL, but the 32-bit version doesn't work. I'd like to tell the client to reinstall Windows Scripting Host, but I don't know how that can be done or if it is possible. Does anyone know how I can resolve this?
The client was able to restore the target computer (although I'm not clear what form the restore actually took). She found that a test program that called
CreateObject("Scripting.FileSystemObject")would succeed after the restore, but after running the installer program I provided, the test program would fail.The installer program was the VB6 setup program from way back. I noted that it should not overwrite any dependencies with older versions, but it does seem to attempt to register every dependency, whether a new version had been installed or not. As an experiment, I stripped all dependencies out of the installer that come preinstalled with Windows 2012 R2. This solved the problem!
It was some hassle for the client to restore the target computer and try the experiments, so I wasn't able to narrow down to anything more specific, nor do I understand why this problem didn't happen on two other examples of Windows 2012 R2 that I have access to. I am only left with the suspicion that the problem was caused by calling the Windows API function that registers some DLL, TLB, or OCX file that did not need it. I have subsequently determined that many of the dependencies that were packaged into this installer are files that come preinstalled with Windows XP SP3 and everything after, so I am permanently removing them from the installer.