Repository navigation
Fails to import on windows under non-conda-managed Python installs #137
Description
The intel python distribution has these instructions for windows:
https://www.intel.com/content/www/us/en/developer/tools/oneapi/distribution-python-download.html?install-type=pip&python-pip=python-3_12&operatingsystem-pip=linux&packagetype-pip=idp-allcomponents
If I pick a python installer for windows from https://www.python.org like this:
https://www.python.org/ftp/python/3.13.11/python-3.13.11-amd64.exe
And I do NOT check the box 'Add python.exe to PATH' (note that it is not checked by default), then after installing these intel python packages, numpy will fail to import, throwing an error (ImportError) about being unable to find DLLs for _multiarray_umath.
Before the error from python about not being able to load modules, I see a warning from mkl-service 'UserWarning: mkl-service failed to import ...'. Not sure if this package in particular is the culprit, but there is something wrong with the intel python packages related to numpy.
Full log:
>>> import numpy
C:\Users\david\AppData\Local\Programs\Python\Python313\Lib\site-packages\numpy\__init__.py:121: UserWarning: mkl-service package failed to import, therefore Intel(R) MKL initialization ensuring its correct out-of-the box operation under condition when Gnu OpenMP had already been loaded by Python process is not assured. Please install mkl-service package, see http://github.com/IntelPython/mkl-service
from . import _distributor_init
Traceback (most recent call last):
File "C:\Users\david\AppData\Local\Programs\Python\Python313\Lib\site-packages\numpy\_core\__init__.py", line 22, in <module>
from . import multiarray
File "C:\Users\david\AppData\Local\Programs\Python\Python313\Lib\site-packages\numpy\_core\multiarray.py", line 11, in <module>
from . import _multiarray_umath, overrides
ImportError: DLL load failed while importing _multiarray_umath: The specified module could not be found.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "C:\Users\david\AppData\Local\Programs\Python\Python313\Lib\site-packages\numpy\__init__.py", line 124, in <module>
from numpy.__config__ import show_config
File "C:\Users\david\AppData\Local\Programs\Python\Python313\Lib\site-packages\numpy\__config__.py", line 4, in <module>
from numpy._core._multiarray_umath import (
...<3 lines>...
)
File "C:\Users\david\AppData\Local\Programs\Python\Python313\Lib\site-packages\numpy\_core\__init__.py", line 48, in <module>
raise ImportError(msg) from exc
ImportError:
IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW TO SOLVE THIS ISSUE!
Importing the numpy C-extensions failed. This error can happen for
many reasons, often due to issues with your setup or how NumPy was
installed.
We have compiled some common reasons and troubleshooting tips at:
https://numpy.org/devdocs/user/troubleshooting-importerror.html
Please note and check the following:
* The Python version is: Python3.13 from "C:\Users\david\AppData\Local\Programs\Python\Python313\python.exe"
* The NumPy version is: "2.3.2"
and make sure that they are the versions you expect.
Please carefully study the documentation linked above for further help.
Original error was: DLL load failed while importing _multiarray_umath: The specified module could not be found.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "<python-input-0>", line 1, in <module>
import numpy
File "C:\Users\david\AppData\Local\Programs\Python\Python313\Lib\site-packages\numpy\__init__.py", line 129, in <module>
raise ImportError(msg) from e
ImportError: Error importing numpy: you should not try to import numpy from
its source directory; please exit the numpy source tree, and relaunch
your python interpreter from there.
Activity
[-]Fails to import on windows if folders are not under `%PATH%[/-][+]Fails to import on windows if folders are not under `%PATH%`[/+]david-cortes-intel commentedon Dec 31, 2025
Actually it also fails even if checking the option to add to
%PATH%.[-]Fails to import on windows if folders are not under `%PATH%`[/-][+]Fails to import on windows under non-conda-managed Python installs[/+]antonwolfy commentedon Jan 8, 2026
@david-cortes-intel, could you please describes exact steps you did? I tried locally, but can't replicate the fault.
Have you completed the step
Set Up Your Environment? And so used the created virtual environment?For me it was:
david-cortes-intel commentedon Jan 8, 2026
Steps:
%PATH%.pip install -i https://software.repos.intel.com/python/pypi numpy scipy dpnp dpctl tbb4py(without creating a venv).antonwolfy commentedon Jan 8, 2026
I believe the instruction requires
Set Up Your Environmentstep to be completed (and to have the virtual env created) to have everything working smoothly.urob commentedon Jan 8, 2026
I believe this is one of the cases where a dynamic detection, as suggested here, would be better than hardcoding the dll path.
If you want to test it, you could try installing from the
numpy-mklrepo. Make sure to uninstallmkl-serviceprior to installing, otherwise it won't work. (There's no support fordpnp,dpctlandtpp4pyfor now).This should work both for virtual environments and for global installs.
david-cortes-intel commentedon Jan 8, 2026
Still doesn't work with a virtual environment created per the instructions in the page.
And if that's a necessary condition, it's by the way not made clear in the requirements, and the instructions are quite undiscoverable since the arrow for 'Set Up Your Environment' doesn't look expandable until hovering the mouse over it:
david-cortes-intel commentedon Jan 8, 2026
Those work on virtual environments, but on user installs throw a similar error:
Details
antonwolfy commentedon Jan 8, 2026
I still wasn't able to reproduce that.
Just wanted to double check that it is not the case?
antonwolfy commentedon Jan 8, 2026
Yes, I agree, it looks confusing. But I have no clue why that works this way. It doesn't relate to that repo. I'll try to investigate how it's rendering and who is responsible for that, but as for now lets leave that out of the scope for that issue.
david-cortes-intel commentedon Jan 8, 2026
No, this is not the case. Here, the interpreter is executed from the default user directory (
C:\Users\<user>), while the files are underAppData\Local\Programs\Python\Python313.david-cortes-intel commentedon Jan 8, 2026
Have you tried a fresh VM?
urob commentedon Jan 8, 2026
What does
pip listsay?(Just ruling out that you configured pip to skip dependencies. If
mklandmkl-servicewere missing, that would generate the same errors.)1 remaining item
antonwolfy commentedon Jan 9, 2026
It seems I was managed to setup the fresh VM and to reproduce a similar issue.
There is no issue for me when virtual env is used:
But the same error without virtual env:
But if I manually do:
the import will work for me.
That is exactly what we do during the init phase of
mkl-servicein the virtual environment only (I believe due to security reasons).And this is the reason I assumed the
Set Up Your Environmentis mandatory pre-condition here.antonwolfy commentedon Jan 9, 2026
@david-cortes-intel, could you please try to do manual call of
os.add_dll_directory(dll_dir)to check if that resolves the issue?antonwolfy commentedon Jan 9, 2026
In case the issue still exists, it'd be great if you can install
Process Monitorinside the VM to inspect DLL import sequence.You will need to create a filter there with
Process Name is python.exeand to apply it.Next to start python console, clear the current session in
Process Monitorto remove the previous output and then doimport numpyin the console.In my case, when the import was failing, it was trying to find `mkl_rt.2.dll, but failed:
david-cortes-intel commentedon Jan 12, 2026
Still fails, even though the file
mkl_rt.2.dllis there.With process monitor, I also see a 'NAME NOT FOUND' log for
mkl_rt.2.dll, plus others forMSVCP140.dllandVCRUNTIME140_1.dll, although later on it does find other files likevcruntime_140_1.dll.david-cortes-intel commentedon Jan 12, 2026
And if I add the DLL directory, then
mkl_rt.2.dllshows as being found, but numpy still fails to import. I still see the same 'NAME NOT FOUND' for the MSVC runtime DLLs though.antonwolfy commentedon Jan 12, 2026
In my setup it tried to load by paths:
with
NAME NOT FOUNDresult.And finally successfully loaded by path:
Might it be a case there is some system configuration issue with the environment you are using?
david-cortes-intel commentedon Jan 12, 2026
I see the same logs. But it still fails to import numpy.
antonwolfy commentedon Jan 12, 2026
Do you see any other DLL from the output of Process Monitor, which can't be loaded?
david-cortes-intel commentedon Jan 12, 2026
No, only MSVC-related DLLs. And it does eventually load some like
vcruntime_140_1.dll.antonwolfy commentedon Jan 12, 2026
In my case the log ends with loading of
C:\Users\gta\AppData\Local\Programs\Python\Python313\Lib\site-packages\mkl_umath\_patch.cp313-win_amd64.pyd.What is the last loaded for you?
david-cortes-intel commentedon Jan 13, 2026
Attaching the log of events from executing
import numpyhere:numpy_import_log.CSV
antonwolfy commentedon Jan 13, 2026
@david-cortes-intel, thank you for the provided logs. I compared your setup with my env.
Based on the log, you don't have the
MSVCP140.dll:while in my env:
Here is the full log:
working_numpy_import.CSV
david-cortes-intel commentedon Jan 13, 2026
Does it mean this library is missing some dependency then? This is what comes by default on python.org builds for windows11.
antonwolfy commentedon Jan 13, 2026
Unfortunately, as I know, our wheel packages do not provide the
msvcp140.dlland it has to be installed separately.antonwolfy commentedon Jan 13, 2026
It differs from the stock NumPy, which distributes
msvcp140.dllas part of numpy wheel package.