CTC: Checkdll: How to Determine if Required DLLs are Available

Note: This software, like all software in H:\Contrib, is user-contributed and is unsupported by CTC staff. The contributor may be willing to provide some assistance with this software.

Some program executables require shared libraries to run. These shared libaries are often in the form of DLLs, or Dynamic Link Libraries. The checkdll.exe program, located in H:\Contrib\Checkdll\, determines whether the shared libraries required by your executable are present. Using this check in a batch script will allow you to check that all of the necessary libraries are accessible as required for a given executable, and gracefully handle the results.

Usage

Checkdll determines whether the necessary dlls are available to run the given command from the current directory.

First add checkdll to your path by running the setup file:

call setup_checkdll

Then run checkdll:

checkdll [-v|--version] myprogram.exe

This sets the cmd shell errorlevel to

0 success
1 arguments incorrect
2 dll not found
3 checkdll.exe internal error

Following is a sample of its output when analyzing an executable called crushd.exe. For each dll found, it prints the name of the dll, the directory where it was found, or "NOT FOUND" if it is missing, and an optional version string, requested by the "-v" command-line option. If a file is visible but unreadable due to privileges, it is listed as "UNREADABLE."

The dlls that are listed in this first section should be copied with your executable unless they are listed as being on the nodes in the list of installed software. For instance, MPI is installed on batch nodes and does not need to be copied. You may need to execute a setup file to put the relevant dlls in your path. For instance, setup_python.bat puts python*.dll in your path.

Warning: These are only on machines with Microsoft Visual Studio installed. If your executable uses these files, you must copy them with the executable to the batch node.

The dlls listed in this category are always on Windows machines with the same operating system. No need to copy.

Using Checkdll in a Batch Job
If you want to be absolutely sure you have all dlls necessary for your job to run on the cluster, insert the following logic into your batch file. If a dll is missing, checkdll will set the errorlevel to 2, which allows your batch file to record the problem in an error log.

call setup_checkdll

checkdll myprog.exe > outfile.txt
if errorlevel 2 goto cantstart

myprog.exe >> outfile.txt

:cantstart
ccrelease

Now, if your executable is missing dlls, it will fail gracefully, leaving you a list of missing files in outfile.txt.

Limitations of Checkdll

Only for native Win32 code, not managed code.
Does not check for the correct version of the dll.
Cannot determine dynamically-loaded dlls.
Does not check the dll's license expiration date.

If an executable fails to load on a cluster node for any of these reasons, no error message is generated , and the batch script will continue to execute.

How to Identify Dynamic and Static Libraries

Many libraries allow you to choose static or dynamic linking by choosing which library you put in your linker's imports list. When two versions of the library exist, the static version will have an "s" appended to the name. Checkdll can help determine which was chosen.

Dynamic and Static Linking in Visual Studio

C, C++, and Fortran codes in Visual Studio always link with an implicit set of standard functions called the runtime library. An option in the Visual Studio project environment determines whether an executable uses a static or dynamic version of the runtime library. The crushd example, above, would not require msvcp*71.dll if it used the static runtime.

You specify the runtime not in the imports list, but in the C/C++ compiler options. You have to open the property page of the project, choose the compiler, and then choose "Code Generation."

The choices that have "DLL" in the name will make your code depend on a dll with the name msvcrt*.dll. This isn't a problem; it just means you have to copy the appropriate dll with your executable to the cluster. You often have no choice in the matter because, if you are linking your executable to a library which linked to the "multi-threaded dll," then your executable should use the same dll in order to avoid conflicting import entries. MSDN has an article on the C run-time libraries.

Contributor
This software was built and installed at CTC by Drew Dolgert. CTC users may email Drew with questions about using checkdll.


Home Services Support

Checkdll: How to Determine if Required DLLs are Available

Note: This software, like all software in H:\Contrib, is user-contributed and is unsupported by CTC staff. The contributor may be willing to provide some assistance with this software. Some program executables require shared libraries to run. These shared libaries are often in the form of DLLs, or Dynamic Link Libraries. The checkdll.exe program, located in H:\Contrib\Checkdll\, determines whether the shared libraries required by your executable are present. Using this check in a batch script will allow you to check that all of the necessary libraries are accessible as required for a given executable, and gracefully handle the results. Usage Checkdll determines whether the necessary dlls are available to run the given command from the current directory. First add checkdll to your path by running the setup file: call setup_checkdll Then run checkdll: checkdll [-v\|--version] myprogram.exe This sets the cmd shell errorlevel to 0 success 1 arguments incorrect 2 dll not found 3 checkdll.exe internal error Following is a sample of its output when analyzing an executable called crushd.exe. For each dll found, it prints the name of the dll, the directory where it was found, or "NOT FOUND" if it is missing, and an optional version string, requested by the "-v" command-line option. If a file is visible but unreadable due to privileges, it is listed as "UNREADABLE." The dlls that are listed in this first section should be copied with your executable unless they are listed as being on the nodes in the list of installed software. For instance, MPI is installed on batch nodes and does not need to be copied. You may need to execute a setup file to put the relevant dlls in your path. For instance, setup_python.bat puts python.dll in your path. Warning:* These are only on machines with Microsoft Visual Studio installed. If your executable uses these files, you must copy them with the executable to the batch node. The dlls listed in this category are always on Windows machines with the same operating system. No need to copy. Using Checkdll in a Batch Job If you want to be absolutely sure you have all dlls necessary for your job to run on the cluster, insert the following logic into your batch file. If a dll is missing, checkdll will set the errorlevel to 2, which allows your batch file to record the problem in an error log. call setup_checkdll checkdll myprog.exe > outfile.txt if errorlevel 2 goto cantstart myprog.exe >> outfile.txt :cantstart ccrelease Now, if your executable is missing dlls, it will fail gracefully, leaving you a list of missing files in outfile.txt. Limitations of Checkdll Only for native Win32 code, not managed code. Does not check for the correct version of the dll. Cannot determine dynamically-loaded dlls. Does not check the dll's license expiration date. If an executable fails to load on a cluster node for any of these reasons, no error message is generated , and the batch script will continue to execute. How to Identify Dynamic and Static Libraries Many libraries allow you to choose static or dynamic linking by choosing which library you put in your linker's imports list. When two versions of the library exist, the static version will have an "s" appended to the name. Checkdll can help determine which was chosen. Dynamic and Static Linking in Visual Studio C, C++, and Fortran codes in Visual Studio always link with an implicit set of standard functions called the runtime library. An option in the Visual Studio project environment determines whether an executable uses a static or dynamic version of the runtime library. The crushd example, above, would not require msvcp71.dll if it used the static runtime. You specify the runtime not in the imports list, but in the C/C++ compiler options. You have to open the property page of the project, choose the compiler, and then choose "Code Generation." The choices that have "DLL" in the name will make your code depend on a dll with the name msvcrt.dll. This isn't a problem; it just means you have to copy the appropriate dll with your executable to the cluster. You often have no choice in the matter because, if you are linking your executable to a library which linked to the "multi-threaded dll," then your executable should use the same dll in order to avoid conflicting import entries. MSDN has an article on the C run-time libraries. Contributor This software was built and installed at CTC by Drew Dolgert. CTC users may email Drew with questions about using checkdll.



© 2008 Cornell University \| Cornell University Center for Advanced Computing \| Copyright Statement