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

using vars.bat

Valued Contributor III

I installed the latest VS 2019, then the OneAPI Base and the Toolkits including Fortran and MKL. 

I updated to the latest Fortran and reinstalled MKL.

I than downloaded a simple MKL program just to try it out.  

I set the vars.bat file in the MKL, but I get a mkl........1.dll error message cannot find 

I find the dlls in the redist directory for mkl. 

I adjust the path to point to the dll and now it works.  

I cannot see any of the env variables from the var.bat file in the env variables memory. 

Any ideas on what I missed.  

0 Kudos
14 Replies
Black Belt

This is an example of a post in which the guidelines for posting in this forum were mostly ignored, and as a result it is next to impossible to provide a useful response to the specific problem.

In a OneAPI installation with Intel Fortran and MKL installed and integrated into Visual Studio, there are probably 15 instances of scripts named vars.bat. I have such an installation, and it works fine as-is for building and running Fortran and C applications and DLLs, some of which use MKL -- I did not modify any of the batch files.

Please consider the following comments:

1. You wrote: "I set the vars.bat file in the MKL, but I get a mkl........1.dll error message cannot find "

What does it mean to "set" a batch file? Did that "set" action itself cause the error message to be issued? I don't believe so. You have to tell us what you did that may have caused the error message to be issued.  The message itself is one result, but the causes can be many. If you do not tell us, we may have no idea about the cause, or there may be umpteen causes and we do not want to waste time (yours and ours) exploring every one of those.

2. You wrote: "I cannot see any of the env variables from the var.bat file in the env variables memory"

As I wrote above, there are 15 files named vars.bat. Which ones did you run? I do not know how you "see in env variables memory". For the same reasons, I do not know which ones are the env variables.

Any set commands in a batch file take effect only if/when the batch file is executed. Furthermore, if any of those set commands are preceded by a setlocal command in a batch file, the corresponding environment variables may disappear as soon as the batch file finishes running. Batch files can call other batch files, so knowing the execution sequence is important for troubleshooting.

3. You wrote: "Any ideas on what I missed". 

Yes. Please try to remember that almost none of your readers have working crystal balls, divining rods or internet-enabled slide-rules. You have to give complete and precise descriptions of the symptoms and the circumstances.

0 Kudos
Valued Contributor III

To report an issue, please provide the following details about the issue so we can replicate it:

  • Library version   ------------  oneapi mkl  revision 1
  • OS info and version                windows 10 Preview - 21286
  • Compiler version                     oneapi Fortran V2 - latest
  • GCC or Visual Studio version if applicable         VS 2019 Preview
  • Specifics on how to reproduce the problem. Include makefiles, command lines, small test cases, and build instructions

1. I installed the VS 2019 Preview and Vs 2019 

2. I installed the oneapi base kit.  This was followed by using setvars.bat as recommended that executes the set of vars.bat files. 

3. capture2.gif shows the run to set x64 environment for set vars.  The mkl is shown to be initialized. 

4. I created a VS project and added a simple mkl program - see attached zip file. 

5. When I run the project I get the error about the missing dll file - see capture1.gif

6. A search for the missing dll turned it up in six locations, two of them related to mkl directories.  

7. If I add the two directories to the path command - using Environmental Variables entry page in Windows 10 

C:\Program Files (x86)\Intel\oneAPI\mkl\2021.1.1\redist\intel64
C:\Program Files (x86)\Intel\oneAPI\mkl\2021.1.1\redist\ia32

8. The ia32 SLN does not work the x64 version works first time.  

9. If I run the var.bat in the mkl directory for the oneapi it does not fix the problem.  The redist directory locations do not appear to be on the path 


C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\mpirt;
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\mpirt;
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler;
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\compiler;
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2020.4.311\windows\mpi\intel64\bin;
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.1\bin;
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.1\libnvvp;
C:\Program Files\Microsoft MPI\Bin\;
C:\Program Files\Tecplot\Tecplot Chorus 2019 R1\bin;
C:\Program Files\Tecplot\Tecplot 360 EX 2019 R1\bin;
C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;
C:\Program Files (x86)\Microsoft SQL Server\150\Tools\Binn\;
C:\Program Files\Microsoft SQL Server\150\Tools\Binn\;
C:\Program Files (x86)\Microsoft SQL Server\150\DTS\Binn\;
C:\Program Files\Microsoft SQL Server\150\DTS\Binn\;
C:\Program Files (x86)\Google\Google Apps Sync\;
C:\Program Files\MATLAB\R2020a\bin;
C:\Program Files\dotnet\;C:\Program Files\MiKTeX 2.9\miktex\bin\x64\;
C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;
C:\Program Files (x86)\dotnet\;
C:\Program Files\NVIDIA Corporation\Nsight Compute 2020.2.0\;
C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;
C:\Program Files\gnuplot\bin;


- here is one path. 

I tried this on three computers and all repeated the errors. 

I have been right through the documentation online and reread the html files as the programs are installed on a NUC and I cannot see that I have missed something. 


0 Kudos
Black Belt

Several comments, the first being about your posting style rather than the thread topic:

In the second post in this thread, as well as in many of your posts,  which I have viewed in Chrome, Edge and Opera, when you include a quote from another post or a Web page, I have to read the text carefully and critically to distinguish between your quotes of others' writing and your own writing. In the absence of markers or character attributes to distinguish the two groups, I often find myself postponing the reading of the rest of such a post, especially if I do not have a lot of free time at the moment. This is an unnecessary source of confusion and should be easy to avoid.


