Last week I had interesting issue with running cscript to execute wsf jobs on a  Windows Server 2003 x64 Edition Server running SQL Server 2005. Every time Cscript ran, a Microsoft Visual C++ Runtime Library Error popped up.

Error Details:

——————————————

Runtime Error!

Program: C:\winnt\system32\cscript.exe

R6034

An Application has made an attempt to load the C runtime library incorrectly. Please contact the application’s support team for more information.

—————————————————————————–

CScript Visual C++ Runtime Lbrary Error

We have five other SQL Server that run the same job, so I know the job works. In order to find out what was going on, I ran Process Monitor to see what dlls are being called by cscript. As you can see from the error, the Microsoft Visual C++ Runtime library was being called from the Microsoft SQL Server Tools\Binn directory. CScript should be calling the msvcr80.dll from the C:\winnt\WinSxS directory as noted in the screen shot below. (I ran the job and Process Monitor on a system where the job ran correctly.)

CSCript Correctly Calling msvcr80.dll

Now that we know that the incorrect msvcr80.dll is being called, we need to figure out why and how to correct it.

Microsoft WinSxs Directory is for Side-by-Side assemblies and dlls. The Windows Kernel works with Fusion to find the correct dll needed for the application. (Learn more about Fusion). In the case of the working system, fusion was finding the correct msvcr80.dll.

The Result:

The wsf script called SQLDMO.dll for a function call. The working system had an updated version of the dll with a Manifest which pointed to the correct msvcr80.dll.

The problem system had an older version of the dll with no Manifest, so the closest msvcr80.dll was being used after SQLDMO.dll was called.

To fix, The SQLDMO.dll was updated to the latest version and the problem was solved.

With this issue, using Process Monitor was the best tool to figure out what the problem system and the control system were doing since it pointed out the different msvcr80.dlls being used.