[python-win32] WMI troubles!

[Alex Hall]

I am trying to put the stack trace into a file, since I cannot copy and 
paste from the cmd line output. Is there a way to do this? Also, if you run 
the file (assuming you have all the dependencies) the error happens as soon 
as you press windows-`. You can change "speaker.say" to "print" and comment 
out the line creating the speaker object so that you do not have to install 
sayTools.


Have a great day,
Alex
Email: mehgcap at gmail.com
----- Original Message ----- 
From: "Tim Golden" <mail at timgolden.me.uk>
Cc: <python-win32 at python.org>
Sent: Friday, January 15, 2010 4:00
Subject: Re: [python-win32] WMI troubles!


> On 15/01/2010 05:05, Alex Hall wrote:
>> Hello all,
>> I just joined this list. I am pretty new to Python, but I really like and
>> hope to get more into it;
>
> Welcome to the list. And to Python.
>
>> Anyway, onto the problem. I am working on a simple resource monitor (I 
>> have
>> never found one that works well with screen readers, so I am writing 
>> one). I
>> am using python2.6 with all the win32 libs installed. My monitor will use
>> wmi to get all of its information, and it was going pretty well until a 
>> few
>> hours ago, when I started receiving seemingly random errors.
>
> What would definitely help, and this is general advice for posting
> to technical groups, is the exact error you received -- the traceback
> which looks something like this:
>
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "c:\work_in_progress\wmi\trunk\wmi.py", line 1124, in __getattr__
>     return getattr (self._namespace, attribute)
>   File "c:\python26\lib\site-packages\win32com\client\dynamic.py", line 
> 512, in __getattr__
>     raise AttributeError("%s.%s" % (self._username_, attr))
> AttributeError: winmgmts:.Win32_Processx
>>>>
>
> In addition -- and I appreciate that this isn't always easy -- is
> the smallest self-contained code example which will fail every time.
> Apart from making it easier for people to help you out, it sometimes
> makes the source of the error clearer even to you, the developer.
>
> I don't have time now, but I will get to this later on today. The
> likeliest cause is that PyHook is introducing a threading context
> which is causing problems with the COM-based WMI stuff. Your early
> CoInitialize is a nod in the right direction, but unfortunately
> redundant where you've put it at the top of the main thread.
>
> But sight of the traceback should help clarify things considerably.
>
> TJG
> _______________________________________________
> python-win32 mailing list
> python-win32 at python.org
> http://mail.python.org/mailman/listinfo/python-win32