Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.

msvcr90.dll is missing

Rob1
Beginner
779 Views

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
0 Kudos
12 Replies
Steven_L_Intel1
Employee
779 Views
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?
0 Kudos
Rob1
Beginner
779 Views
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
<<<<<<
0 Kudos
Steven_L_Intel1
Employee
779 Views
I am going to move this thread over to the MKL forum.
0 Kudos
Rob1
Beginner
779 Views
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
0 Kudos
Rob1
Beginner
779 Views
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...
0 Kudos
Rob1
Beginner
779 Views
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
0 Kudos
Steven_L_Intel1
Employee
779 Views
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.
0 Kudos
Rob1
Beginner
779 Views
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.
0 Kudos
Steven_L_Intel1
Employee
779 Views
It would do no harm to place the MKL DLLs in the same folder as your EXE.
0 Kudos
Rob1
Beginner
779 Views
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.
0 Kudos
Steven_L_Intel1
Employee
779 Views
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.
0 Kudos
Bernard
Valued Contributor I
779 Views
>>>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).
0 Kudos
Reply