[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 ________________________________________________________________________ -- http://mail.python.org/mailman/listinfo/python-list
