DLL search path problem - MSVCP140.dll #739
Comments
|
@jjerphan @SylvainCorlay is this likely the fmt 11 bug? |
|
At least, that's something that's clearly wrong in this env. |
|
Ping @Klaim, in case you have an idea. |
|
@sp147505 for context, we just released https://github.com/conda-forge/miniforge/releases/tag/24.11.3-2 which addresses a known issue with It would be helpful to us if you would "reinstall" with 24.11.3-2 and report your findings. |
|
I'm not super familiar with how miniforge works so bear with me. What is the path of the working directory when the python command (following the example) is executed? Also could you gather the content of the Usually this kind of thing happens when the environment is setup in a way where Windows cannot find the dependency locally (in the working directory or in the directory of the exe) and will start going through the PATH directories, in which case it will stop at the first matching name, if my memory is correct. If the directory providing the dlls you expect are not in the PATH or if they are but after another directory providing a version of that dll, that might be it. If that's not it, then there are other ways dependencies binaries are selected first which could play a role but I lack info on the context to help figure that out. Note that it wouldnt be surprising if MSVCP140.dll is a special name dll and mcaffee setups the system to force-use it's one to help with some security stuffs. Special names dlls are used in priority over looking in directories.
Note that they should have the same ABI, it's versioned through the name and is supposed to be stable. If it's not, to me that super suspicious. |
|
@sp147505 would you be able to try out with the more recent builds of miniforge? |
|
@hmaarrfk @SylvainCorlay I tried 24.11.3-2 but unfortunately it still has the same problem. Furthermore I noticed that 25.1.1-2 (prerelease) was available but that has the same problem too, sorry. @Klaim At present my CWD for all tests is C:. Happy to try other suggestions. Here's my PATH when once I've started the Miniforge command prompt: PATH=C:\Miniforge;C:\Miniforge\Library\mingw-w64\bin;C:\Miniforge\Library\usr\bin;C:\Miniforge\Library\bin;C:\Miniforge\Scripts;C:\Miniforge\bin;C:\Miniforge\condabin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\Users\XXXXXX\AppData\Local\Microsoft\WindowsApps; As an additional step, I also prepended "C:\Miniforge" to the system PATH variable, so that the "correct" MSVCP140.DLL would be sure to be picked up during any scan of the path. But that didn't work either unfortunately. Re your other thoughts - I agree with you that the issue is likely something to do with the list in the link you posted. Happy to try other things to do with that list if someone can explain what to do. Only a few of the options make sense to me. The mystery for me is that all Miniforge releases up to and including 24.3.0-0 work fine, on exactly the same system / McAfee version, policies etc. So what was the installer (or Python.exe) doing correctly in 24.3.0-0, and later releases not so? I haven't come across any previous situation in many years of supporting Windows applications, where McAfee needed to be uninstalled in order to resolve an apparent DLL naming clash with another application. Thanks all for your comments, very helpful |
|
Are you in a position where you can try to uninstall McAcfee to help troubleshoot? |
|
Yes, but to get rid of all McAfee components completely, the easiest route will be to rebuild my test machine after putting in an exclusion for McAfee from deploying in the first place. I'll give it a go... (and hoping there isn't some other policy somewhere putting it back on) |
|
Fwiw, I'm having the exact same issue, but I'm not using conda or miniforge or fmt. What's causing this on my end is using mysql-connector-python > 9.0.0. I'm not desperately dependent on v9.2 of the connector and with 9.0.0 it doesn't crash, most likely because that was built with the old VC version which that old MSVCP140.DLL in Trellix is from, but I'd still like to find a way for python to use the actual VC redist package components and not some outdated ones shipped with the AV. Any suggestions welcome. |
|
@hmaarrfk I've built a machine without McAfee on it, installed Miniforge 24.11.3-2 and repeated my previous tests. Spyder works perfectly now, with the DLL being picked up from the correct location of C:\Miniforge\MSVCP140.dll. @Harrier-Du-Bois Your problem is interesting, as it suggests the problem could be deeper within Python. I have just tried Python 3.13.2 from python.org. Although Spyder doesn't crash (as it did with Miniforge), DLL explorer shows that this is still loading MSVCP140.DLL from the McAfee installation directory, rather than the correct one within its installation tree. I will be trying older versions of CPython to see if there is any correlation with Miniforge in terms of which versions work correctly, and which versions don't, on systems with McAfee installed. Thanks all! |
|
Dear all, Thanks for your comments so far. After some further investigations, we have established that the problem is caused by McAfee Threat Prevention interfering with python.exe. Specifically, it is the "Antimalware Scan Interface" - details at Switching this off makes the problem go away. Although this setting can be disabled using a central McAfee policy, one issue we have is that it can probably only enabled or disabled on a whole-machine basis. There may not be away of restricting this setting to the C:\Miniforge tree or the python.exe executable. I am having a conversation with our enterprise sysadmins. Separately, on systems with the McAfee policy enabled, I can initiate a program crash with fewer steps than I've outlined in previous posts. All I need to do get python.exe to crash is the following:
Then:
The crash only occurs if vc14_runtime is greater than 14.38 (or conversely, pinning vc14_runtime at 14.38 will |
Solution to issue cannot be found in the documentation.
Issue
I am testing version 24.11.3-1 under Windows 10, but the bug seems to be present at least since 24.5.0-0 and releases in between.
"C:\Miniforge\python.exe" should have a dependency on C:\Miniforge\msvcp140.dll. However I believe that python.exe has been packaged or built incorrectly, as sometimes other DLLs of the same name are loaded up in preference to the correct DLL.
For some reason, python.exe seems to load functions from C:\Program Files\McAfee\Endpoint Security\Threat Prevention\MSVCP140.dll instead of C:\Miniforge\msvcp140.dll.
For example if I install spyder (along with various other common addons):
mamba install pyarrow python-dateutil pandas numpy scipy ipython -y
mamba install matplotlib jupyterlab notebook spyder ipympl ipywidgets -y
Faulting application name: python.exe, version: 3.12.9150.1013, time stamp: 0x67c7812e
Faulting module name: MSVCP140.dll, version: 14.0.24210.0, time stamp: 0x575a4ceb
Exception code: 0xc0000005
Fault offset: 0x0000000000018c34
Faulting process ID: 0x13ac
Faulting application start time: 0x01db9333d5d31b07
Faulting application path: C:\Miniforge\python.exe
Faulting module path: C:\Program Files\McAfee\Endpoint Security\Threat Prevention\MSVCP140.dll
Report ID: 52b62df9-cd54-4d47-8ba5-f383b6769b92
Faulting package full name:
Faulting package-relative application ID:
https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-redirection
namely
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options" /v DevOverrideEnable /t REG_DWORD /d 1
Reboot the machine.
Create a zero-byte "redirection file":
copy /y nul C:\Miniforge\python.exe.local
but I would prefer not to use this as a permanent change on users' systems, as there could be unforeseen side-effects with other installed software.
I can obviously uninstall the McAfee products on my test system, and Spyder then works, but this is not an option for other machines in our organisation.
Installed packages
Environment info
The text was updated successfully, but these errors were encountered: