ObReferenceObjectByHandle failing randomly when called repeatedly

This is a test-scenario, scenario is this:

A user-mode App opens a kernel-mode driver HANDLE using CreateFile(), calls an IOCTL where a HANDLE from CreateEvent() is passed in as input, Closes the driver HANDLE obtained from CreateFile() and Closes the Event HANDLE, in an infinite loop.

Since the Event HANDLE is from usermode, the kernel-mode driver calls ObReferenceObjectByHandle() to check HANDLE validity in the IOCTL, and calls ObDereferenceObject() in FileClose().

This runs a few hundred loops successfully, then suddenly the ObReferenceObjectByHandle() returns an error code saying STATUS_INVALID_HANDLE.

The number of successful tries is random, one time it succeeded 363 times, another try it succeeded ~50,000 times before hitting the error.

Any ideas of what could be going wrong in the scenario is highly appreciated!

Thanks
Madhavi

Is your driver using KMDF? If yes, in what function do you handle this IOCTL?

Yes, the driver is using KMDF. The WDFQUEUE for IOCTL is configured to dispatch sequentially, and the IOCTL is handled in the EvtIoDeviceControl for the Queue.

Thanks
Madhavi

EvtIoDeviceControl can be called in any context, it is not guaranteed to be called in the context of your app. Make the Ob call in EvtInCallerContext and then do the rest if your processing in EvtIoDeviceControl

d

debt from my phone


From: xxxxx@gmail.com
Sent: 9/25/2012 5:18 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ObReferenceObjectByHandle failing randomly when called repeatedly

Yes, the driver is using KMDF. The WDFQUEUE for IOCTL is configured to dispatch sequentially, and the IOCTL is handled in the EvtIoDeviceControl for the Queue.

Thanks
Madhavi


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

My own opinion is that the design of the driver is flawed beyond any hope
of recovery, and should be redone. The notion that event signaling makes
sense is at best a fiction, beloved by far too many driver writers as the
first cut on a design. It rarely makes sense. Possibly, it never makes
sense. Also, Occam’s Razor applies: if you are doing something complex
that causes a failure, make it simpler.
joe

This is a test-scenario, scenario is this:

A user-mode App opens a kernel-mode driver HANDLE using CreateFile(),
calls an IOCTL where a HANDLE from CreateEvent() is passed in as input,
Closes the driver HANDLE obtained from CreateFile() and Closes the Event
HANDLE, in an infinite loop.

Since the Event HANDLE is from usermode, the kernel-mode driver calls
ObReferenceObjectByHandle() to check HANDLE validity in the IOCTL, and
calls ObDereferenceObject() in FileClose().

This runs a few hundred loops successfully, then suddenly the
ObReferenceObjectByHandle() returns an error code saying
STATUS_INVALID_HANDLE.

The number of successful tries is random, one time it succeeded 363 times,
another try it succeeded ~50,000 times before hitting the error.

Any ideas of what could be going wrong in the scenario is highly
appreciated!

Thanks
Madhavi


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer