- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- « Previous
-
- 1
- 2
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi there, this solution does not seem to work for me, I'm using C++. Please check this StackOverflow question for details.
Thank you!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, my x86 compiled executables cannot run, but x64 are able to run. But Visual Studio can run even with x86.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does installing https://aka.ms/vs/16/release/vc_redist.x86.exe make a difference? This is not the same as I linked before.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »