Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28381 Discussions

.dll missing from compiled Fortran executable

Feng__Jesse
New Contributor I
7,197 Views

After building a release solution of my Fortran code using Visual Studio community 2019 and OneAPI HPC package, I tried to run the compiled executable outside of Visual Studio and I encountered 3 errors regarding missing libifcoremd.dll, libmmd.dll, and svml_dispmd.dll.

 

I searched online about this and there were some suggestions to add the .dll's path to the compiler, but I am not sure how to do it in VS2019 since all the posts I saw were for older versions. I never had this issue when I used Parallel Studio before.  Following one post, I copied the .dll files to the running directory and the error instead becomes "The application was unable to start correctly (0xc000007b). Click OK to close the application."

 

I looked under Tools -> Options -> Projects and Solutions but didn't see any option regarding linking paths. I see there is a "command line" option under project properties -> Fortran/Linker. But I am not sure how to include the .dll's path here. Can someone help me out?

 

Thanks!

 

Jesse

0 Kudos
1 Solution
Feng__Jesse
New Contributor I
6,660 Views

Hi Steve,

 

I may have found the problem... Originally, Visual Studio would put the release and debug builds and related files directly in the folder. I.e. project/release, and project/debug. But now as I am compiling in x64, it is putting them in project/x64/release and project/x64/debug.

I noticed this when I tried to clean the project but all the files are still there.

 

However, another project that was compiled in x86, where the release and debug folders are not under x64 still has the issue. So perhaps another thing I did to fix it may have helped:

I was looking around in the One API folder and found a sys_check.bat and it gave me the following error among other messages: 


: debugger -- latest
" Error: Environment variable pointing to INTELGTDEBUGGERROOT folder not set."
" The Visual Studio Integration plugin for the debugger will not work."
" Run the script env\vars.bat to fix this configuration problem."

So I found the file under debugger\env\vars.bat and ran it. The above error is no longer there and now everything works, if compiled under x64. The code compiled with x86 still doesn't. But I am not concerned right now.

 

Thanks for everything!

 

Jesse

View solution in original post

0 Kudos
39 Replies
Steve_Lionel
Honored Contributor III
2,408 Views

This is the first I've seen you say you can't run a Release build outside VS. What error do you get when you try that?

Feng__Jesse
New Contributor I
2,403 Views

Excuse me for not communicating clearly. When I sent those compiled executables' DWI before, they were all built-in release mode. The error is the same as shown above. Also attached here since we are now on page 2.

Feng__Jesse_0-1625265602910.png

 

0 Kudos
Steve_Lionel
Honored Contributor III
2,397 Views

Sorry, I get easily confused these days, with multiple threads describing similar problems. As I wrote earlier, the .DWI you attached shows that it is looking for the VS2015 version of the MSVC library.

I suppose the next thing I'd ask for is to set the project property Linker > General > Show Progress > Show some progress messages, relink, and then zip the buildlog.htm and attach that zip. This will tell me which libraries your EXE is linking against.

Feng__Jesse
New Contributor I
2,368 Views

Hi Steve,

Once again thank you very much for the help on this issue. Sorry it took me a long time to get back here. To recap the issue:

I previously had Parallel Studio for Fortran installed and then the license expired. Then I installed One API Base and then HPC.

Initially, when I tried to run a compiled code outside of Visual Studio, I had a missing dll error which I fixed by downloading and installing a patch from Intel as you directed. Then when I try to run the compiled code outside of Visual Studio, I have the error "The application was unable to start correctly" as shown in previous responses. Just to be clear, the program can run successfully as release and debug modes if I click "start" and run in Visual Studio.

Per your instruction, here is the zipped build log file. I added the compiler output in Visual Studio to the bottom of the original build log where it indicated what libraries the compiler searched once I enabled the show progress in properties.

Once more, any suggestions of the next steps are greatly appreciated. Thank you very much for the help.

Jesse

0 Kudos
Feng__Jesse
New Contributor I
6,661 Views

Hi Steve,

 

I may have found the problem... Originally, Visual Studio would put the release and debug builds and related files directly in the folder. I.e. project/release, and project/debug. But now as I am compiling in x64, it is putting them in project/x64/release and project/x64/debug.

I noticed this when I tried to clean the project but all the files are still there.

 

However, another project that was compiled in x86, where the release and debug folders are not under x64 still has the issue. So perhaps another thing I did to fix it may have helped:

I was looking around in the One API folder and found a sys_check.bat and it gave me the following error among other messages: 


: debugger -- latest
" Error: Environment variable pointing to INTELGTDEBUGGERROOT folder not set."
" The Visual Studio Integration plugin for the debugger will not work."
" Run the script env\vars.bat to fix this configuration problem."

