Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


STATUS_PRIVILEGE_NOT_HELD while sending IOCTL_HID_GET_FEATURE from KMDF HID client

Sudheer_NairSudheer_Nair Member Posts: 20
edited October 28 in NTDEV
Hi,

To give a background....
I am writing a KMDF HID client driver that sits above the HIDClass(This is not a filter driver like the Firefly sample). This is a POC project and wanted to make sure if we are on the right track.

The stack would look something like:

HID client driver -> HIDClass -> HIDMiniport -> Firmware

Our firmware exposes a specific device for this HIDclient driver (the miniport is also owned by us).

The HID client INF looks something like:

------
Class = Sensor
ClassGuid = {5175D334-C371-4806-B3BA-71FD53C9258D}

The device ID part would be something like
%XXX.DeviceDesc%=XXX, HID\Vid_0001&Pid_0088
-----

Even though the UP/U exposed is for SENSOR, technically this would not be a sensor like any of the accelerometer etc. We would not be exposing this to the OS as a sensor.

Problem:
The driver loads and I am able to send some of the COLLECTION related IOCTL's and get data back.
For e.g. IOCTL_HID_GET_COLLECTION_INFORMATION, IOCTL_HID_GET_COLLECTION_DESCRIPTOR

But when I try to send a IOCTL_HID_GET_FEATURE, it fails with STATUS_PRIVILEGE_NOT_HELD

Initially I was using the local IO target (WdfDeviceGetIoTarget). I then tried using a remote IO target like the Firefly example. However in that case
WdfIoTargetOpen(...) failed with STATUS_NO_DEVICE.

ntStatus = WdfIoTargetCreate(p_wdfDevice,
WDF_NO_OBJECT_ATTRIBUTES,
&wdfIoTarget);
if (!NT_SUCCESS(ntStatus)) {
goto exit;
}

WDF_IO_TARGET_OPEN_PARAMS_INIT_OPEN_BY_NAME(&wdfIoTargetOpenParams,
&pDeviceContext->pdoName,
FILE_WRITE_ACCESS);
wdfIoTargetOpenParams.ShareAccess = FILE_SHARE_READ | FILE_SHARE_WRITE;
//pFileObject = WdfIoTargetWdmGetTargetFileObject(wdfIoTarget);
//if (pFileObject == NULL) {
// goto exit;
//}

//wdfIoTargetOpenParams.TargetFileObject = pFileObject;

ntStatus = WdfIoTargetOpen(wdfIoTarget, &wdfIoTargetOpenParams);
if (!NT_SUCCESS(ntStatus)) {
goto exit;
}

Would appreciate if someone could point to what I am missing here? The firefly sample seems to be doing the same?

