msvcr90.dll is missing

msvcr90.dll is missing

Ritratto di Rob

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

AllegatoDimensione
Scarica BAD.dwi4.18 MB
Scarica GOOD.dwi4.18 MB
13 post / 0 new
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione
Ritratto di Steve Lionel (Intel)

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?

Steve
Ritratto di Rob

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

<<<<<<

Ritratto di Steve Lionel (Intel)

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

Steve
Ritratto di Rob

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

Allegati: 

AllegatoDimensione
Scarica MAINkm5.dwi4.18 MB
Ritratto di Rob

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...

Ritratto di Rob

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

Ritratto di Steve Lionel (Intel)

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.

Steve
Ritratto di Rob

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.

Ritratto di Steve Lionel (Intel)

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

Steve
Ritratto di Rob

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.

Ritratto di Steve Lionel (Intel)

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.

Steve
Ritratto di iliyapolak

>>>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).

Accedere per lasciare un commento.