I'm trying to load pykd.pyd in order to be able to use Python during Windbg crash dump analysis. This does not work, as you can see here:
0:006> .load C:\Python27\Lib\site-packages\pykd.pyd
The call to LoadLibrary(C:\Python27\Lib\site-packages\pykd.pyd) failed,
Win32 error 0n126
"The specified module could not be found."
Please check your debugger configuration and/or network access.
For your information, I have started, opening Windbg (version x86) and opening a crash dump file, and I can confirm that the mentioned pykd.pyd file is present.
If I put the filename between double quotes, I get another error message, as you can see here:
0:006> .load "C:\Python27\Lib\site-packages\pykd.pyd"
The call to LoadLibrary(C:Python27Libsite-packagespykd.pyd) failed,
Win32 error 0n2
"The system cannot find the file specified."
Please check your debugger configuration and/or network access.
(It might be important to mention that both Win32 errors are different!)
Does anybody know what might cause this issue?
Thanks in advance
The Error Codes
The error message corresponds to the error codes. You can check that with the !error command:
0:000> !error 0n2
Error code: (Win32) 0x2 (2) - The system cannot find the file specified.
0:000> !error 0n126
Error code: (Win32) 0x7e (126) - The specified module could not be found.
So: nothing new here. WinDbg already told us.
The Quotation Marks
Since you are already debugging, let's debug this problem as well. Just know the right tool, which is Process Monitor.
Set up a filter like so:
"Process name", "contains", "windbg.exe", then "Include"
"Process name", "contains", "EngHost.exe", then "Include"
Now run the command
0:000> .load "c:\hello"
and you'll see that the quotes will mess up everything:
Now try
0:000> .load c:\hello
and you'll see that it searches in the right place:
Conclusion: .load is without quotation marks.
Loading PyKD
You are probably aware that there is 32 bit and 64 bit. And you can't load 32 bit DLLs in 64 bit processes nor 64 bit DLLs in 32 bit processes.
Same goes for debugging extensions: if you use 64 Bit WinDbg, you need 64 bit extensions. If you use 32 bit WinDbg, you need 32 bit extensions.
So first of all, check if your PyKD DLL (or .pyd here, which is actually .dll, just rename it) has the correct bitness (32 bit if I read that correctly).
Now, the 32 bit PyKD DLL will need a 32 bit installation of Python to run correctly. And likewise, 64 bit PyKD will need a 64 bit installation of Python.
Again you can help yourself with the right debugging tool. Process Monitor clearly shows that pykd.pyd is loaded successfully, but the dependency python38.dll (in my case, maybe Python 2.7 for you) is not:
For the following, I'm not 100% sure, but IMHO:
The PyKd DLL will try to find a Python system installation (as opposed to a virtual environment or venv).
That system installation must be in %PATH%
While you could have a 32 bit and 64 bit Python installation in the %PATH% variable, it will find one of them first. It might be the correct one or not.
Conclusion: put only one Python installation in %PATH% and use the correct bitness. Currently I only know this solution. Maybe the PyKD team posts an answer as well and explains how it can be done without modifying %PATH% all the time.
Don't load python package directly ( C:\Python27\Lib\site-packages\pykd.pyd ). It is a legacy unsupported way.
You need the special python bootstrapper for windbg:
https://githomelab.ru/pykd/pykd-ext
Related
I fixed a super-annoying case of "ImportError: DLL load failed while importing" in a way that generally applies to Windows, so let me share it with the group. Here is the question:
I installed FINUFFT via pip install finufft. When I import finufft, I get this error:
ImportError: DLL load failed while importing _finufft: The specified module could not be found.
How do I fix it?
Read to the end before doing anything.
The error means that a DLL cannot find another DLL that it was linked with. But which other DLL?
Download Dependencies.
Locate your problematic DLL. In this specific case: Locate the folder ...\Lib\site-packages\finufft\ of the FINUFFT installation that you want to fix. ...\ is the path of your standard python installation or of your python virtual environment.
Start DependenciesGui.exe and use it to open the problematic DLL, e.g. ...\finufft\_finufft.cp38-win_amd64.pyd. (A .pyd is a regular DLL with some specific entry points for python.)
On the left, you will see a complete list of the problematic DLL's direct dependencies, whose dependencies you can in turn unfold by mouse click. Apart from typical Windows-DLLs, like kernel32.dll and MSVCRT.dll, and apart from the FFTW-DLLs, which should already be in the FINUFFT-folder, there will also be some - possibly missing - Linux-DLLs. For me, it was libgcc_s_seh-1.dll, libgomp-1.dll and libstdc++-6.dll. By checking their direct dependencies, I also discovered libwinpthread-1.dll as missing.
[See EDIT below!!!] I found those DLLs in Anaconda (...\Anaconda3\Library\mingw-w64\bin\), but you can probably also get them from cygwin (...\cygwin64\bin\), git (...\Git\mingw64\bin\) or anything else that downloads mingw64 and its packages on Windows.
To solve the problem, copy the respective DLLs into ...\Lib\site-packages\finufft\ and give them the exact filenames that the FINUFFT-DLL is expecting according to Dependencies. This works because Windows and because of the Windows DLL search order.
Now, import finufft should work in the specific python environment whose FINUFFT installation you fixed. Clearly, this method can be applied anytime DLL dependencies are missing.
EDIT - correction of my answer by #CristiFati: If possible, DLLs and similar things should always be built with the same toolchain. So if you don't compile them yourself, get them from as few different places as possible, i.e. don't mix regular python, Anaconda, cygwin, etc. - if possible. Of course, Windows DLLs will have a different origin from Linux DLLs.
I'd like to use cjson in Maya 2018 but I'm running into some trouble. The original tool seems to be 32-bit compiled (https://pypi.org/project/python-cjson/) so I looked around and found a version that was compiled in 64-bit from https://www.lfd.uci.edu/~gohlke/pythonlibs/.
Using "C:\Program Files\Autodesk\Maya2018\Python\Scripts\pip.exe" in admin mode I managed to pip install the 64-bit wheel file and that's given me cjson.pyd in my Maya 2018 site-packages directory.
However, when I try to import this I get the error:
// Error: root : [('<maya console>', 2, '<module>', None)] //
// Error: root : DLL load failed: The specified module could not be found. //
// Error: //
Has anyone had any experience importing this module into Maya before?
I have a feeling this could be to do DLL dependencies but I'm not sure where to begin solving it.
So, traditionally you'd check your dll for dependencies using something like Dependency Walker. .pyd files are just renamed .dll files, so should work fine with this. However, Dependency Walker is mostly full of noise - unless you spot something really obvious (and you can ignore all the API-MS-WIN*, EXT-MS-* dlls straight away) then you might find it easier to enable Loader Snaps (see this old but still relevant MSDN article) which should hopefully be able to tell you which loadlibrary call is failing. Alternatively, you can use Process Monitor (procmon) form Sysinternals to see what files Maya attempts to load when you import the module in to a script. I can't remember if Maya spawns a separate process to run it's python scripts in, or if they're executed in the context of the main maya process. This is important as you'll want to filter events in procmon to just maya / the python executable as otherwise you'll be swamped by them.
Edit: Having looked through the source code there doesn't appear to be much in the way of dependencies beyond the python headers themselves and some standard library includes. I suspect it's more likely that this is compiled with a different version of the toolchain than Maya's Python. In the Python interpreter, you should see a line like this when you start it:
Python 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:25:58) [MSC v.1500 64 bit (AMD64)] on win32
It would be good to see what toolchain was used to compile it (the square brackets bit), and then build the extension from source again with that toolchain. Alternatively, you can try running the setup.py for this module from the project's GitHub page, which if your machine is set up to be able to compile python extensions correctly will build it from source. More details about building c extensions can be found on the Python docs page.
Pyahk documentation says:
A copy of the ANSI 32-bit dll must be provided either in the system location of your version of Windows, or in the same folder as the ahk.py file. (The required dll is not provided as part of this distribution, see the AutoHotKey.dll site for download instructions (alternate link AutoHotKey_H).)
Autohotkey.dll site does not provide any download instructions. The alternate link does not work.
I found some dlls here. Pyahk is not able to import the 32bit dll versions. I'm able to import ahk in python without the missing dll warning with the 64bit dll, but upon a call the library complains about some chinese characters.
Possibly I need to compile autohotkey.dll myself. If so I would prefer a method which does not require me to install a ton of compilation tools.
You can find the source code here: https://github.com/HotKeyIt/ahkdll
And the releases can be found here: https://github.com/HotKeyIt/ahkdll-v1-release
You'll find a couple of different versions (unicode, ansi, 64 bit, 32 bit ...).
I have been trying to install the module python-magic for a few hours, and I've been encountering some problems. I am using the 32-bit version of Python 3.5.2 with 64-bit Windows 7.
First, I used the command "pip install python-magic". I downloaded magic1.dll, regex2.dll, and zlib1.dll, and magic from the Files for Windows project, and I copied those four files to
C:\Program Files (x86)\Python35-32\Lib\site-packages\python_magic-0.4.12-py3.5.egg-info.
I added the aforementioned directory to the beginning of PATH in my Windows environment variables. Then I opened IDLE's Shell and typed "import magic" and got the response OSError: [WinError 126] The specified module could not be found.
I read that the "magic" file should have the extension .dll, so I renamed it. This led to the pop-up warning by Windows "C:\Program Files (x86)\Python35-32\Lib\site-packages\magic.dll is either not designed to run on Windows or contains an error" and by Python, "OSError: [WinError 193] %1 is not a valid Win32 application". I read that the latter error is commonly encountered while running it in a 64-bit environment, but I made sure to run it in 32-bit IDLE and only have the 32-bit version of Python installed.
Following the advice of previous StackOverflow posts, I tried copying cygmagic-1.dll, cygwin1.dll, and cygz.dll to C:\Windows\System32, to the same folder as magic.dll, and I also tried renaming cygmagic-1.dll as magic1.dll, but that didn't have any effect. I know other places say you're not supposed to mix Cygwin Python and Windows Python, but I tried it without the involvement of these files, and it didn't work then, either.
I tried renaming magic.dll to magic.exe, and that allowed "import magic" and magic.Magic(magic_file=r'C:\Program Files (x86)\Python35-32\Lib\site-packages\python_magic-0.4.12-py3.5.egg-info\magic.exe') with the response "<magic.Magic object at 0x02EA0A70>". When I tried testing with magic.from_file(r'C:\Program Files (x86)\Python35-32\Lib\site-packages\README.txt'), though, I got the error magic.MagicException: b'could not find any magic files! I figured that renaming it to magic.exe had to be wrong, but that it was worth a try.
After I gave up on python-magic, someone recommended an older project. I downloaded it and put the pymagic folder in my site-packages directory. When I tried to import pymagic.pymagic, it told me that the module StringIO doesn't exist, and the recommender told me it was because StringIO is from Python2. I changed all mentions of StringIO to io and tried the command pymagic.pymagic.identify_file(r'E:\Pictures\picture.jpg')
This generated the error TypeError: startswith first arg must be bytes or a tuple of bytes, not str. I'm not involved enough with Python's os, io, etc. modules to know how to make modifications to get this to work. Can anyone make any recommendations on how to get python-magic or pymagic working, or any other module for identifying a file based on its header? I know this question has been asked a lot, but the previous answers didn't work out for me.
Did you call the 'magic' data file magic, and leave it in the same folder as magic1.dll?
Following your instructions I was able to reproduce the same error as you. Using Sysinternals Process Monitor, I could see that the reason for your first error appeared to be that Python was trying to load the the magic data file as if it were the library.
I then renamed the magic data file to magic_data, restarted IDLE, and it worked. I could then use magic to identify a file:
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:43:06) [MSC v.1600 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import magic
>>> fn = r'C:\Python34\Lib\site-packages\python_magic-0.4.12-py3.4.egg-info\magic_data'
>>> m = magic.Magic(magic_file=fn)
>>> m.from_file(r'C:\Python34\Lib\site-packages\python_magic-0.4.12-py3.4.egg-info\zlib1.dll')
'PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit'
(I'm using a different version of Python (3.4), and a different version of Windows (10) to you, but I don't think these matter too much.)
I'm trying to compile a python project into an executable. To test this, I've got Py2Exe installed, and am trying to do their Hello.py test. Here is hello.py:
print "Hello World!"
Here is my setup.py:
from distutils.core import setup
import py2exe
setup(console=['hello.py'])
I do the following on the command line:
python setup.py py2exe
And I get it mostly working until it start 'finding dlls needed', at which point we get:
Traceback:
<some trace>
ImportError: DLL load failed: %1 is not a valid Win32 application.
Python version is 2.6.6, and I'm on a 32-bit machine running Windows 7. Any ideas or help most appreciated.
In my experience py2exe is rather difficult to use, a bit hit-and-miss in terms of whether it will work or not, and an absolute nightmare to get working at all with any matplotlib import.
I realise this question is quite old now, but I am not sure why people continue to use py2exe when there are much smoother functioning alternatives available. I have have good results with pyinstaller (which was recommended to me after asking a question here on SO where I was also battling with py2exe). Now every time I have tried it it "just worked", so if you're still interested in packing up python code into executables then try give this app a shot instead.
http://www.pyinstaller.org/
Note: py2exe hasn't been updated for some years, while python and 3rd party modules have, which must be partly why it often doesn't work particularly well these days.
Sounds like step 5 in this tutorial describes what you are experiencing:
http://www.py2exe.org/index.cgi/Tutorial#Step5
I had this same problem, this is what I was able to do Q-A. Basically, I downloaded the updated sqlite dll file from sqlite.org. I replaced the py2exe generated DLL file with this new file. The program worked after that. Do make sure you download the 32-bit DLL, however.