Thanks in advance!
Post edited by Peter_Viscarola_(OSR) on

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,718
    Ask for read access as well

    Get Outlook for Android



    On Sat, Jul 16, 2016 at 10:12 PM -0700, "[email protected]" > wrote:

    Hi,

    To give a background....
    I am writing a KMDF HID client driver that sits above the HIDClass(This is not a filter driver like the Firefly sample). This is a POC project and wanted to make sure if we are on the right track.

    The stack would look something like:

    HID client driver -> HIDClass -> HIDMiniport -> Firmware

    Our firmware exposes a specific device for this HIDclient driver (the miniport is also owned by us).

    The HID client INF looks something like:

    ------
    Class = Sensor
    ClassGuid = {5175D334-C371-4806-B3BA-71FD53C9258D}

    The device ID part would be something like
    %XXX.DeviceDesc%=XXX, HID\Vid_0001&Pid_0088
    -----

    Even though the UP/U exposed is for SENSOR, technically this would not be a sensor like any of the accelerometer etc. We would not be exposing this to the OS as a sensor.

    Problem:
    The driver loads and I am able to send some of the COLLECTION related IOCTL's and get data back.
    For e.g. IOCTL_HID_GET_COLLECTION_INFORMATION, IOCTL_HID_GET_COLLECTION_DESCRIPTOR

    But when I try to send a IOCTL_HID_GET_FEATURE, it fails with STATUS_PRIVILEGE_NOT_HELD

    Initially I was using the local IO target (WdfDeviceGetIoTarget). I then tried using a remote IO target like the Firefly example. However in that case
    WdfIoTargetOpen(...) failed with STATUS_NO_DEVICE.

    ntStatus = WdfIoTargetCreate(p_wdfDevice,
    WDF_NO_OBJECT_ATTRIBUTES,
    &wdfIoTarget);
    if (!NT_SUCCESS(ntStatus)) {
    goto exit;
    }

    WDF_IO_TARGET_OPEN_PARAMS_INIT_OPEN_BY_NAME(&wdfIoTargetOpenParams,
    &pDeviceContext->pdoName,
    FILE_WRITE_ACCESS);
    wdfIoTargetOpenParams.ShareAccess = FILE_SHARE_READ | FILE_SHARE_WRITE;
    //pFileObject = WdfIoTargetWdmGetTargetFileObject(wdfIoTarget);
    //if (pFileObject == NULL) {
    // goto exit;
    //}

    //wdfIoTargetOpenParams.TargetFileObject = pFileObject;

    ntStatus = WdfIoTargetOpen(wdfIoTarget, &wdfIoTargetOpenParams);
    if (!NT_SUCCESS(ntStatus)) {
    goto exit;
    }

    Would appreciate if someone could point to what I am missing here? The firefly sample seems to be doing the same?

    Thanks in advance!


    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • Sudheer_NairSudheer_Nair Member Posts: 20
    Still fails similarly....

    WDF_IO_TARGET_OPEN_PARAMS_INIT_OPEN_BY_NAME(&wdfIoTargetOpenParams,
    &pDeviceContext->pdoName,
    FILE_READ_ACCESS | FILE_WRITE_ACCESS);

    WdfIoTargetOpen failed 0xc000000e
  • Sudheer_NairSudheer_Nair Member Posts: 20
    Some more info (for test purposes I am calling this from D0Entry):

    1: kd> !wdfkd.wdfdevice 0x00001fff`6fe5cae8 <-- This is my device/FDO
    Treating handle as a KMDF handle!

    Dumping WDFDEVICE 0x00001fff6fe5cae8
    =================================

    WDM PDEVICE_OBJECTs: self ffffe00090dad240, attached ffffe0008af83060, pdo ffffe0008af83060

    Pnp state: 108 ( WdfDevStatePnpHardwareAvailable )
    Power state: 30f ( WdfDevStatePowerD0Starting )
    Power Pol state: 501 ( WdfDevStatePwrPolStarting )

    Default WDFIOTARGET: 00001fff70214618

    Device is the power policy owner for the stack
    No pended power, wait-wake irps
    Pended pnp(IRP_MN_START_DEVICE) !irp 0xffffe0008ede1c10

    1: kd> !devobj ffffe0008af83060
    Device object (ffffe0008af83060) is for:
    00000055 \Driver\mshidkmdf DriverObject ffffe0008a7ab9c0
    Current Irp 00000000 RefCount 0 Type 00000022 Flags 00003050
    Dacl ffffc1024800fd11 DevExt ffffe0008af831b0 DevObjExt ffffe0008af83900 DevNode ffffe0008a9cf350
    ExtensionFlags (0x00000810) DOE_START_PENDING, DOE_DEFAULT_SD_PRESENT
    Characteristics (0x00000180) FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
    AttachedDevice (Upper) ffffe00090dad240 \Driver\XXX_hid
    Device queue is not busy.

    pdoname that I am passing below - "\Device\00000055"
    WDF_IO_TARGET_OPEN_PARAMS_INIT_OPEN_BY_NAME(&wdfIoTargetOpenParams,
    &pDeviceContext->pdoName,
    FILE_ANY_ACCESS);
    wdfIoTargetOpenParams.ShareAccess = FILE_SHARE_READ | FILE_SHARE_WRITE;
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,718
    Does the opening of the target succeed? You can't open a handle (which is what open by name does) until the stack has successfully completed the start request back to the pnp manager. You are in the middle of processing the start, so you should not be able to open the handle at the point

    Get Outlook for Android



    On Sun, Jul 17, 2016 at 9:50 AM -0700, "[email protected]" > wrote:

    Some more info (for test purposes I am calling this from D0Entry):

    1: kd> !wdfkd.wdfdevice 0x00001fff`6fe5cae8 <-- This is my device/FDO
    Treating handle as a KMDF handle!

    Dumping WDFDEVICE 0x00001fff6fe5cae8
    =================================

    WDM PDEVICE_OBJECTs: self ffffe00090dad240, attached ffffe0008af83060, pdo ffffe0008af83060

    Pnp state: 108 ( WdfDevStatePnpHardwareAvailable )
    Power state: 30f ( WdfDevStatePowerD0Starting )
    Power Pol state: 501 ( WdfDevStatePwrPolStarting )

    Default WDFIOTARGET: 00001fff70214618

    Device is the power policy owner for the stack
    No pended power, wait-wake irps
    Pended pnp(IRP_MN_START_DEVICE) !irp 0xffffe0008ede1c10

    1: kd> !devobj ffffe0008af83060
    Device object (ffffe0008af83060) is for:
    00000055 \Driver\mshidkmdf DriverObject ffffe0008a7ab9c0
    Current Irp 00000000 RefCount 0 Type 00000022 Flags 00003050
    Dacl ffffc1024800fd11 DevExt ffffe0008af831b0 DevObjExt ffffe0008af83900 DevNode ffffe0008a9cf350
    ExtensionFlags (0x00000810) DOE_START_PENDING, DOE_DEFAULT_SD_PRESENT
    Characteristics (0x00000180) FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
    AttachedDevice (Upper) ffffe00090dad240 \Driver\XXX_hid
    Device queue is not busy.

    pdoname that I am passing below - "\Device\00000055"
    WDF_IO_TARGET_OPEN_PARAMS_INIT_OPEN_BY_NAME(&wdfIoTargetOpenParams,
    &pDeviceContext->pdoName,
    FILE_ANY_ACCESS);
    wdfIoTargetOpenParams.ShareAccess = FILE_SHARE_READ | FILE_SHARE_WRITE;

    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • Sudheer_NairSudheer_Nair Member Posts: 20
    Hi Doron,

    No, with the remote target the open is what fails with "STATUS_NO_DEVICE". I do not get to the point of trying to send the IOCTL.
    ntStatus = WdfIoTargetOpen(wdfIoTarget, &wdfIoTargetOpenParams);

    I tried this from D0Exit which also had the same problem.

    Would there be a better place to call this from (other than making an external IOCTL call to trigger this) ? I do not have any interrupts etc but would providing a EvtDeviceD0EntryPostInterruptsEnabled callback and calling this from there help?

    Thanks
    Sudheer
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,718
    All of the initial calls to the init and power up related callbacks are before or during processing of the start request. None of them are after. The tried and true way is to register for HID notifications and when notified, open it up, check the PDO and if it is your stack's PDO you have opened your device, otherwise close it. I have heard of using other callbacks which happen to be invoked after processing the pnp start like EvtDeviceRelationsQuery for child relations and using that implementation detail to open the target.

    d

    -----Original Message-----
    From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
    Sent: Sunday, July 17, 2016 11:07 AM
    To: Windows System Software Devs Interest List <[email protected]>
    Subject: RE:[ntdev] STATUS_PRIVILEGE_NOT_HELD while sending IOCTL_HID_GET_FEATURE from KMDF HID client

    Hi Doron,

    No, with the remote target the open is what fails with "STATUS_NO_DEVICE". I do not get to the point of trying to send the IOCTL.
    ntStatus = WdfIoTargetOpen(wdfIoTarget, &wdfIoTargetOpenParams);

    I tried this from D0Exit which also had the same problem.

    Would there be a better place to call this from (other than making an external IOCTL call to trigger this) ? I do not have any interrupts etc but would providing a EvtDeviceD0EntryPostInterruptsEnabled callback and calling this from there help?

    Thanks
    Sudheer

    ---
    NTDEV is sponsored by OSR

    Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev&gt;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at <http://www.osr.com/seminars&gt;

    To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer&gt;
    d
  • Sudheer_NairSudheer_Nair Member Posts: 20
    Hi Doron,

    Thanks for your inputs, appreciate it!

    1. Regarding HID notifications, is there a DEVICE INTERFACE GUID that I can register for ?
    From the link: https://msdn.microsoft.com/en-us/library/windows/hardware/ff538731(v=vs.85).aspx
    If the driver is not a function or filter driver, it typically uses Plug and Play notification to find a collection

    2. I did see AddDevice getting called twice; is this expected?

    3. I tried to supply a EvtDeviceIoControl for handling ioctl's from user space and call the collection/GET_FEATURE ioctl's to the remote target(using pdoname).
    I was able to do the target open but these ioctl's came to my EvtDeviceIoControl. From here how can I forward without getting the PRIVILIGE error? If I use the local IO target I do get the privilige error.

    Thanks
    Sudheer
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,718
    1) there is HID device interface guid. I just remembers a simpler solution. You register your own device interface guid and then listen for its arrival and then open yourself up, making sure the create irp goes all the way down the stack.

    2) if you are installed on one device, not expected. If you installed your driver with devcon install, which creates a root device, it could explain it. You could also be failing start, the stack is torn down and then built up again.

    3) how are you formatting the request to send down the stack on the local io target? Are you using WdfRequestFormatRequestUsingCurrentType? If that is not working, in addition to the call afterwards you should set the file object manually

    PIRP irp = WdfRequestWdmGetIrp(request);
    IoGetNextIrpStackLocation(irp)->FileObject = IoGetCurrentIrpStackLocation(irp)

    d
    -----Original Message-----
    From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
    Sent: Sunday, July 17, 2016 5:49 PM
    To: Windows System Software Devs Interest List <[email protected]>
    Subject: RE:[ntdev] STATUS_PRIVILEGE_NOT_HELD while sending IOCTL_HID_GET_FEATURE from KMDF HID client

    Hi Doron,

    Thanks for your inputs, appreciate it!

    1. Regarding HID notifications, is there a DEVICE INTERFACE GUID that I can register for ?
    From the link: https://msdn.microsoft.com/en-us/library/windows/hardware/ff538731(v=vs.85).aspx
    If the driver is not a function or filter driver, it typically uses Plug and Play notification to find a collection

    2. I did see AddDevice getting called twice; is this expected?

    3. I tried to supply a EvtDeviceIoControl for handling ioctl's from user space and call the collection/GET_FEATURE ioctl's to the remote target(using pdoname).
    I was able to do the target open but these ioctl's came to my EvtDeviceIoControl. From here how can I forward without getting the PRIVILIGE error? If I use the local IO target I do get the privilige error.

    Thanks
    Sudheer

    ---
    NTDEV is sponsored by OSR

    Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev&gt;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at <http://www.osr.com/seminars&gt;

    To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer&gt;
    d
  • Sudheer_NairSudheer_Nair Member Posts: 20
    1. Will look into this.

    2. I am using "devcon update" and not install to avoid the "root" related side effect. Will see if there is a failure somewhere that I might be missing.

    3. This is what I am doing for forwarding:
    WDF_REQUEST_SEND_OPTIONS wdfRequestSendOptions;

    WdfRequestFormatRequestUsingCurrentType(p_wdfRequest);
    WDF_REQUEST_SEND_OPTIONS_INIT(&wdfRequestSendOptions, WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET);

    bStatus = WdfRequestSend(p_wdfRequest, wdfIoTarget, &wdfRequestSendOptions);

    Will try to manually set the FileObject.

    Thanks!
  • Sudheer_NairSudheer_Nair Member Posts: 20
    It seems WdfRequestFormatRequestUsingCurrentType(p_wdfRequest) does copy the fileobject. I assume you were meaning to do the following?

    IoGetNextIrpStackLocation(irp)->FileObject = IoGetCurrentIrpStackLocation(irp)->FileObject

    The GET_FEATURE still had the same error. The WdfRequestSend call seems to call the DeviceIoControl again - is this expected? It does seem to send it after that.

    Also after sometime it crashed if I do the copy manually (after I get the FAILURE). Otherwise it just seems to fail the IOCTL.

    00 xxx_hid!EvtIoDeviceControl <-----------------------Again EvtDeviceIoControl?
    01 Wdf01000!FxIoQueueIoDeviceControl::Invoke
    02 Wdf01000!FxIoQueue::DispatchRequestToDriver
    03 Wdf01000!FxIoQueue::DispatchEvents
    04 Wdf01000!FxIoQueue::QueueRequest
    05 Wdf01000!FxPkgIo::DispatchStep2
    06 Wdf01000!FxPkgIo::DispatchStep1
    07 Wdf01000!DispatchWorker
    08 Wdf01000!FxDevice::Dispatch
    09 Wdf01000!FxDevice::DispatchWithLock
    0a Wdf01000!imp_WdfRequestSend
    0b xxx_hid!WdfRequestSend
    0c xxx_hid!EvtIoDeviceControl <-----------------------EvtDeviceIoControl
    0d Wdf01000!FxIoQueueIoDeviceControl::Invoke
    0e Wdf01000!FxIoQueue::DispatchRequestToDriver
    0f Wdf01000!FxIoQueue::DispatchEvents
    10 Wdf01000!FxIoQueue::QueueRequest
    11 Wdf01000!FxPkgIo::DispatchStep2
    12 Wdf01000!FxPkgIo::DispatchStep1
    13 Wdf01000!DispatchWorker
    14 Wdf01000!FxDevice::Dispatch
    15 Wdf01000!FxDevice::DispatchWithLock
    16 Wdf01000!FxIoTarget::SubmitSync
    17 Wdf01000!FxIoTargetSendIoctl
    18 Wdf01000!imp_WdfIoTargetSendIoctlSynchronously
    19 xxx_hid!WdfIoTargetSendIoctlSynchronously
    1a xxx_hid!xxxHidGetCollection <--------------------- Call GET_FEATURE
    1b xxx_hid!EvtIoDeviceControl
    1c Wdf01000!FxIoQueueIoDeviceControl::Invoke
    1d Wdf01000!FxIoQueue::DispatchRequestToDriver
    1e Wdf01000!FxIoQueue::DispatchEvents
    1f Wdf01000!FxIoQueue::QueueRequest

    I just tried to put some bp in HIDClass......
    xxx_hid!EvtIoDeviceControl+0x136:
    fffff801`d4e21f36 cc int 3
    2: kd> g
    Breakpoint 1 hit
    HIDCLASS!HidpIrpMajorDeviceControl+0x687:
    fffff801`d4b82ef7 8bf0 mov esi,eax
    2: kd> g
    Breakpoint 0 hit
    HIDCLASS!HidpMajorHandler+0x159:
    fffff801`d4b82629 eb0b jmp HIDCLASS!HidpMajorHandler+0x166 (fffff801`d4b82636)
    2: kd> g
    XXXHidGetCollection: IOCTL_HID_GET_FEATURE failed 0xc0000061
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,718
    Did you forward the create request down the stack in EvtDeviceFileCreate for hidclass to process it? If not, you must.

    Get Outlook for Android



    On Sun, Jul 17, 2016 at 9:46 PM -0700, "[email protected]" > wrote:

    It seems WdfRequestFormatRequestUsingCurrentType(p_wdfRequest) does copy the fileobject. I assume you were meaning to do the following?

    IoGetNextIrpStackLocation(irp)->FileObject = IoGetCurrentIrpStackLocation(irp)->FileObject

    The GET_FEATURE still had the same error. The WdfRequestSend call seems to call the DeviceIoControl again - is this expected? It does seem to send it after that.

    Also after sometime it crashed if I do the copy manually (after I get the FAILURE). Otherwise it just seems to fail the IOCTL.

    00 xxx_hid!EvtIoDeviceControl <-----------------------Again EvtDeviceIoControl?
    01 Wdf01000!FxIoQueueIoDeviceControl::Invoke
    02 Wdf01000!FxIoQueue::DispatchRequestToDriver
    03 Wdf01000!FxIoQueue::DispatchEvents
    04 Wdf01000!FxIoQueue::QueueRequest
    05 Wdf01000!FxPkgIo::DispatchStep2
    06 Wdf01000!FxPkgIo::DispatchStep1
    07 Wdf01000!DispatchWorker
    08 Wdf01000!FxDevice::Dispatch
    09 Wdf01000!FxDevice::DispatchWithLock
    0a Wdf01000!imp_WdfRequestSend
    0b xxx_hid!WdfRequestSend
    0c xxx_hid!EvtIoDeviceControl <-----------------------EvtDeviceIoControl
    0d Wdf01000!FxIoQueueIoDeviceControl::Invoke
    0e Wdf01000!FxIoQueue::DispatchRequestToDriver
    0f Wdf01000!FxIoQueue::DispatchEvents
    10 Wdf01000!FxIoQueue::QueueRequest
    11 Wdf01000!FxPkgIo::DispatchStep2
    12 Wdf01000!FxPkgIo::DispatchStep1
    13 Wdf01000!DispatchWorker
    14 Wdf01000!FxDevice::Dispatch
    15 Wdf01000!FxDevice::DispatchWithLock
    16 Wdf01000!FxIoTarget::SubmitSync
    17 Wdf01000!FxIoTargetSendIoctl
    18 Wdf01000!imp_WdfIoTargetSendIoctlSynchronously
    19 xxx_hid!WdfIoTargetSendIoctlSynchronously
    1a xxx_hid!xxxHidGetCollection <--------------------- Call GET_FEATURE
    1b xxx_hid!EvtIoDeviceControl
    1c Wdf01000!FxIoQueueIoDeviceControl::Invoke
    1d Wdf01000!FxIoQueue::DispatchRequestToDriver
    1e Wdf01000!FxIoQueue::DispatchEvents
    1f Wdf01000!FxIoQueue::QueueRequest

    I just tried to put some bp in HIDClass......
    xxx_hid!EvtIoDeviceControl+0x136:
    fffff801`d4e21f36 cc int 3
    2: kd> g
    Breakpoint 1 hit
    HIDCLASS!HidpIrpMajorDeviceControl+0x687:
    fffff801`d4b82ef7 8bf0 mov esi,eax
    2: kd> g
    Breakpoint 0 hit
    HIDCLASS!HidpMajorHandler+0x159:
    fffff801`d4b82629 eb0b jmp HIDCLASS!HidpMajorHandler+0x166 (fffff801`d4b82636)
    2: kd> g
    XXXHidGetCollection: IOCTL_HID_GET_FEATURE failed 0xc0000061



    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • Sudheer_NairSudheer_Nair Member Posts: 20
    I have not set a callback for evtdevicefilecreate; was not aware that was needed?
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,718
    Are you calling WdfFdoInitSetFilter?

    Get Outlook for Android



    On Mon, Jul 18, 2016 at 12:41 AM -0700, "[email protected]" > wrote:

    I have not set a callback for evtdevicefilecreate; was not aware that was needed?

    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • Sudheer_NairSudheer_Nair Member Posts: 20
    I was calling InitSetFilter at some point but I was getting an error in the target open (I believe for SHARE ACCESS being incompatible).
    So I had commented that out. In that case it would have sent the create down without the callback being needed. I was not sure if calling
    SetFilter without having it in the INF had any side effects?

    Meanwhile providing the EvtDeviceFileCreate callback and passing it down worked! Even the SetFilter without providing the File callbacks work now!
    I am at least able to do a GET_FEATURE and see some data.
    Thanks for being patient and providing your responses!

    Had a related followup, if you don't mind:

    1. If I do not want to load this as a function driver and want to talk to the HIDClass directly would that be doable? Is there a good documentation on MSDN for that?
    The only thing I found (https://msdn.microsoft.com/en-us/library/windows/hardware/ff538731(v=vs.85).aspx) does not have much data for KMDF, especially the HID interface
    I should be registering for etc.

    2. Since our collection gets exposed as a UP=20(Sensor); and if we don't load our driver on that device then I assume the inbox MS Sensor driver would claim it. In that
    case would there be an issue in doing 1. above?

    3. The reason I am asking about the above is that we need to exchange data with the ACPI stack. We will have a ACPI driver that loads on an ACPI device and that can talk
    to this HID driver via driver-driver interface (QueryInterface). If 1. is doable then probably the ACPI driver could find the collection and start sending GET/SET feature directly?

    Thanks
    Sudheer
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,718
    1) yes you can open a HID for from outside the stack. IoRegisterPlugPlayNotification on the HID device interface guid (GUID_DEVINTERFACE_HID). You would then open each notification and see if it is your HID. You would then have to register for file handle notifications so you can close the handle in case the HID is removed. The opening and handle notifications are handled by a remote io target.

    2) if the inbox hid sensor driver opens the HID for exclusive access (I don't know either way), then no, you couldn't open it. You can let the in box driver load and then try the experiment from a user mode app, the sensor driver won't know the difference.

    3) yes, also assuming the in box sensor driver lets you still open the HID

    -----Original Message-----
    From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
    Sent: Monday, July 18, 2016 11:29 AM
    To: Windows System Software Devs Interest List <[email protected]>
    Subject: RE:[ntdev] STATUS_PRIVILEGE_NOT_HELD while sending IOCTL_HID_GET_FEATURE from KMDF HID client

    I was calling InitSetFilter at some point but I was getting an error in the target open (I believe for SHARE ACCESS being incompatible).
    So I had commented that out. In that case it would have sent the create down without the callback being needed. I was not sure if calling SetFilter without having it in the INF had any side effects?

    Meanwhile providing the EvtDeviceFileCreate callback and passing it down worked! Even the SetFilter without providing the File callbacks work now!
    I am at least able to do a GET_FEATURE and see some data.
    Thanks for being patient and providing your responses!

    Had a related followup, if you don't mind:

    1. If I do not want to load this as a function driver and want to talk to the HIDClass directly would that be doable? Is there a good documentation on MSDN for that?
    The only thing I found (https://msdn.microsoft.com/en-us/library/windows/hardware/ff538731(v=vs.85).aspx) does not have much data for KMDF, especially the HID interface I should be registering for etc.

    2. Since our collection gets exposed as a UP=20(Sensor); and if we don't load our driver on that device then I assume the inbox MS Sensor driver would claim it. In that case would there be an issue in doing 1. above?

    3. The reason I am asking about the above is that we need to exchange data with the ACPI stack. We will have a ACPI driver that loads on an ACPI device and that can talk to this HID driver via driver-driver interface (QueryInterface). If 1. is doable then probably the ACPI driver could find the collection and start sending GET/SET feature directly?

    Thanks
    Sudheer

    ---
    NTDEV is sponsored by OSR

    Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev&gt;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at <http://www.osr.com/seminars&gt;

    To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer&gt;
    d
  • Sudheer_NairSudheer_Nair Member Posts: 20
    Thanks Doron!
  • Sudheer_NairSudheer_Nair Member Posts: 20
    Hi Doron,

    Tried getting the HID class interface:

    I was able to call GET_COLLECTION_INFO for most of the HID collection that came along and check the VID/PID but for my device (on which the MS HID Sensor driver is loaded and there is only one)
    the TargetOpen failed with STATUS_INVALID_DEVICE_REQUEST.

    Snippet from logdump (last one is the failure):

    120: FxIoTarget::WaitForDisposeEvent - WDFIOTARGET 00001FFE15206438, Waiting on Dispose event FFFFD000727D7450
    121: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15206438 derefing PDO FFFFE001EADFA060 on close
    122: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15206438 derefing FileObj FFFFE001EADFC430 on close
    123: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15206438 closing handle FFFFFFFF800004B0 on close
    124: FxIoTargetRemote::OpenTargetHandle - ZwCreateFile for WDFIOTARGET 00001FFE15410228 returned status STATUS_SUCCESS, info 0x0
    125: FxIoTargetRemote::ClearTargetPointers - WDFIOTARGET 00001FFE15410228 cleared pointers FFFFD000727CF4E0 state WdfIoTargetDeleted, open state 3, pdo FFFFE001EADF9060, fileobj FFFFE001EABEFCD0, handle FFFFFFFF80000434
    126: FxIoTarget::WaitForDisposeEvent - WDFIOTARGET 00001FFE15410228, Waiting on Dispose event FFFFD000727CF450
    127: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15410228 derefing PDO FFFFE001EADF9060 on close
    128: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15410228 derefing FileObj FFFFE001EABEFCD0 on close
    129: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15410228 closing handle FFFFFFFF80000434 on close
    130: FxIoTargetRemote::OpenTargetHandle - ZwCreateFile for WDFIOTARGET 00001FFE154105C8 returned status STATUS_SUCCESS, info 0x0
    131: FxIoTargetRemote::ClearTargetPointers - WDFIOTARGET 00001FFE154105C8 cleared pointers FFFFD000727CF4E0 state WdfIoTargetDeleted, open state 3, pdo FFFFE001EADC7060, fileobj FFFFE001EADFC430, handle FFFFFFFF80000434
    132: FxIoTarget::WaitForDisposeEvent - WDFIOTARGET 00001FFE154105C8, Waiting on Dispose event FFFFD000727CF450
    133: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE154105C8 derefing PDO FFFFE001EADC7060 on close
    134: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE154105C8 derefing FileObj FFFFE001EADFC430 on close
    135: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE154105C8 closing handle FFFFFFFF80000434 on close
    136: FxIoTargetRemote::OpenTargetHandle - ZwCreateFile for WDFIOTARGET 00001FFE14018368 returned status 0xc0000010(STATUS_INVALID_DEVICE_REQUEST), info 0x3c006a

    Would that be an indication that the HID Sensor driver is not allowing the open like you had mentioned previously?
    Is there a way to interpret the info code?

    Thanks!
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,718
    That would be my guess. Even if it allowed opens, the sensor driver would talk "sensors io", not "hid io". If you need the hid sensor to be consumed as a sensor by the OS AND still query it for raw data, you need to either filter below the hid sensor driver or figure out how to open a handle to the sensor driver and see if there is raw or cooked sensor data that meets your needs. Getting the create handle to succeed might be as simple as configuring the umdf hid sensor driver to allow km creates ( by default umdf drivers do not allow km originated creates)

    Get Outlook for Android



    On Tue, Jul 19, 2016 at 5:30 PM -0700, "[email protected]" > wrote:

    Hi Doron,

    Tried getting the HID class interface:

    I was able to call GET_COLLECTION_INFO for most of the HID collection that came along and check the VID/PID but for my device (on which the MS HID Sensor driver is loaded and there is only one)
    the TargetOpen failed with STATUS_INVALID_DEVICE_REQUEST.

    Snippet from logdump (last one is the failure):

    120: FxIoTarget::WaitForDisposeEvent - WDFIOTARGET 00001FFE15206438, Waiting on Dispose event FFFFD000727D7450
    121: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15206438 derefing PDO FFFFE001EADFA060 on close
    122: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15206438 derefing FileObj FFFFE001EADFC430 on close
    123: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15206438 closing handle FFFFFFFF800004B0 on close
    124: FxIoTargetRemote::OpenTargetHandle - ZwCreateFile for WDFIOTARGET 00001FFE15410228 returned status STATUS_SUCCESS, info 0x0
    125: FxIoTargetRemote::ClearTargetPointers - WDFIOTARGET 00001FFE15410228 cleared pointers FFFFD000727CF4E0 state WdfIoTargetDeleted, open state 3, pdo FFFFE001EADF9060, fileobj FFFFE001EABEFCD0, handle FFFFFFFF80000434
    126: FxIoTarget::WaitForDisposeEvent - WDFIOTARGET 00001FFE15410228, Waiting on Dispose event FFFFD000727CF450
    127: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15410228 derefing PDO FFFFE001EADF9060 on close
    128: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15410228 derefing FileObj FFFFE001EABEFCD0 on close
    129: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE15410228 closing handle FFFFFFFF80000434 on close
    130: FxIoTargetRemote::OpenTargetHandle - ZwCreateFile for WDFIOTARGET 00001FFE154105C8 returned status STATUS_SUCCESS, info 0x0
    131: FxIoTargetRemote::ClearTargetPointers - WDFIOTARGET 00001FFE154105C8 cleared pointers FFFFD000727CF4E0 state WdfIoTargetDeleted, open state 3, pdo FFFFE001EADC7060, fileobj FFFFE001EADFC430, handle FFFFFFFF80000434
    132: FxIoTarget::WaitForDisposeEvent - WDFIOTARGET 00001FFE154105C8, Waiting on Dispose event FFFFD000727CF450
    133: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE154105C8 derefing PDO FFFFE001EADC7060 on close
    134: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE154105C8 derefing FileObj FFFFE001EADFC430 on close
    135: FxIoTargetRemote::Close - WDFIOTARGET 00001FFE154105C8 closing handle FFFFFFFF80000434 on close
    136: FxIoTargetRemote::OpenTargetHandle - ZwCreateFile for WDFIOTARGET 00001FFE14018368 returned status 0xc0000010(STATUS_INVALID_DEVICE_REQUEST), info 0x3c006a

    Would that be an indication that the HID Sensor driver is not allowing the open like you had mentioned previously?
    Is there a way to interpret the info code?

    Thanks!

    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • Sudheer_NairSudheer_Nair Member Posts: 20
    Thanks Again!

    We do not need to expose this to the OS. The FW exposes this as a sensor device and currently we do not have the flexibility to change that. So if we do not load on this device the inbox UMDF driver is going claim it. In that scenario was evaluating the option of our KMDF ACPI driver to talk to the HID stack directly so that we have only one driver. The other option is the original one in this thread where we claim the device and talk to the ACPI driver via a private interface.

    Technically there could be multiple instances of the sensor devices(only one of which would be the one I am interested in) exposed and correspondingly there would be that many instances of the inbox sensor driver. In such a scenario would it be possible to have this ACPI driver as a lower filter for just one particular instance of the inbox sensor driver?

    Thanks
    Sudheer
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,718
    You have an additional alternative. You write an INF that installs the "null" driver on top of the device (it is a special directive in the INF, there is no physical null driver), essentially blocking out the sensor driver from matching against the device. With the null driver installed, it is a normal HID and you can access it with normal HID semantics and HID io

    If you can give the special sensor that should not be exposed as a sensor its own unique hardware ID (compared to its peers which will be sensors who have a different hardware ID), yes it is easy to target on the special sensor. If you can't, then you have to have magic in your installer that identifies the right sensor. Special magic in the installer only works for desktop or server, if you want to target phone or other Microsoft OS editions, you can't do that. Even on desktop, special installer magic makes migration to a new OS very difficult and perhaps it does not replicate on the new OS.

    d

    -----Original Message-----
    From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
    Sent: Tuesday, July 19, 2016 9:13 PM
    To: Windows System Software Devs Interest List <[email protected]>
    Subject: RE:[ntdev] STATUS_PRIVILEGE_NOT_HELD while sending IOCTL_HID_GET_FEATURE from KMDF HID client

    Thanks Again!

    We do not need to expose this to the OS. The FW exposes this as a sensor device and currently we do not have the flexibility to change that. So if we do not load on this device the inbox UMDF driver is going claim it. In that scenario was evaluating the option of our KMDF ACPI driver to talk to the HID stack directly so that we have only one driver. The other option is the original one in this thread where we claim the device and talk to the ACPI driver via a private interface.

    Technically there could be multiple instances of the sensor devices(only one of which would be the one I am interested in) exposed and correspondingly there would be that many instances of the inbox sensor driver. In such a scenario would it be possible to have this ACPI driver as a lower filter for just one particular instance of the inbox sensor driver?

    Thanks
    Sudheer

    ---
    NTDEV is sponsored by OSR

    Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev&gt;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at <http://www.osr.com/seminars&gt;

    To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer&gt;
    d
  • Sudheer_NairSudheer_Nair Member Posts: 20
    The null driver option seems promising. We do have the option of having a special ID for this device.

    I assume if we have to sign the drivers eventually we will have to submit the null driver INF also in the package and it should be OK?
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,718
    Yes

    Get Outlook for Android



    On Tue, Jul 19, 2016 at 11:42 PM -0700, "[email protected]" > wrote:

    The null driver option seems promising. We do have the option of having a special ID for this device.

    I assume if we have to sign the drivers eventually we will have to submit the null driver INF also in the package and it should be OK?

    ---
    NTDEV is sponsored by OSR

    Visit the list online at:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at

    To unsubscribe, visit the List Server section of OSR Online at
    d
  • ginolinginolin Member Posts: 1

    I got the same problem. I fixed it by calling "WdfIoTargetSendInternalIoctlSynchronously()" for sending IOCTL_HID_GET_FEATURE.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,043

    @ginolin ... I'm sure the OP will appreciate your advice, even if it is 6 years after he needed it.

    People, people, people: CHECK THE DATE before you respond. Please?

    Peter Viscarola
    OSR
    @OSRDrivers

This discussion has been closed.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 January 2023 Live, Online
Developing Minifilters 20 March 2023 Live, Online
Writing WDF Drivers TBD 2023 Live, Online
Internals & Software Drivers 17 April 2023 Live, Online