Problem listing services with wmi

[Tim Golden]

[Jean-Sébastien Guay]

| Hi again Tim,

Nice to hear back from you.

| Any reason I should know about that you haven't updated to 
| 2.4? I just got into Python, so I got the latest version, but if there's 
| something wrong with 2.4 I'd like to know...

No; there's no problem as such. At home, I'm running 2.4. 
It's just that for every version you run, you need versions
of any extension modules to be recompiled (or precompiled)
for that version. This only applies to extensions written in
C (not to normal .py modules). Since none of the language
features or bugfixes in 2.4 give me a pressing need to upgrade
for any of my business apps, I've taken the line of least risk.
(Also, Object Craft's MSSQL module which I've used consistently
for the last three years or so isn't available under 2.4, and
I don't have the necessary infrastructure to compile it).

| >It would be interesting
| >to know what it is about one or more services which gives WMI a
| >problem
| >  
| >
| 
| Which is what really puzzles me... From the list of 21 services that 
| were gotten by win32service and not wmi, I can't see any 
| service that's "special" in any way... 
| So without further investigation, I really couldn't say.

Oh, well. I was hoping one would have strange Unicodesque
characters in the service name or something equally glaring.
Is it possible there's simply an upper limit (ie it will
only list 87 services or whatever)? Doesn't seem likely,
but in this case nothing seems likely.

| >I think that all we're likely to achieve is, as I say, a more
| >robust solution; we're unlikely to get the missing service
| >if the core WMI can't see it for some reason. 
| >
| 
| But if we can get WMI to just "skip over" the offending service, at 
| least then we'll be able to know which one causes this...
| 
| >n_services = services.Count
| >
| 
| It now fails at the line above, with the following error :
| 
| Traceback (most recent call last):
|   File "<stdin>", line 1, in ?
|   File "G:\Python-2.4\Lib\site-packages\win32com\client\__init__.py", 
| line 455, in __getattr__
|     return self._ApplyTypes_(*args)
|   File "G:\Python-2.4\Lib\site-packages\win32com\client\__init__.py", 
| line 446, in _ApplyTypes_
|     return self._get_good_object_(
| pywintypes.com_error: (-2147352567, 'Exception occurred.', (0, 
| 'SWbemObjectSet',  'Critical error ', None, 0, -2147217398), None)

Well now, that's strange. Although probably not that strange,
as the .Count property may just internally enumerate all its
items, which would trigger the same problem.

| I had tried something similar yesterday, with the same 
| results. It would 
| seem (from what I can understand) that c.ExecQuery() just 
| makes a list of proxy objects, and that when you call Count on the set, it has to 
| create them all for real and that's where it fails when reaching the 
| "bad" service.

Ah, I see you had the same idea.

| 
| Thanks again, looking forward to trying other ideas.

I'm afraid I'm pretty much out of ideas. As no-one else
on this list is chiming in (and believe me, they would
if they had anything to add) I suspect that no-one else
is any the wiser. Since the problem seems to be within
WMI there's only so far I can go.

Just had an idea: look at the WMI group on Google:
http://groups-beta.google.com/group/microsoft.public.win32.programmer.wmi

There are several posts there talking about services
actually crashing when enumerated, and suggestions from
the MS people include checking the event log for more
info about the service, with the explanation that poorly
written service control code reacts badly to a  
SERVICE_CONTROL_INTERROGATE message. Might be worth
looking through in case it sheds any light.

Apart from that, unless someone comes up with a startling 
new direction, I'm afraid you're going to have to go with
the win32service solution. Please don't give up on WMI
though: it's a very useful general-purpose solution
to lots of information under Windows. Some things it does
better than others, but it's easy enough to try something
out to see if it works, and if it doesn't...

By the way, if you're doing win32 programming using Python
and you haven't already come across it, you will definitely
need Thomas Heller's ctypes at some point:
http://starship.python.net/crew/theller/ctypes/
It lets you get at C-level structures directly from Python.
If you had enough patience, you could reimplement the
WMI model using ctypes, but I suspect you'd hit exactly the
same error, only after considerably more effort!

Best of luck with Python, and let me know if any breakthrough
occurs.

TJG

________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________