[python-win32] wmi.py + pythonservice.exe

[c***@viawest.net]

background:

using - win2k, python2.3.3, pywin32 201.1, wmi 0.5 (from Tim Golden)

Typically, I use python in a *nix envoronment, but in this case I'm of
course working on a windows machine and slightly out of my element. I've
successfully implemented some pieces of code using Tim Golden's wmi module
and they work well. I've also implemented some very basic service code
and successfully registered pythonservice.exe, installed the service, and
stopped and started it. (all using win32 items and examples)

When I take working service code, add an "import wmi" statement, and
update the service, I then suddenly get failures when trying to start the
service. The event log holds almost no information. I simply get this:

A system error has occured.
System error 1067 has occured.
The process terminated unexpectedly.

Interestingly, when I use pythonservice.exe to run the service in debug
mode it runs well.

question:
Has anyone else successfully used the wmi.py and pythonservice.exe
combination, or have any leads I might research?

Thanks!

cody

[Wolf Logan]

system error 1067 is, as it says, unexpected process termination. as you're
aware, services are not supposed to exit unless they've been sent the "stop"
signal, so any exit from your code while starting or running will log this
error.

I'm going to guess that the python script is exiting with an exception for
some reason. you could try wrapping the code in an exception handler, and
then logging the exception somewhere before exiting.

it's possible that the WMI stuff needs some resource privileges that the
service environment isn't providing. the default setting for services is
very restricted, for security. if your service is set to log on as the
"local system", try setting the "interact with desktop" flag, which allows
some extra privileges. otherwise, try running the service to log on as a
regular user, preferably one which can successfully run the code from the
desktop (for example, your own account).

----- Original Message -----
From: <***@viawest.net>
Sent: Thursday, May 06, 2004 5:20 PM

Post by c***@viawest.net
When I take working service code, add an "import wmi" statement, and
update the service, I then suddenly get failures when trying to start the
A system error has occured.
System error 1067 has occured.
The process terminated unexpectedly.
Interestingly, when I use pythonservice.exe to run the service in debug
mode it runs well.
Has anyone else successfully used the wmi.py and pythonservice.exe
combination, or have any leads I might research?

[Mark Hammond]

Post by Wolf Logan
system error 1067 is, as it says, unexpected process
termination. as you're
aware, services are not supposed to exit unless they've been
sent the "stop"
signal, so any exit from your code while starting or running
will log this
error.

Theoretically, this should not be able to happen for Python services.
Unhandled exceptions should still terminate "gracefully", logging the error
and notifying the SCM that it finished.

A fatal Python error could cause this though, and the most common cause of
this is a thread-state mixup - but then I would expect the same code to fail
regardless of the context it was being executed in.

All my ideas to diagnose this require MSVC.

Mark

[Tim Golden]

Post by c***@viawest.net
using - win2k, python2.3.3, pywin32 201.1, wmi 0.5 (from Tim Golden)
I've successfully implemented some pieces of code using Tim
Golden's wmi module and they work well.

Glad to hear it!

Post by c***@viawest.net
When I take working service code, add an "import wmi" statement, and
update the service, I then suddenly get failures when trying
to start the service. The event log holds almost no information.

No magic bullet here, I'm afraid. I've not tried this myself, tho'
if I have time this morning I'll give it a go.
You're up against at least two things:

+ Security issues around services, which -- by default -- run
as the most basic user possible, without network access (I
think).

+ The WMI security model is a real pain to manipulate, not
least because you have to contend with its own security,
general COM / DCOM security, and even more general NT
Security, all of which are interlinked, but subtly different
(or at least that's the impression I have from no small
amount of research).

And, of course, it may be that even sorting this out won't
solve your problem!

I suggest that you run the service under the same user which
you're logged in as. In case you haven't done this before, it
means going to Control Panel -> Admin Tools -> Services
(or however you normally get there), right-clicking for
Properties, selecting the LogOn tab, and specifying an
exact account. Then try starting the service again.

As you can see from the top of the WMI file, the only thing
the module does on import (apart from defining a few constants
and, obviously, the classes and functions) is to call
win32com.client.gencache.EnsureDispatch. This is to ensure
that various constants etc are readily available. There aren't
many, (in fact, three), so you might try adding these lines
somewhere towards the top of the module at line 129:

wbemErrInvalidQuery = -2147217385
wbemErrTimedout = -2147209215

to replace lines 129-131:

#obj = win32com.client.GetObject ("winmgmts:")
#win32com.client.gencache.EnsureDispatch (obj._oleobj_)
#del obj

