DLL compiled in XP works in Win2000 but not in WinXP


We have a DLL that is developed as a customization to a software we use and is supposed to be loaded when you logon to the software.

The library is written in C and compiled using MS VC++.  Even though all the compilation and linking is done in Windows XP the library is loaded successfully in Windows 2000 clients but fails to load in Windows XP clients. The software's log file contains errors such as "The specified module could not be found" (even though the path it shows is correct), "Invalid library" and "Could not load the Custom Library <TAI_custom_handlers> and/or Function Ptr <TAI_custom_handlers_register_callbacks>".  The libraries that succesfully load are registered in the log file as "Successfully loaded the Entry Point Function Ptr <custom_TAI_register_callbacks> for Custom Library <custom_TAI>"

Considering there might be an OS library difference I ran depends.exe on the same DLL, on both W2000 and XP. The only difference seemed to be where the library MSVCR80.DLL was read from.

Windows 2000 uses
Windows XP uses

Any ideas why XP would reject our library (event though all the work is done on XP) while W2000 accepts it?


Who is Participating?
You can find the explanation also on "C Run-Time Libraries" http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx

The MSVCR80.DLL resp. MSVCR80D.DLL libraries are imported via msvcrt.lib resp. msvcrtd.lib. The *80*.dll came with Visual Studio 2005 (also known as Visual Studio version 8). They are not distributed with Windows XP.

The alternative is to keep linking DLL and distribute the MSVCR80.DLL resp. MSVCR80D.DLL with your application.
I'd suggest to check the whole thing using the DependencyWalker (www.dependencywalker.com). Verify two things:

- are any DLLLs reported as "missing" when you openend your module with the app?

- what errors are reported when you use "Profile" with an app that uses your DLL?
Go to menu Project -- Properties (Alt+F7) -- Configuration Properties -- C/C++ -- Code Generation and change the Runtime library setting from "Multi-threaded Debug DLL (/MDd)" to "Multi-threaded Debug (/MTd)" for the Debug configuration. Then do similar actions for Release configuration, i.e. "Multi-threaded DLL (/MD)" replace by "Multi-threaded (/MT)".

After that, your dll should not be dependent on msvcr80.dll.
Cloud Class® Course: Microsoft Windows 7 Basic

This introductory course to Windows 7 environment will teach you about working with the Windows operating system. You will learn about basic functions including start menu; the desktop; managing files, folders, and libraries.

It is likely that the MSVCR80.DLL and MSVCR80D.DLL were installed into your Windows 2000 with some other application or with some service pack.
>>change the Runtime library setting from "Multi-threaded Debug DLL (/MDd)" to
>> "Multi-threaded Debug (/MTd)"

I'd like to add that this is not a good idea, since it will statically link the CRT, which defeats the purpose of using DLLs in the first place. As an additional impact, this introduces an additional allocator for the app and therefore another heap, which may cause cross-module allocations to leave memory leaks.
It depends on purpose and on the intention. It may be easier to distribute a single dll instead of distributing of two dll's. The truth is that linking statically the runtime to DLL may be strange. It makes more sense to use static linking when building .exe.

It is also a question if your dll should use functions implemented in CRT.
>>>> Even though all the compilation and linking is done in
>>>> Windows XP the library is loaded successfully in Windows 2000
>>>> clients but fails to load in Windows XP clients.

We experienced similar things regarding XP and NT4 clients. There were a few main reasons we found out:

1. Some common controls were installed and registered at NT4 but not on XP. In our case it was a 'date picker' control, but we had things to do for nearly any custum control e.g. flexgrid, e. g. license issues or version issues.

2. Normally user's at a XP have lesser rights often controled by system policies. If using controls or components that need access to system part of the registry (HKEY_LOCAL_MACHINE), such access may work a W2K but not at XP. Also, updating ini files located in system or windows folder may work at older OS (and for a developer) but not for a XP user.

3. If developing on XP you might have a .manifest file for your application. .manifest files are a means to have specific registry setting for an executable but do not need to register them in the local registry. That is a good thing but may rise compatibility issues when installing at XP clients and Win2K clients. Assume you are installing without .manifest files your XP installation may fail for this reasons if for example the equivalent registry information was not available at all XP clients. If installing with .manifest it could work on Win2k cause it ignores .manifest files while it fails on XP clients cause the .manifest refers to items which were not available at the target system.

Regards, Alex
TAI-Author Commented:
It seems compiling and linking with MS VC 8 is causing an incompatibility with the software we are customizing. It only supports MS VC 7.

Thanks for the suggestions everyone.
TAI: "It seems compiling and linking with MS VC 8 is causing an incompatibility with the software we are customizing. It only supports MS VC 7."

It is difficult to say the reason. The truth is that it is usual to compile the libraries using the same version of the compiler (if you have sources). On the other hand, the skip from VC 6 to VC 7 was bigger than from VC 7 to VC 8. The VC 7 compiler comes with Visual Studio 2003 and it is likely that a lot of Microsoft applications were compiled with that compiler -- the dll's were distributed with many "standard" applications, like Internet Explorer. It may be the reason why it seems that your application compiled with VC 7 runs everywhere and application compiled with VC 8 has some problems.

I do not know your DLL, but you could try to minimize dependency of your DLL on libraries. Try tomenu Project -- Properties (Alt+F7) -- Configuration Properties -- Linker -- Input  and set the "Ignore All Default Libraries" to Yes. Then compile and follow the errors to learn what function implementations were not found, what libraries do implement them and if you really need them.

Learning the hard way is hard but you will learn more after a while. Solving the problem the easy way (i.e. fast) satisfy customers. The compromise is the answer. Keep ballance ;)

P.S. And try to split the points next time, please. jkr and itsmeandnobodyelse also gave you usefull hints.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.