msvcr80.dll Problems once solved and back again

[stumple]

We have a visual fortran 10 project that uses msvcr80.dll. I think it might be using mixed mode C++/fortran and is why we are seeing this file. I am not the one with the compiler so I am unable to really look at this too much. We only have one license so it makes solving these problems difficult.

The problem is that dependency walker sees this dependency and notifies us it isn't there. What we did in the past was to take this file and include it along with it's manifest in our release setup. Something happened over the last two weeks, maybe it was a windows update or something else. Now when we look at our .dll that visual fortran makes using dependency walker the same error saying that msvcr can not be found comes back. I have been trying to figure out a solution and I have read a few things that suggests we need to compile a manifest in along with the dll and also that we might trying using the /MT or /MD flags.

The other thing is me as a developer am able to take the generated .dlls and register them on my computer but not on a "fresh" computer without all of the development libraries. I did try installing the C++ runtime libraries for 2005 and 2008 to solve this problem but that didn't seem to fix it. We have tried compiling the program in debug mode or release mode.

Basically, we know the symptom of the problem and not why it is occuring or how to fix it.

We added the /MD flag to the command line arguments but I don't know if the compiler actually used it.

Has anyone here experienced a problem like this before and is able to provide a solution?

Many thanks.

[Greg_T_]

Hello,

We have also had some recent trouble with the msvcr80.dll. In our case it was due to a specific version in the windows system side-by-side "winsxs" directory, here's the path:
c:windowswinsxsx86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4053_x_ww_e6967989msvcr80.dll
(I think I typed all of that correctly, but you get the idea).
In this case, I was using VS2005 to edit, compile, and link my IVF DLL project. The Dependency Walker tool (depends.exe) helped me to identify the specific msvcr80.dll dependency and where it was located.

We're pretty sure that this particular msvcr80.dll was installed as part of a security hot fix, maybe by an automatic update, or by our IT support. One work-around was to compile the DLL on a computer that did not have this hotfix, and thus depended on a different msvcr80.dll, and that avoided the problem dependency. This worked for us, but was inconvenient.

Another recent fix is to use VS2008 to compile the Fortran DLL, since that gives a different system dependency, which for me is now msvcr90.dll. And I think we'll be able to include a new redistributable in our software install: vcredist_x86.exe.

Here is the title of another thread with more of the details:
"manifest file selects msvcr80.dll version 8.0.50727.4053 which causes a file not found error"
or
http://software.intel.com/en-us/forums/showthread.php?t=67774

Do you think you've encountered a similar, or perhaps different cause? Having had a problem once, I'm now keen to find out more about other similar problems. If more information is needed, perhaps I can come up with more details.

Regards,
Greg

[IanH]

A crude summary. This is only relevant to applications that dynamically link to the C run time library in some way.

Your development machines have probably had this security update (or one of its relatives) applied: http://support.microsoft.com/kb/971090/.

After that update, anything built on your development machine that dynamically links to the C run time library will (by default) require version 8.0.50727.4053 (or greater) of the C run time library to be on the target machine. If the target machine does not have that version, you will experience problems.

A recommended practice is to always distribute the relevant version of the C run time library with your application. If you use merge modules to do this then the security update applied to your development machines will have updated those merge modules for you. If you use the redistributable package method, then you need to distribute and get your users to install the updated redistributable package (see http://www.microsoft.com/downloads/details.aspx?familyid=766a6af7-ec73-40ff-b072-9112bab119c2&displaylang=en).

If you don't distribute the relevant version of the C run time library with your application, then you are at the mercy of whether the target machine has picked up the updated C run time through some other channel, such as Windows Update.