You could then replace "win32com.client.constants." with ""
throughout (there are only three instances) and see if that
helps.

(In case it wasn't obvious, all I'm doing there is to remove
the need to do any win32com stuff on module import, in case
that's a problem.)

Let us know if that helps or hinders.

TJG


________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. 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
________________________________________________________________________

[c***@viawest.net]

Thank you all for the quick input and insights. Tim, I'll give your
suggestions a shot for routing around the com imports issue when I have a
chance.

In the mean time, I found an interesting work around. If I rename wmi.py
to anything else and then reference it accordingly, the problem
dissapears. (ex. pywmi.py, import pywmi) Due to deadlines, I'll probably
have to come back and learn why this is the case later, but I'm sure it
will provide some good insight and a learning experience regarding python
internal workings.

cody

Post by Tim Golden

Post by c***@viawest.net
using - win2k, python2.3.3, pywin32 201.1, wmi 0.5 (from Tim Golden)
I've successfully implemented some pieces of code using Tim
Golden's wmi module and they work well.

Glad to hear it!

Post by c***@viawest.net
When I take working service code, add an "import wmi" statement, and
update the service, I then suddenly get failures when trying
to start the service. The event log holds almost no information.

--snip--

[Tim Golden]

Post by c***@viawest.net
Thank you all for the quick input and insights. Tim, I'll give your
suggestions a shot for routing around the com imports issue
when I have a
chance.
In the mean time, I found an interesting work around. If I
rename wmi.py
to anything else and then reference it accordingly, the problem
dissapears. (ex. pywmi.py, import pywmi) Due to deadlines,
I'll probably
have to come back and learn why this is the case later, but
I'm sure it
will provide some good insight and a learning experience
regarding python
internal workings.
cody

Wow. Don't pretend to understand that one bit, but thanks
for the information.

I did try to put an "import wmi" into
my usual test service earlier, but ran into annoying problems
before ever getting the "import wmi" into the script and
ran out of time, so inconclusive. Should really try again so
I can advise when other people try.

TJG


________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. 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
________________________________________________________________________

[Mark Hammond]

Post by c***@viawest.net
In the mean time, I found an interesting work around. If I
rename wmi.py
to anything else and then reference it accordingly, the problem
dissapears. (ex. pywmi.py, import pywmi) Due to deadlines,
I'll probably
have to come back and learn why this is the case later, but
I'm sure it
will provide some good insight and a learning experience
regarding python
internal workings.

It is possible that a "wmi.dll" is being found first on sys.path, and is
what is getting loaded. It may also be that the sys.path{} was setup this
way only when running under the service context (eg, due to the user, etc)

I'm still love to know how it caused a silent fatal error - unless the
"wmi.dll/.pyd" found was indeed an old Python extension module built for a
different Python version. (If it was just a "regular" windows DLL, it
should cause an ImportError, which should not be silent.)

Mark.

[Tim Golden]

Well, as Mark Hammond suggested in another post
(which I can't now find to respond to), there is
in my Win2K installation a [wmi.dll] stashed
away in [c:\winnt\system32]. If you cd to that
directory, start a Python session on try doing
"import wmi" it crashes mightily. Don't know
why.

Presumably services run in the context of that
directory, so running the script from elsewhere
won't manifest the problem while as soon as it
becomes a service -- BANG!

Looks like I might want to consider calling the
module pywmi or something instead, if only to
avoid this problem.

TJG


________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. 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
________________________________________________________________________

[Thomas Heller]

Post by Tim Golden
Well, as Mark Hammond suggested in another post
(which I can't now find to respond to), there is
in my Win2K installation a [wmi.dll] stashed
away in [c:\winnt\system32]. If you cd to that
directory, start a Python session on try doing
"import wmi" it crashes mightily. Don't know
why.

It crashes when trying to access the import table of the wmi.dll.
File Python/dynload_win.c, line 125, in the GetPythonImport function.

On WinXP Pro, it seems wmi.dll doesn't contain an import table.
Or something like that.

Thomas

[Mark Hammond]

Post by Thomas Heller
It crashes when trying to access the import table of the wmi.dll.
File Python/dynload_win.c, line 125, in the GetPythonImport function.
On WinXP Pro, it seems wmi.dll doesn't contain an import table.
Or something like that.

It's like a tag-team match :)

www.python.org/sf/951851

Thomas - a quick review of the patch, if you don't mind, and I'll check it
in before 2.3.4 goes out!

Thanks,

Mark