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

.dll missing from compiled Fortran executable

Feng__Jesse
New Contributor II
9,816 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 II
9,279 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
6,592 Views

See Re: libmmdd.dll libifcoremdd.dll is needed in Deployment - Intel Community

I really wish Intel would go back to including this with the compiler install - it baffles me that it was left out.

Feng__Jesse
New Contributor II
6,583 Views

Hi Steve,

 

Thanks for the response! I installed that and now it doesn't say missing dll anymore, but it still says "The application was unable to start correctly (0xc000007b). Click OK to close the application."

 

I guess copying the dll files to the directory did solve the problem, except now I have another problem.

0 Kudos
Steve_Lionel
Honored Contributor III
6,573 Views

Try going to The latest supported Visual C++ downloads (microsoft.com) , download and install the Visual Studio 2019 runtime for x64 and also the one for x86.

Feng__Jesse
New Contributor II
6,553 Views

Hi Steve,

Those were already installed. I first tried to use the "repair" option for both. I still get the same error. Then I tried to uninstall both and re-install both. The problem persists. Thanks for the help so far, are there anything else I can try?

To clarify, I made sure to re-build the solution each time.

Jesse

0 Kudos
Steve_Lionel
Honored Contributor III
6,549 Views

What I suggest is to download Dependency Walker , run it, open your executable. Wait for it to finish analyzing, click File > Save. Save the .dwi file somewhere. Put it in a ZIP file and attach to a reply here so that we can look at it. Be sure to choose the correct download (32-bit or 64-bit) for your application. Don't be concerned by errors it reports - many of them are false - but the rest of the info will be useful.

Feng__Jesse
New Contributor II
6,545 Views

Here is the dwi file. Thank you very much!

 

Jesse

0 Kudos
Arjen_Markus
Honored Contributor I
6,443 Views

Note there is a newer version (rewrite) of Dependency Walker at https://github.com/lucasg/Dependencies.

Steve_Lionel
Honored Contributor III
6,435 Views

Nice to see that, but it's less useful in cases such as this as it doesn't support saving a results file (like the .dwi). Still, if I get an EXE I can use this to prod it. Thanks for the pointer, @Arjen_Markus .

Steve_Lionel
Honored Contributor III
6,524 Views

Ah, this is a Debug build. You can run this only from within Visual Studio or an Intel Fortran Command Line Build environment. (Start > Intel oneAPI 2021 > Intel oneAPI Command Prompt for x86.

Feng__Jesse
New Contributor II
6,517 Views

Hi Steve,

 

Thanks for checking it out.

I am not sure if I mixed up the builds. But I made sure this is the release build this time. If it still says debug, that could be where I need to look at in settings.

Nevertheless, even when I try to run the program through the command Prompt, it still gives the same error.

 

Jesse

0 Kudos
Steve_Lionel
Honored Contributor III
6,497 Views

Are you using Visual Studio 2015? Your program is linked to its libraries - perhaps there's something explicit in your project that does that. Install the x86 (32-bit) package from Download Microsoft Visual C++ 2015 Redistributable Update 3 RC from Official Microsoft Download Center

Feng__Jesse
New Contributor II
6,480 Views

I see. That could be the problem. I am using Visual Studio 2019.  The runtime I downloaded from earlier replies are for VS 2015 - 2019 though. I will get that download and see what happens.

 

Thanks!

0 Kudos
Feng__Jesse
New Contributor II
6,378 Views

Hi Steve,

 

To follow up on this thread. I have installed Microsoft Visual C++ 2015 - 2019 Redistributable from https://visualstudio.microsoft.com/downloads/. It installed it on my computer, I restarted the PC as requested, and recompiled the program, but I still cannot get it to work. I put the program compiled in release into the dependency program, and the results are attached.

 

If you can take a look and let me know what I can do that would be greatly appreciated!

 

Some information: my computer currently has a whole lot of redistributables: 2005, various updates of 2008, 2010, various updates of 2012, various updates of 2013, and 14.29.30037 of 2015-2019 x64, and 14.28.29914 of 2015-2019 x86.

 

Should I consider uninstall all these, as well as visual studio and one-API and reinstall everything?

 

Jesse

0 Kudos
Steve_Lionel
Honored Contributor III
6,351 Views

The .dwi does not show any missing DLL errors. What exact error message are you seeing? Screenshot, please.

Feng__Jesse
New Contributor II
6,349 Views

error screenshot.PNG

Initially, I had the DLL errors. When I put the missing DLL directly into the directory where the executable is, I get the error above. Then I installed the various libraries and didn't have to put the DLLs directly in the running folder, and I still get the error above. Last time you mentioned you saw the program is linked to  Visual Studio  2015, which I said I shouldn't be using 2015 but 2019 with oneAPI for Fortran.

 

Additionally, the program runs fine if I run it in Visual Studio. But when I take the compiled executable outside, it does this.

 

Jesse

0 Kudos
Feng__Jesse
New Contributor II
6,339 Views

Hi Steve,

 

I have an update. A colleague of mine who did not uninstall her Parallel Studio 2019 Update 5 does not have this issue. Her parallel studio is still expired, but it seems that something parallel studio installs but oneAPI doesn't can solve the issue.

 

The problem is - I cannot reinstall parallel studio because I don't have a valid license anymore.

 

Jesse

0 Kudos
Steve_Lionel
Honored Contributor III
6,328 Views

The .dwi you attached still showed the VS2015 MSVCR140.DLL being used. There were also a bunch of other DLLs referenced with names I did not recognize.

Feng__Jesse
New Contributor II
6,293 Views

Hi Steve,

 

Sorry for coming back to this question sporadically as I have to also focus on completing my research work.

 

I was just thinking about how the executable can run successfully inside Visual Studio but cannot outside of it. Is it ridiculous to think that VS knows the correct link to the libraries and needed runtimes but when compiling, there is a setting missing somewhere for the compiler and so the compiled code doesn't know after being compiled? If so, where can I go to look at VS's linking paths for compiling a code and running a code inside VS? If I can compare the two files, perhaps I can correct it.

 

Jesse

0 Kudos
Steve_Lionel
Honored Contributor III
6,283 Views

What happens is that VS adds the directories containing debug DLLs to PATH when starting the process to run under the debugger. The compiler isn't involved in this. The idea is that you run a debug build under control of the debugger (you can also run without debugging in VS.) If you want to run outside the VS environment, build a Release configuration (or choose non-debug libraries in the property for that.)

The debug DLLs are not in the same system directory the release DLLs are.

Feng__Jesse
New Contributor II
6,284 Views

Hi Steve,

 

I could build debug and release versions of the code and run them inside VS. Before, I could also run both builds outside the VS, and now I can't run either outside. So I am a bit confused about if I am not compiling the right release build following your response?

 

Jesse

0 Kudos
Reply