Python library - WMI.py RegistryValueChangeEvent
mail at timgolden.me.uk
Tue Apr 7 16:52:43 CEST 2015
On 07/04/2015 15:35, Khyati wrote:
> On Tuesday, April 7, 2015 at 10:31:47 AM UTC-4, Chris Angelico wrote:
>> On Wed, Apr 8, 2015 at 12:15 AM, Khyati wrote:
>>> Thanks for taking a look, Chris.
>>> The error trace:
>>> traceback (most recent call last):
>>> File "MonitorRegistry.py", line 18, in <module>
>>> process_created = watcher()
>>> File "C:\Python27\lib\site-packages\wmi.py", line 1195, in __call__
>>> handle_com_error ()
>>> File "C:\Python27\lib\site-packages\wmi.py", line 241, in handle_com_error
>>> raise klass (com_error=err)
>>> _wmi: <x_wmi: Unexpected COM Error (-2147352567, 'Exception occurred.', (0, u'SWbemPropertySet', u'Not found ', None, 0, -2147217406), None)>
>> It looks to me like this is a thin wrapper around the underlying API
>> call, and you're getting back an error from the lower-level services.
>> The way this reads, there might well not be an
>> HKLM\Software\Temp\Name; maybe the ValueName is what's wrong here?
>> Someone somewhere knows more than I do, but if you can't find that
>> someone here on python-list, you might be able to find some help on
>> Stack Overflow or another mailing list, from people who know how to do
>> this kind of thing in a different language. You'd have to translate
>> their suggestions back into Python, but when the wrappers are thin
>> enough, that's usually not too hard.
> HKLM\Software\Temp\Name exists since the event is caught correctly only when I change that key.
> i'll keep looking :)
Unfortunately, extrinsic events don't come with much information. As you
can see from the MSDN description:
they're not linked to WMI objects internally (which the intrinsic events
are) so all they can do is echo back to you details of what changed --
which will usually be the thing you were asking about in the first place!
So the Python wrapper doesn't receive any TargetInstance because it's
not a *WMI* event as such, linked to a WMI object; rather, it's an
external event which has provided a hook for WMI to hang on to.
In this specific case, you could use the WMI Registry provider to pick
up the current value of that registry value, but that wouldn't tell you
what was there before or anything else. In another case, the event might
be about some entirely external system -- such as the
SecurityViolationEvent in the MSDN example -- which provides no WMI
interface beyond the event itself.
Feel free to ask more, either on this list or on the win32-specific
(I'm not often free to answer questions so best to use the public forums
where more people will be able to help).
More information about the Python-list