[python-win32] Handle to a Driver
me at chi-tai.info
Sun Apr 3 13:32:01 CEST 2005
i've found the faulty.
For those interested in: win32file.DeviceIoControl transfers a string or
character array, thus a numerical value like a handle is also transfered
as a character array and the cast operation within the driver does not
result in a valid handle.
> str(ReadEvent) would give you a string with something like
> '<PyHANDLE:768>'. It seems unlikely to me that this is your
> intention. Maybe str(int(ReadEvent)) - this would just send the
> handle value (as a string)
I have tried this, but then it's size is less than "sizeof(HANDLE)" and
even if i remove the size-check the Routine fails with an invalid
> > Driver code in Dispatch Routine for IOCTL: ntStatus =
> > ObReferenceObjectByHandle ( handleFromPython, EVENT_MODIFY_STATE,
> > *ExEventObjectType, Irp->RequestorMode, (PVOID*)
> > &EventHandleDestination, NULL);
> It's not clear to me how 'handleFromPython' gets its value. I
> expect that is your problem.
Yes, this seems to be the problem. "handleFromPython" must be a valid
Handle object which
represents a valid handle-entry in the user-modes handle-table of the
It's transfered using the buffered i/o mode and the following code
snippet in the driver:
HANDLE handleFromPython = *( (PHANDLE) Irp->AssociatedIrp.SystemBuffer )
(btw: this call (DeviceIoControl) succeeds with a HANDLE in C++, so it
must be something with the PyHANDLE given
to the win32file.DeviceIoControl(...), which i don't understand... )
> > Is it possible that the win32 extensions wrapped the functions
> > whithin it's own handle-table, so that the operating system can't
> > find the handle-id in the system handle table ?
> Nope, but there is "auto-close" behaviour that may be biting you
> (or about to bite you :)
> As soon as the ReadEvent object goes out of scope, CloseHandle()
> will be automatically called for the underlying handle. The
> Detach() method on a handle lets you get the integer handle and
> "detaches" it from the object, so CloseHandle will not be called.
> In your example above that should not be a problem (ReadEvent
> remains in scope during the call to DeviceIoControl) - but if the
> driver is storing the handle for use internally, things will start
> going wrong when the object dies.
More information about the Python-win32