So I found the file under debugger\env\vars.bat and ran it. The above error is no longer there and now everything works, if compiled under x64. The code compiled with x86 still doesn't. But I am not concerned right now.

 

Thanks for everything!

 

Jesse

0 Kudos
BullyWiiPlaza
Beginner
510 Views

Hi there, this solution does not seem to work for me, I'm using C++. Please check this StackOverflow question for details.

 

Thank you!

0 Kudos
Steve_Lionel
Honored Contributor III
2,350 Views

Thanks for the build log. I don't see any problems in it. The next thing I would suggest is to download and run https://aka.ms/vs/16/release/vc_redist.x64.exe which is the Visual C++ runtime for x64. You should have this already, but it may correct the problem. 

If it doesn't, I'd be interested in seeing a new .DWI. Oh, also please open a plain command prompt window (Start, type cmd, run Command Prompt) and type:

set path > E:\path.txt

and attach path.txt to a reply here.

Feng__Jesse
New Contributor I
2,345 Views

Hi Steve,

 

Please see the second reply I sent regarding the original problem.

I am not able to run ifort command in the windows default command prompt window.

Here is the path.txt, and I do see the one api path in it. So I am curious as to how to fix this because I was also not able to do so when I used parallel studio. When I tried to run Abaqus with Fortran, I simply ran Abaqus inside the command prompt that came with the compiler.

 

Jesse

0 Kudos
Steve_Lionel
Honored Contributor III
2,331 Views

I did not expect that you would be able to run ifort from that window - I wanted you to do that so I could see the system PATH. I am curious, though, can you run the program from an Intel compiler environment command prompt?

The value of PATH looks OK to me. Again, I would like to see a .DWI from your EXE in the current configuration.

Feng__Jesse
New Contributor I
2,322 Views

Here is the .dwi of an executable that can run outside of Visual Studio. Compiled in x64.

 

I am able to run the program from an intel compiler environment command prompt now. But I wasn't able to before.

0 Kudos
Steve_Lionel
Honored Contributor III
2,310 Views

Thanks. Now I am going to ask you to do something a bit different. From a command prompt environment where the program runs (you said the Intel compiler command prompt works), run depends.exe (specify the path to it - do NOT double-click from a folder), ask it to analyze your EXE and save a DWI, then attach that.

I am very puzzled that VCRUNTIME140.DLL shows as being loaded - it is finding this in the Windows\System32 folder, and initially I thought it shouldn't be there, but it's there on my system too. What I can't figure out is why it is being loaded instead of one of the VS2019 C++ DLLs.

Feng__Jesse
New Contributor I
2,305 Views

I ran the program like this in the Intel(r) oneAPI Tools console as dependency.exe EpsilonUmatNew.exe

 

It opened the program and loaded the compiled code.

 

The .dwi is attached.

0 Kudos
Steve_Lionel
Honored Contributor III
2,297 Views

I am stumped. The dependency info is identical between the two, but you say one works and one doesn't. I don't know what else to try.

Feng__Jesse
New Contributor I
2,291 Views

No no this version of the compiled code works when I try to run it outside of Visual Studio and inside the OneAPI console. Previously, the compiled program doesn't run outside of Visual Studio AND doesn't run with the OneAPI console.

 

As I mentioned, I found a problem when running sys_check.bat under the Intel/OneAPI directory and it said the following:

: debugger -- latest
" Error: Environment variable pointing to INTELGTDEBUGGERROOT folder not set."
" The Visual Studio Integration plugin for the debugger will not work."
" Run the script env\vars.bat to fix this configuration problem."

 

So I ran env/vars.bat and now everything is good.

0 Kudos
Steve_Lionel
Honored Contributor III
2,282 Views

That should have no effect on the program running. But I am out of ideas to suggest - if you have a workable solution, then that's great.

Feng__Jesse
New Contributor I
2,273 Views

Well, my x86 compiled executables cannot run, but x64 are able to run. But Visual Studio can run even with x86.

0 Kudos
Steve_Lionel
Honored Contributor III
2,258 Views

Does installing https://aka.ms/vs/16/release/vc_redist.x86.exe make a difference? This is not the same as I linked before.

Feng__Jesse
New Contributor I
2,240 Views

I installed that one but the x86 build still cannot run outside of Visual Studio. But I am able to run it in the IA32 console and not the 64 console.

 

When I try to run the dependency walker through the IA 32 console on this compiled code, it takes forever and eventually induces a lot of lag on my computer and I have to terminate the dependency process.

0 Kudos
Steve_Lionel
Honored Contributor III
2,233 Views

Yes, depends has gotten very slow for reasons I don't understand (the program hasn't been changed in years, but something in Windows makes it take a very long time.)

It's too bad you're not getting a better error message.

Reply