Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Failure while registering scrrun.dll 1

Status
Not open for further replies.

CruiseMan

Programmer
Nov 17, 2006
29
US
I have installed a new VB6 package using Setup.exe as I have done many times before. However, I did the installation on an NT 4.0 PC and received and error after the installer told me that some of the system files were too old and that I could click "Yes" to continue and it would update the system files for me. The error I got after re-starting the PC was "GetSystemDefaultUILanguage entry point not found in kernel32.dll". Then after clicking "OK", received another messagebox stating "Failed while registering scrrun.dll". Now every time I try to run a VB program, I get a message like "Cannot create ActiveX object". Help!!!John

 
This sounds as if you made a common error: deploying things you should not try to deploy.

scrrun.dll is one example. This must be installed using the full Scripting package. It can be hard to find since NT 4.0 has been unsupported for many years.

Worse yet force-installing other items can lead to problems like you're seeing or even a system that fails to boot entirely (blue screens, reboot loops, etc.). Part of the problem is that you're picking up DLLs from a different OS that "don't fit" on NT 4.0 (many system DLLs are tailored to a specific OS version now). Another part of the problem is that you have failed to update the PDW's VB6DEP.INI file's [Do Not Redistribute] section to reflect the changes since 1998.

These changes involve DLLs that were once perhaps harmless to redist but now will cause trouble. The source of the changes is a long series of MS KB articles published since 1998. These cover a number of other issues that require various resolutions as well.

The PDW was only meant to be used by naive users on Windows 95/98 systems with a single hard drive. On NT 4.0 it always required a bit more knowledge. It was also replaced in late 1998 by VSI 1.0 and in 2000 by VSI 1.1, which can still be obtained: Visual Studio 6.0 Installer. This requires a bit more study but is a more professional tool.

KB Examples:

PRB: Shdocvw.dll Is Not Included in PDW Setup Package
BUG: Error "Unable to Register MSADO15.TLB" If You Use a PDW Package to Install a VB Application
PRB: Multiple "System Files Are Out of Date" Errors
 
Thanks for that detailed explanation. I have other NT 4.0 workstations that have not had this install done. If I take a copy of the scrrun.dll from one of them and try registering that version on the problem NT station, do you think that would work? If not, any ideas of where I might look for the full scripting package?
 
Would it be easiest just to do a system restore to just before you ran your installation package?

Tom
 
One of the "odd" things I tend to hang onto is ancient CDs accumulated over the years from Microsoft. For a long time when I built an NT4 box I would haul out an old CD for Internet Explorer 4.1, because it contained both the Shell Update and this scripting installer package (scr56en.exe).

Another possible source might be older editions of the Platform SDK (newer versions called Windows SDK). These have been made available in several forms: online install, ISO image download, and physical media (CD, DVD) for a small fee. Currently those still available are limited: Microsoft® Windows® and Platform SDKs.

Other possible sources might be MSDN or TechNet disks from subscriptions your organization may have had. Nobody tosses these out right? Everyone knows you're supposed to archive all this stuff when new editions arrive? Yeah, right.


Aside from tracking items like that down I'm not sure there is a lot of hope. As the Wikipedia article states:
Recently, redistributable versions for older operating systems (Windows 9x and Windows NT 4.0) are no longer available from the Microsoft Download Center.

I don't happen to have it handy here. It would take some archeology to track it down. Perhaps somebody else might have it in a more accessible location. I don't see it around out there online from another source.

Note that it will not install anyway without IE 4.0 or later installed as well. Maybe you could look for a full install package for IE 5.x that will install into NT 4.0? It would probably include Scripting 5.6 as part of the install.
 
One more thought: Your VB6/VS6 CDs might well have a Scripting 1.0 or 2.0 installation package on them someplace. That will be a moldy version lacking features, containing bugs and security loopholes, but it was probably what was expected to be deployed to Win95/98/NT4 when VB6 was first released.

If you track down an old VB6-sourced scrrun.dll you can deploy, don't try to deploy the MSVCRT.dll that scrrun.dep implies as a dependency. That was only good "advice" back in 1998/1999 and replacing your system's MSVCRT.dll now is likely to cause some of the problems you were seeing: PRB: Your Computer Does Not Restart After You Install a Microsoft Visual Basic 6.0 Application That Includes a MSVCRT.dll File.
 
Final remark. ;-)

See Best practices for deploying Visual Basic 6.0 applications for a good deal of general advice. For example:
Prepare the Redist folder

The Redist folder is located on the packaging computer. By default, the Redist folder is located in the following folder:

C:\Program Files\Microsoft Visual Studio\VB98\Wizards\PDWizard

After the Package and Deployment Wizard determines the application's dependencies, the Package and Deployment Wizard tries to locate the files that it has determined must be included with the Setup package. The first location that the Package and Deployment Wizard scans is the Redist folder.

If the Package and Deployment Wizard does not locate the required files in the Redist folder, it tries to locate the files in other folders, such as the System32 folder. This behavior may cause problems because your operating system may contain versions of system files that are not compatible with earlier operating systems. Therefore, make sure that the Redist folder contains the correct versions of any files that the Package and Deployment Wizard copies from your system.
I'm always amazed people let the PDW default to deploying their dev computer's "live" files from the System32 directory. This has always been a bad idea but most shade-tree VBers still do it... after a decade of being told not to.

Why does the PDW still do this? Remember, the PDW was retired in 1998! I recall a readme.txt buried in the VS6 CDs that suggests programmers phase out its usage.

Introducing Visual Studio Installer
 
I was able to locate a copy of scrrun.dll on another NT4.0 workstation that is running the same service pack version of the problem PC. I was able to register that copy on the problem PC. All the VB6 programs fire up fine now with no error messages.

Thanks for all your help and advise.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top