[python-win32] Handle to a Driver

[Chi Tai]

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
handle error.

> > 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
calling Thread.
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.
>
>  Mark