This code used to work on Vista (and Windows XP) but after an upgrade to Windows 7 it now fails with the error shown:
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on win32
>>> import _winreg
>>> h1 = _winreg.ConnectRegistry(None, _winreg.HKEY_LOCAL_MACHINE)
>>> key = r'SOFTWARE\Python\PythonCore\2.6\InstallPath'
>>> h2 = _winreg.OpenKey(h1, key, 0, _winreg.KEY_ALL_ACCESS)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
WindowsError: [Error 5] Access is denied
I'm fairly sure this is the result of changes in the security model in Windows 7, but various searches I tried have turned up nothing I can use as an answer so far.
(Not that it should be relevant, but to stave off "why would you do that?" responses, this is for a developer's utility which can switch the registry between multiple installations of Python, for use in a multi-project environment where we need more control over which version of Python is in use, and what packages are available, than things like virtualenv can provide.)
Edit: The logged-in user is an Administrator. Also, I've turned off the UAC (User Access Control) stuff as completely as one can (not true... see next edit), as was previously the case before the upgrade from Vista to Windows 7.
Edit 2: As noted in my own answer below, I hadn't rebooted after turning off UAC, so it was still set to the default. Apparently this results in the Access denied error (as I confirmed by testing with UAC set to Default and to Never).
This was a user mistake, compounded or triggered by changes in Windows 7 to how the UAC feature is implemented.
In Vista, the much-detested User Access Control feature was binary, either on or off. On Windows 7 that has been changed to provide four levels of granularity:
Always Notify (when either programs or user tries to change settings)
Default (notify only when programs try to make changes, and dim screen)
Notify without dimming (same as default but don't dim screen when notifying)
Never notify (for either programs or user changes)
My mistake was in not rebooting after dropping the UAC feature down to the Never Notify level. (Vista was aggressive about requesting that you reboot, while Windows 7 seems to be slightly more passive.)
I think you have an access right problem.
Try to open the key with a less demanding access right (e.g. KEY_QUERY_VALUE) and check if it works.
Of course, with that change you will not be able to change the registry, but it would be only for pinpointing the issue.
As an alternative, try to execute the utility from a user with higher privileges - and by the way this would be the only solution I could see for a problem involving access rights.
Related
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
I've been running around in circles for a few weeks, and can't get past an infuriating problem... firstly; I'm running 64-bit Win10, with 64-bit Powershell invoking python 3.9 (also 64-bit), which is an app with a Tk GUI, and uses python-vlc. It's been running fine for weeks on a laptop, and I'm now trying to get it work on a PC with the same setup (Win10, 64-bit VLC, 64-bit Python).
The error can be reproduced in a few simple lines right in the Python shell:
PS C:\Users\Vexen\OneDrive> python
Python 3.9.2 (tags/v3.9.2:1a79785, Feb 19 2021, 13:44:55) [MSC v.1928 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import vlc
>>> p = vlc.MediaPlayer("C\:\\Users\\Vexen\\OneDrive\\test.mp3")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Users\Vexen\AppData\Local\Programs\Python\Python39\lib\site-packages\vlc.py", line 3327, in __new__
o = instance.media_player_new()
AttributeError: 'NoneType' object has no attribute 'media_player_new'
>>>
Or, using a slightly different method with an explicit .Instance():
>>> import vlc
>>> i=vlc.Instance()
>>> p=i.MediaPlayer()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'NoneType' object has no attribute 'MediaPlayer'
And to test what i comes out as on the machine where it doesn't work:
>>> type(i)
<class 'NoneType'>
On the laptop where it works, it says <class 'vlc.Instance'>.
Here's things I've looked at and tried (more detail on each, below):
The correct code required to instantiate a Media Player
Using vlc.Instance('--verbose 3')
vlc.py inbuilt GUI/demo causes the same error
Checking that VLC can open .mp3 files
Reinstalls and 64-bit checks
VLC DLLs locations and the %PATH% environment variable
Checking vlc.py
vlc.py internal issue: Instance.new() call to _CFunctions returns None
(1) Code to create the player
The docs say that .MediaPlayer automatically creates the Instance if it's not done manually. Also this is stated here: AttributeError: 'NoneType' object has no attribute 'media_player_new' and .
No matter which way I do it (direct in Python, or held open in a gui by setting frmMain.vlc to vlc.MediaPlayer(), I get the same results, so I'm only showcasing the simpler method here.
(2) i = vlc.Instance('--verbose 3')
Python VLC Script error: AttributeError: 'NoneType' object has no attribute 'media_player_new' says about using i = vlc.Instance('--verbose 3') to see possible error messages: Mine outputs "C:\Windows\system32" and no errors.
On the laptop where it works fine, it outputs a screenfull of technical details.
(3) vlc.py inbuilt GUI/demo causes the same error
When looking in vlc.py I see that it's got an inbuilt simple GUI. When I run it, the file itself outputs the same error:
PS C:\Users\Vexen\OneDrive> python C:\Users\Vexen\AppData\Local\Programs\Python\Python39\Lib\site-packages\vlc.py C:\Users\Vexen\OneDrive\test.mp3
AttributeError: 'NoneType' object has no attribute 'media_new' (C:\Users\Vexen\AppData\Local\Programs\Python\Python39\Lib\site-packages\vlc.py 3.0.11115 vs LibVLC b'3.0.12 Vetinari')
This makes me think that it's something inherent to the VLC install or backend DLLs.
(4) Checking that VLC can open .mp3 files
The following makes VLC full app open and play the file correctly:
PS C:\Users\Vexen\OneDrive> C:\Users\Vexen\OneDrive\test.mp3
Also, intentionally providing a wrong filepath to .MediaPlayer() produces the same error, therefore, it's hitting the NoneType error before it gets as far as parsing the filepath parameter.
(5) Reinstalls and 64-bit checks
Many similar questions focus on mismatches between 32-bit and 64-bit installs. E.g. PyInstaller with Python-VLC: No Attribute "media_player_new" Error and https://superuser.com/questions/1281731/how-to-install-64-bit-vlc-library-for-64-bit-python-3-on-windows . I've uninstalled VLC and Python, rebooted, reinstalled, rebooted, and double-checked I've got 64-bit versions of it all installed.
I uninstalled it from both machines, and using advanced install options, done a custom install on both using the exact same settings (not including Python docs, include Tcl, include Python launcher, install for all users).
Checking Python is 64-bit on both machines:
>>> import platform
>>> platform.architecture()[0]
'64bit'
Getting a fresh vlc.py file:
pip3 install python-vlc --force-reinstall
Checking vlc version, on both machines the details match precisely:
PS C:\Users\Vexen\OneDrive> python -m vlc -v
vlc.py: 3.0.11115 (Sat Jul 25 15:07:40 2020 3.0.11)
LibVLC version: 3.0.12 Vetinari (0x3000c00)
LibVLC compiler: gcc version 6.4.0 (GCC)
Plugin path: C:\WINDOWS\system32
Python: 3.9.2 (64bit) Windows 10
And when running the VLC full app, the 'About' screen also states "3.0.12 Vetinari", on both machines.
32-bit and 64-bit mismatchines have different errors (File Not Found, %1 not compatible, etc) to the ones I've got, so, that's not the problem.
Other general install issues questions, e.g., Python vlc install problems and Attribute error when importing VLC module in python , cover some of the same things I've already done.
(6) VLC DLLs locations and the %PATH% environment variable
Python vlc install problems and some other issues have to do with %PATH% and Python not knowing where to look for vlc DLLs, however, that's not the problem in my case.
Microsoft says that Sytem32 is a default location where Windows will search for DLLs: https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order .
I've stepped through vlc.py, and in "find_lib()", I can see it picks up the correct location of libvlc.dll in /system32/. I deleted the 2x DLL files (the other is libvlccore.dll) and replaced them with newer copies from the newer install of VLC. Made no difference, but, it means that I don't need to worry about the %PATH% environment variable, because it finds the DLLs easily and automatically in /system32/.
Also, the dll version above listed by python -m vlc -v correctly found it in /system32/.
(7) Checking vlc.py
I've copied the file from the laptop (where Python can invoke VLC and play .mp3 files fine), to the desktop (where it causes an error), but with the same results. The file version looks exactly the same.
Verifying that I know exactly which vly.py is being used is used; it's in the Stacktrace of the error, and:
>>> vlc.__file__
returns the expected filepath on both machines. Copying it to the local dir doesn't change anything (except the occur occurs in the file in the new location, as you'd expect).
I also downloaded the very latest version of vlc.py from https://git.videolan.org/?p=vlc/bindings/python.git;a=blob;f=generated/3.0/vlc.py;h=fdb603002425e082b1d6b8ac08ab8322248d3ac7;hb=HEAD .
This file produces the same error on the same line of code (albeit a few line numbers different):
File "C:\Users\Vexen\OneDrive\Music\Pyggy\vlc.py", line 3200, in __new__
o = instance.media_player_new()
AttributeError: 'NoneType' object has no attribute 'media_player_new'
(8) vlc.py internal issue: Instance.new() call to _CFunctions returns None
It runs find_lib() which correctly sets dll location to system32. The Instance class is initialized (I guess) by Instance.new() , which calls libvlc_new() which returns [b'vlc'], which seems good (it's not None). But it then passes this to _Cfunctions (via f()), which returns None. This is returned as the Instance() instance, and is the source of the problem.
I added some print() statements to vlc.py (when testing, I tend to put the "Line xxxx" in the print statement, to help me remove the prints() later!):
On the PC where it doesn't work:
Line 4685, lib_vlc_new() is sending the following to f(): 1 [b'vlc']
Line 4688 will return the results of f(argc, argv): None
Line 1883, Instance.__new__() is returning the following: None
On the laptop where it does work:
Line 4685, lib_vlc_new() is sending the following to f(): 1 [b'vlc']
Line 4688 will return the results of f(argc, argv): <vlc.Instance object at 0x000001DCD37BA370>
Line 1883, Instance.__new__() is returning the following: <vlc.Instance object at 0x000001DCD37BA400>
f is the subfunction that calls _Cfunctions.
Whilst talking with the developer community over here, the issue fixed itself. https://github.com/oaubert/python-vlc/issues/170
Our closing comments included our best guess: A Windows internal cache somewhere. I deleted the DLLs from system32 in preparation for doing yet another reinstall. I tested the program, and it picked up the DLL from "C:\Program Files\VideoLAN\VLC\libvlc.dll" rather than the /system32/ directory. I strongly suspect that within Windows somewhere, the .dll was cached by something like the preload process or some other obscure bit of Windows. There's no user-facing way to clear some of Windows internal caches. The cache became invalid at some point (3 weeks seems an arbitrary (and rather long) cache period, but Windows is infamously opaque). After that, it genuinely loaded a new version from a new install. Perhaps until then, all my attempts were failing due to a preload cache. That's only a guess.
Correct answer: Just keep trying, even after uninstalling previous versions, manually remove the libvlc.dll and libvclcore.dll , keep restarting, keep checking version numbers. Eventually. it'll start working.
One solution is to manually set the dll path. Add the following line to your code before you import vlc:
os.environ.setdefault('PYTHON_VLC_LIB_PATH', 'your/path/to/libvlc.dll').
If we go directly to the source, this line is one of the first to run, and it's checking for the environment variable above. You could put the dll's wherever you want. You don't even need to install vlc player.
Updated with information I forgot to include:
Canopy Version: 1.7.4.3348 (64 bit)
Python version: '2.7.11 | 64-bit | (default, Jun 11 2016, 11:33:47) [MSC v.1500 64 bit (AMD64)]'
Also: This problem only started a few days ago, but it's pretty irritating. It could be the network guys are doing something, or it could be I've altered my environment somehow without realizing it.
I have the habitual problem in Canopy that for some reason the prompt in the immediate window acts weird. It lets me type, but doesn't do anything and doesn't seem to advance to the next command.
Welcome to Canopy's interactive data-analysis environment!'t' not in 'tf'
Type '?' for more information.
...:
...:
n [1]: %run "C:\Projects\MyProject\MyProgram.py"
Enter (T)est or (F)ull or (Q)uit: t
How many rows to process: d
't' not in 'tf'
Out[2]: False
'a' not in 'tf'
Out[3]: True
In [4]:
...:
...:
...:
The only way I can get past this is to restart the kernel. I think something in my program might be causing this. Not sure what. Don't want to put the whole thing here. Anyone had this problem and know what kind of thing might cause it?
Also, what is this "mode" called and is there a way to get back to a regular "mode" without restarting the kernel?
Your firewall might be blocking ipython's communication with its kernel. Try disconnecting from the internet, disabling your firewall, and trying again. If this solves the problem then you'll need to configure your firewall not to block localhost, or use a smarter firewall program.
I am working on Windows 10 presently and need to put some code if the platform is Windows 10. So, I checked in python docs and read about platform module. This is what the documentation says :
platform.win32_ver(release='', version='', csd='', ptype=''):
Get additional version information from the Windows Registry and return a tuple (release, version, csd, ptype) referring to OS release, version number, CSD level (service pack) and OS type (multi/single processor)
When I tried the same function on my Windows 10 machine I got below :
>>> platform.win32_ver(）
('8', '6.2.9200', '', u'Multiprocessor Free')
But, I was expecting the release to be 10 instead of 8.
So, any idea if I am missing something here ?
Also, can somebody please tell me if there exists any other way to detect if the windows platform is Windows 10 ?
The problem is python uses GetVersionEx to determine the version.
As you can read here, Microsoft doesn't support this anymore and offers a different API.
However, you can always call the new API yourself, or check the registry value at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion.
You can also use WMI to get the Win32_OperatingSystem instance.
I'd also like to note that specific version checking is generally considered a bad practice.
I am working on a "chat-like" server using Twisted in Python. However I am having issues. On the main admin account of my Mac, Twisted works fine. But when I go onto a separate admin account, I get thrown...
Traceback (most recent call last):
File "/Users/Alec/Desktop/server.py", line 1, in <module>
from twisted.internet.protocol import Protocol, Factory
ImportError: No module named twisted.internet.protocol
It works fine on the other account, but this new admin account doesn't work. I am working hard to get my project going, but this has me at a halt.
Thanks!
I can only guess at what's wrong with your setup, since you haven't provided much information. However, the cause must be something to do with the way you're invoking python, since the default python on OS X has Twisted installed (as you may have noticed).
Does your administrative user have a self-compiled Python?
Is your administrative user using virtualenv, or any other environment-management tool that would remove site-packages?
Did your administrative user install Python from python.org? (This is not completely compatible with the built-in system Python and will have different packages available.)
If type -p python in a shell doesn't print /usr/bin/python, then one of these is likely the case, but fixing it (in other words, un-doing whatever has been done) depends on which of these options has altered your default Python.
You might want to check if sys.path (the module search path) is the same for both users.
>>> import sys
>>> sys.path
There may be a user specific PYTHONPATH environment variable which alters the behavior for one of the two users, although I'm not sure it could actually break the import.