msvcr90.dll is missing

[Rob1]

Hi,

I have a compiled fortran exe that is running fine on about 15 machines, however on 1 machine i am having problems.

On the problem machine, most of the time when it is run the command window closes immediately without any windows's message. However in the process of adding debugging messages to the code, one build does generate the windows message "The program can't start because MSVCR90.dll is missing from your computer. Try reinstalling the program to fix the problem".

The crash occurs when NRM2 (from BLAS95) is called.

I reinstalled the MS VC++ 2008 SP1 redistributable, but this did not change the outcome.

I ran dependency walker on the problem machine, and it didn't show any problems. Attached should be the dependency walker dwi file from problem machine (BAD.dwi) and a dwi file from a machine that works (GOOD.dwi).

I noticed that the path of the MSVCR90.dll is slightly different between the two (different versions?), not sure if that matters:

GOOD:c:\\windows\\winsxs\\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4940_none_50916076bcb9a742\\MSVCR90.DLL

BAD:c:\\windows\\winsxs\\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\\MSVCR90.DLL

Any help is greatly appreciated.

thanks,

rob

[Steven_L_Intel1]

What you show is a bit puzzling. I would not expect the same executable to generate references to two different versions of msvcr90.dll, yet the .dwi shows that DLL as directly referenced by your executable, not from a DLL it calls. Are you actually copying the EXE to the other system?

As for the difference in the paths, that does indicate two slightly different versions of msvcr90.dll, but I don't think that's the issue as otherwise you would get a different error. Also, that the error happens when you call NRM2 suggests that there's a dynamic load going on and this is what is failing. It looks as if you're calling into MKL, is that right?

[Rob1]

The exe is part of an installer msi.

Yes, i'm using the MKL.

Here is the code that causes the crash (on the problem machine):

>>>>>>

FUNCTION normalize3(A)

! returns normalized vector of A

USE BLAS95

IMPLICIT NONE

!-------------------- begin function parameters --------------------

REAL*8, DIMENSION(3) :: normalize3,A

!-------------------- end function parameters --------------------

normalize3 = A/NRM2(A) ! NRM2 computes the euclidean norm

RETURN

ENDFUNCTION normalize3

<<<<<<

[Steven_L_Intel1]

I am going to move this thread over to the MKL forum.

[Rob1]

I have tried installing the same c++ redistributables that are on the working machine, onto the nonworking machine. The file versions detected by dependency walker are now the same on both machines, but the result is still the same (still crashes in the same place as before).

I have attached the latest DWI file from the bad machine (MAINkm5.dwi).

Here are the installed redistributables on the bad machine:

And here is the good machine:

I am out of ideas. Any help is greatly appreciated.

rob

[Rob1]

I have found a second machine that it won't run on.

I tried running two different exes on this machine and got two different errors.

The first required a ninja fast screen capture:

The error with the second exe is:

So do i need to include these dlls with the installation then i assume? So far i have been just including the dlls that dependency walker detects, should i be installing an mkl redistributable or something? I seem to have to deal with dll horrors every time a new mkl function is used in my code, seems like i'm doing something wrong...

[Rob1]

I have included mkl_avx.dll and mkl_def.dll with the installation (so they reside in the same directory as the exe).

The exe runs now on both problem machines so i guess the problem is solved at least temporarily.

It seems like i'm going about this the wrong way. It shouldn't be this painful to get an exe working.

What is the recommended way to get these dlls (and other unknown dlls in the future) on the user's machine? If i am to include them with the msi, how do i know which dlls to include especially when dependency walker does not detect that they are needed.

I see this problem happening again in the future.

Help?

rob

[Steven_L_Intel1]

The most recent error you saw with msvcr90.dll happens when the executable (or a DLL it uses) references a DLL via the manifest as a shared assembly, but a DLL by that name is also found in PATH (or in the executable folder). This conflict leads to that particular error.

For the compiler, a Windows Installer Merge Module is provided for its run-time DLLs. I don't see that MKL offers something similar.

[Rob1]

Yeah i had added MSVCR90.dll to the exe directory to see if that would fix things but it is normally not included (I have microsoft_vc90_crt_x86_x64.msmin the installer).

So what to do about the mkl dlls? Continue testing the exe on various computers to see if any dlls are missing(since dependency walker does not always seem to detect them) and if they are do a quick ninja screen capture of the dos window to determine which dlls? Theninclude those dlls with the install?

Thanks for your help again.

[Steven_L_Intel1]

It would do no harm to place the MKL DLLs in the same folder as your EXE.

[Rob1]

Ok, that's what i'll be doing.

Is there a way to know before i distribute the installer to a user which dlls will be needed? Dependency walker seems to be hit or miss, unless i'm missing something. Should i be including all of the mkl dlls? I'd prefer to keep the size of the installer to a minimum if possible.

[Steven_L_Intel1]

Dependency Walker will tell you which DLLs are linked with the EXE, but not about any loaded dynamically. I don't know how to capture that.

[Bernard]

>>>Dependency Walker will tell you which DLLs are linked with the EXE, but not about any loaded dynamically. I don't know how to capture that>>> You can always run your application under windbg.Please enable an options which prints the loaded libraries by NtLoader function(s).