Now, about your report. In Itemx 2 and 3, you ran the batch file setvars.bat, and the responses appear normal. However, the resulting changes to the environment apply only to that command window and child processes that are run from that console.

Notably, those changes do not apply to a subsequent session of Visual Studio that you start from a desktop shortcut or the VS entry in the Windows Start Menu. Likewise, if you build an EXE or DLL, either from the command window in which you ran setvars.bat or from within Visual Studio, and subsequently attempt to run the resulting EXE (or call the resulting DLL from an application) in a different CMD window or from the Windows Explorer, Desktop, etc., the required environment may not be present, or the environment variables could even be present but have inconsistent values. The EXE/DLL may fail to run or it may run incorrectly.

The policy that Jim D. recommended is a good one: first start a properly configured command window, and run VS using the command line devenv <mySolution>.sln . I do this whenever I use Visual Studio, which is not very often.

Another approach would involve changing the Windows global environment to make it suitable for all sessions that you run using Visual Studio. That, however, is something that I would never do, since I use a number of different compilers (including different versions of Intel Fortran), and I cannot permit a mongrel environment to make my work impossible. Towards this requirement, I often find myself undoing global environment changes that some software installers perform without giving the user an opt-out choice at installation time. Your have to assess this tradeoff for your own setup and usage patterns.

0 Kudos
Valued Contributor III

I appreciate the comment and I will endeavour to correct my writing. 

I only use VS and Intel Fortran so fixing the computer to allow for simple use is no problem as I prefer to not use a command window, so thank you for clarifying the matter.  

As a matter of interest I went back and started to compile the Pardiso based programs that have run for years with out modification using Intel Fortran and MKL. I now get the same error on programs that have compiled on VS 2019 and Parallel Studio.  

Thanks again for the assistance. 

0 Kudos
Valued Contributor III

I removed all of the oneAPI system, where Paradiso program  would not run without fixing the path command. 

After removal, I cleaned out all of the path commands and the directories

I then installed the PSXE 2020.4 and initialized the psxevars and the mklvars batch files. 

I checked the MKL parallel box in the Properties ->Fortran->Libraries

The Paradiso program compiled and then ran properly without asking for the mkl*.dll modules.  

There is a distinct difference between the PSXE 2020 run after installation which finds the mkl-dll.s and ONEAPI which does not.  

I did the installations as required in the installation guides. 


0 Kudos
Valued Contributor III

After a little bit of fiddling - the mklthread.dll is found by VS in the following directory

C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2020.4.311\windows\redist\ia32_win\mkl

The path command contains the following 

C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2020.4.311\windows\redist\ia32_win

It is missing the mkl but it finds it.  


0 Kudos
Black Belt

Those are the 32-bit versions of mkl.

Are you building for 32-bit platform?

Jim Dempsey

0 Kudos
Valued Contributor III
0 Kudos
Black Belt

I thought I heard that 32-bit MKL was no longer available. You might want to check on this.

Jim Dempsey

0 Kudos
Valued Contributor III


you asked in your last post about 32 bit mkl,  this is the computer where I reverted the PS 2020 and installed it clean on a computer that had all the Intel oneAPI removed and cleaned out.  

As the picture shows, there are clearly two versions of the mkl dll's one ia32 and one intel64,  I have a lot of old programs so I tend to stick to stock standard Fortran templates if I can.  The intel64 will work it is just a pain to change and for most of my coding not worth the effort.  

The new oneAPI dll's have all had an extra .1.dll  added to the dll name.  And if my memory serves me correctly and I am not going to reinstall oneAPI to find out - the mkl_intel_thread.1.dll was only in two locations.  I think this is an error on the oneAPI installer for Intel Fortran not a new feature.  You can see the number of locations above.  

So I am not sure what is happening, but it would be nice to fix it. 

0 Kudos

both 32 and 64 bits of MKL are available and supported. it includes the latest ( current ) version 2020.1

0 Kudos
Valued Contributor III

If I install oneAPI -- mkl - then in VS 2019 Preview, I cannot automatically select mkl - it tells me the mkl_intel_thread.1.dll is not found.  

I include the path for the mkl_.dll the system now works as it did for PSXE 2020.  

I reinstalled PSXE on a clean windows to check this and it works.  

Some one has adjusted the path and left out a selection.  

Windows 10 VS 2019 Preview 

0 Kudos


I actually saw similar issue. I got VS 2019 installed, then base toolkit and then hpc toolkit. Then I created a hello world project and enabled MKL in it via Fortran -> Libraries tab.

And it all compiled and linked well. But in runtime I got "Cannot find mkl_intel_thread.1.dll".

The solution is to add path to this DLL. The VS 2019 way is to set Environment in Configuration Properties -> Debugging to "PATH=%PATH%;C:\...mkl\redist\intel64" or -> Debugging to "PATH=%PATH%;C:\...mkl\redist\ia32" for x86 apps. 

The exact path better be checked.

I guess oneMKL integration into VS2019 has a bug. I don't see a good reason I had to do this manually.



For 64-bit application,

0 Kudos
Black Belt

Related issue for you to keep in mind.

I have an app that uses MKL. Using MS VS on Windows

The app builds and runs properly from the MS VS IDE.

However, from the MS VS IDE, should I VTune the app, I get the mkl_intel_thread.dll not found message.

The "fix" for this is to launch an Intel Parallel Studio (x64) command prompt, then

CD to solution folder
devenv mySolution.sln

Now, runs, debug, and VTune work.

Jim Dempsey

0 Kudos