I have a USB HID device that requires no IHV driver and uses the system
supplied hidusb.sys, hidclass.sys and hidparse.sys. I have written a hid
minidriver, based on the WDF UMDF2 vhidmini2 sample model, for this device
and it installs mshidumdf.sys below the hidclass.sys driver and above
itself. Where are hidusb.sys and hidparse.sys located in the driver
hierarchy in relation to mshidumdf.sys and my driver?
If hidusb.sys is above my driver then do I have to use the WdfUsbTarget
methods to communicate with the device rather than the WdfioTarget methods?
If you are filtering below hidusb you are no longer a hid minidriver and can’t use the hid minidriver infrastructure (like mshidumdf.sys), so I am a little confused as to how you think this should work. If you want to filter below hidusb you have to write a KMDF lower filter driver (start with the toaster sample).
To answer the title question. Hidparse.sys is just an export driver (e.g. a KM DLL) that hidclass links to to parse hid reports. Hidclass itself is an export driver that KM hid miniport links to, in this case, hidusb.
d
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Randy Lewis
Sent: Thursday, February 25, 2016 10:30 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Where are hidusb and hidparse in the driver hiearchy in relation to mshidumdf and a hid minidriver?
I have a USB HID device that requires no IHV driver and uses the system supplied hidusb.sys, hidclass.sys and hidparse.sys. I have written a hid minidriver, based on the WDF UMDF2 vhidmini2 sample model, for this device and it installs mshidumdf.sys below the hidclass.sys driver and above itself. Where are hidusb.sys and hidparse.sys located in the driver hierarchy in relation to mshidumdf.sys and my driver?
If hidusb.sys is above my driver then do I have to use the WdfUsbTarget methods to communicate with the device rather than the WdfioTarget methods?
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>
I’m confused, the online WDK documentation for “Creating WDF HID Minidrivers” states:
"This topic describes how to create a Human Interface Device (HID) minidriver using Windows Driver Frameworks (WDF).
You can write a HID minidriver using either KMDF or UMDF. We recommend starting with the vhidmini2 minidriver sample. You can compile this sample driver using either KMDF or UMDF 2.x.
What to provide
1.You’ll write a lower filter driver under MsHidUmdf.sys (for UMDF) or MsHidKmdf.sys (for KMDF), both of which are included as part of the operating system.
2.Download and review the vhidmini2 sample."
I have done what is described above. The only significant changes I have made to the sample driver are related to modifying the data passing through the driver from and to the user app plus my efforts to add communication with an actual device. The sample driver is virtual and works without a device installed but I assume it can be made to work with a device installed, I just don’t know how.
I think you’re telling me that hidusb.sys itself is a minidriver and is above my driver and I assume it is above mshidumdf.sys as well. Is my driver no longer a minidriver, as you state, because that role is usurped by hidusb?
Randy
Yes. Hidusb is the minidriver. You are confusing the mechanics of how you write a WDF based hid mini driver (as a lower filter paired with mshid(u)(k)mdf.sys) with filtering an existing hid stack. In the built in hid stack (hidusb) there are no lower filters. By adding one you are adding a different type of driver.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@cox.net
Sent: Thursday, February 25, 2016 2:31 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Where are hidusb and hidparse in the driver hiearchy in relation to mshidumdf and a hid minidriver?
I’m confused, the online WDK documentation for “Creating WDF HID Minidrivers” states:
“This topic describes how to create a Human Interface Device (HID) minidriver using Windows Driver Frameworks (WDF).
You can write a HID minidriver using either KMDF or UMDF. We recommend starting with the vhidmini2 minidriver sample. You can compile this sample driver using either KMDF or UMDF 2.x.
What to provide
1.You’ll write a lower filter driver under MsHidUmdf.sys (for UMDF) or MsHidKmdf.sys (for KMDF), both of which are included as part of the operating system.
https://na01.safelinks.protection.outlook.com/?url=2.Download&data=01|01|Doron.Holan%40microsoft.com|f858583b470c49687ee308d33e334f1e|72f988bf86f141af91ab2d7cd011db47|1&sdata=wQq3xCzU%2FCBXQCOfU2%2FSzelI4tnAewNIdGBw7fVO3aA%3D and review the vhidmini2 sample.”
I have done what is described above. The only significant changes I have made to the sample driver are related to modifying the data passing through the driver from and to the user app plus my efforts to add communication with an actual device. The sample driver is virtual and works without a device installed but I assume it can be made to work with a device installed, I just don’t know how.
I think you’re telling me that hidusb.sys itself is a minidriver and is above my driver and I assume it is above mshidumdf.sys as well. Is my driver no longer a minidriver, as you state, because that role is usurped by hidusb?
Randy
—
NTDEV is sponsored by OSR
Visit the list online at: https:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:
To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>
Doron,
Aren’t most HID devices also USB devices and, therefore, why does the WDK documentation recommend starting with the vhidmini2 sample driver when it can’t communicate with the HID devices for which a person would want to write a driver? I feel misled by this recommendation, although as a virtual driver it has provided me with a valuable tool since its allowed me to reverse engineer the user app commands without the need to have a device installed and connected to the system that it would monitor.
Going forward, if all I need is to modify the user input, before it goes to the device, and the and device output, before it is returned to the app, that are associated with user app WriteFile and ReadFile requests, would you still recommend the toaster sample model as the best place to start?
Randy
Because nearly all hid devices are class compliant and no one needs to write a driver for them. Hidusbfx2 is the other wdf based hid miniport example and it shows how to tall to a Usb device (in this case make the osr fx2 dev board look like a hid)
Sent from my Windows 10 phone
From: xxxxx@cox.netmailto:xxxxx
Sent: Thursday, February 25, 2016 5:32 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Where are hidusb and hidparse in the driver hiearchy in relation to mshidumdf and a hid minidriver?
Doron,
Aren’t most HID devices also USB devices and, therefore, why does the WDK documentation recommend starting with the vhidmini2 sample driver when it can’t communicate with the HID devices for which a person would want to write a driver? I feel misled by this recommendation, although as a virtual driver it has provided me with a valuable tool since its allowed me to reverse engineer the user app commands without the need to have a device installed and connected to the system that it would monitor.
Going forward, if all I need is to modify the user input, before it goes to the device, and the and device output, before it is returned to the app, that are associated with user app WriteFile and ReadFile requests, would you still recommend the toaster sample model as the best place to start?
Randy
—
NTDEV is sponsored by OSR
Visit the list online at: https:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:
To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:></mailto:xxxxx></mailto:xxxxx>
Good, I recently received an OSR FX2 dev board to experiment with. Maybe I can accomplish two things with one driver and conserve time and effort.
>I have a USB HID device that requires no IHV driver
Then why are you writing a driver for it?
Can’t you just access the HID report flow via DirectInput?
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Maxim,
Your timing is perfect, I just logged in to ask one more time what the best way to proceed would be. At this stage in my project all I need to accomplish is to intercept the user app WriteFile and ReadFile requests to the device so that I can alter the contents of the write requests before they go to the device and responses to the read requests before they are returned to the app. The request packets are 17 bytes with the first byte being the HID ReportId. The remaining 16 bytes of write requests are commands to the device, which returns 16 byte messages in response to read requests. I do not need to add new device features or change the size of the packets. I had originally thought I could simply do this within the virtual hidmini driver that I wrote to masquerade as the device when I was reverse engineering the user app command and expected response format. Based on Doron’s feedback I guess that driver cannot be made to communicate with the device. I would like to stay in user mode, since it allows me to monitor the I/O packets flowing through the driver with KdPrint commands and attaching WinDbg to the WudfHost process. Alternatively, however, I could do this with a USB packet sniffer. I was just looking at the UMDF2 Echo sample driver model, wondering whether I could use that, what do you think?
I’m not familiar with DirectInput that you referred to. Would you please tell me more about it?
Doron,
I hope you get this, I’m at my wits end with this project. Per one of your recommendations I’ve tried using the Toaster KMDF generic filter driver to communicate with my device. It looks ideal for what I want to do, but when I install it into the devices driver stack the user app can no longer find the device because it is no longer associated with the HIDClass setup class (at least that is what I think is happening). Can I simply change the Toaster filter INF file [Version] Class to HIDClass and ClassGUID to {system assigned GUID for HID collection} to correct this problem? And if I do, will I have to remove the [ClassInstall32] section and move the AddReg directive to the [DDInstall.HW] section?
Also, the Toaster generic filter INF file has an AddReg directive:
HKR,“UpperFiltes”,0x00010000,“ToasterFilter”
Should this be changed to “LowerFilters”?
I’m desperate to get over this hurdle.
Randy
Yes, your inf needs to match the std driver?s class. Are you matching on the HID\ id or USB\ ?
Sent from my Windows 10 phone
From: xxxxx@cox.netmailto:xxxxx
Sent: Saturday, February 27, 2016 12:07 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Where are hidusb and hidparse in the driver hiearchy in relation to mshidumdf and a hid minidriver?
Doron,
I hope you get this, I’m at my wits end with this project. Per one of your recommendations I’ve tried using the Toaster KMDF generic filter driver to communicate with my device. It looks ideal for what I want to do, but when I install it into the devices driver stack the user app can no longer find the device because it is no longer associated with the HIDClass setup class (at least that is what I think is happening). Can I simply change the Toaster filter INF file [Version] Class to HIDClass and ClassGUID to {system assigned GUID for HID collection} to correct this problem? And if I do, will I have to remove the [ClassInstall32] section and move the AddReg directive to the [DDInstall.HW] section?
Also, the Toaster generic filter INF file has an AddReg directive:
HKR,“UpperFiltes”,0x00010000,“ToasterFilter”
Should this be changed to “LowerFilters”?
I’m desperate to get over this hurdle.
Randy
—
NTDEV is sponsored by OSR
Visit the list online at: https:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:
To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:></mailto:xxxxx></mailto:xxxxx>
Doron,
In my INF device section I list both the HID\VID_xxxx and USB\VID_xxxx. I’m installing the driver to the HID component. I went ahead and changed the Class to HIDClass and ClassGUID to {HIDClass GUID} and “UpperFilters” to “LowerFilters” and left the [ClassInstaller32] section as it was. The driver installed without complaint or apparent ill effects and shows up under CCS\Control\Class{HIDClass GUID} as device key 010. However, my user app still can’t find the device. I ran my test app in debug mode and found that the call to Hid_GetHidGuid(HidGuid) returns the system defined GUID_DEVINTERFACE_HID Guid of {4D1E55B2-F16F-11CF-88CB-001111000030} and not the ClassGUID that my driver is listed under. How can I get my driver to be a member of the GUID_INTERFACE_HID?
Randy
Has the device successfully started after you installed your filter?
Sent from my Windows 10 phone
From: xxxxx@cox.netmailto:xxxxx
Sent: Saturday, February 27, 2016 12:58 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Where are hidusb and hidparse in the driver hiearchy in relation to mshidumdf and a hid minidriver?
Doron,
In my INF device section I list both the HID\VID_xxxx and USB\VID_xxxx. I’m installing the driver to the HID component. I went ahead and changed the Class to HIDClass and ClassGUID to {HIDClass GUID} and “UpperFilters” to “LowerFilters” and left the [ClassInstaller32] section as it was. The driver installed without complaint or apparent ill effects and shows up under CCS\Control\Class{HIDClass GUID} as device key 010. However, my user app still can’t find the device. I ran my test app in debug mode and found that the call to Hid_GetHidGuid(HidGuid) returns the system defined GUID_DEVINTERFACE_HID Guid of {4D1E55B2-F16F-11CF-88CB-001111000030} and not the ClassGUID that my driver is listed under. How can I get my driver to be a member of the GUID_INTERFACE_HID?
Randy
—
NTDEV is sponsored by OSR
Visit the list online at: https:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:
To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:></mailto:xxxxx></mailto:xxxxx>
Since I can’t yet communicate with it I don’t know. If I disconnect it the drivers uninstall, and if I then connect it again the drivers reinstall and show up in Device Manager and all looks well with both the HID and USB components shown as “This device is working properly”.
1 connect a kernel debugger and look
2 look in device manage, is it !ed out or not?
You know, the basics?.
Sent from my Windows 10 phone
From: xxxxx@cox.netmailto:xxxxx
Sent: Saturday, February 27, 2016 3:33 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Where are hidusb and hidparse in the driver hiearchy in relation to mshidumdf and a hid minidriver?
Since I can’t yet communicate with it I don’t know. If I disconnect it the drivers uninstall, and if I then connect it again the drivers reinstall and show up in Device Manager and all looks well with both the HID and USB components shown as “This device is working properly”.
—
NTDEV is sponsored by OSR
Visit the list online at: https:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:
To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:></mailto:xxxxx></mailto:xxxxx>
Up until now I’ve been developing in user mode and haven’t had a need to set up a target machine. I don’t even have a debugging cable to connect two machines together. Is there anything I can do in user mode to try and keep this project moving until I can get setup for kernel mode debugging? I hate to think I’ll lose a week waiting for a debugging cable to arrive (I doubt that the local BestBuy or Staples has one of these). And, no I don’t know the basics of debugging drivers, the vhidmini2 based driver I previously developed was my first endeavor at driver writing (not counting my attempts with the firefly sample before that, which failed with the same problem I’m having now with the Toaster filter model). It seems to me that if I can verify that the bare bones Toaster filter driver is getting installed in the correct stack location that it should just be a matter of setting up some commands in the filter and/or INF file to get the system to register it as a member of the GUID_DEVICEINTERFACE_HID collection so that my user app program will be able to recognize it. At that point I can at least experiment (blindly perhaps) and maybe getting it working through trial and error. I’ve tried setting up a DDInstall.Interfaces Section in the INF with the following:
;
; Add interfaces
;
[ToasterFilter.Interfaces]
AddIterface=%GUID_DEVICEINTERFACE_HID%, , ToasterFilter.Interface.Toaster
[ToasterFilter.Interface.Toaster]
AddReg=ToasterFilter.Interface.Toaster.AddReg
[ToasterFilter.Interface.Toaster.AddReg]
HKR,CLSID,%Proxy.CLSID%
[Strings]
Proxy.CLSID =“{745A17E0-74D3-11D0-B6FE-00A0C90F57DA}”
GUID_DEVICEINTERFACE_HID =“{4D1E55B2-F16F-11CF-88CB-001111000030}”
and also the following command in the filter:
WdfDeviceCreateDeviceInterface( device, (LPGUID)&GUID_DEVICEINTERFACE_HID, NULL);
but the system is still not adding the driver to that interface and the user app, therefore, still doesn’t recognize it.
Randy Lewis wrote:
Is there anything I can do in user mode to try and keep this
project moving until I can get setup for kernel mode debugging?
I hate to think I’ll lose a week waiting for a debugging cable to
arrive (I doubt that the local BestBuy or Staples has one of these).
How about researching if there are other ways to do kernel debugging without the cable that Best Buy doesn’t have?
You know, still the basics?
Doron,
I revisited the firefly sample driver that I had started with long ago, pulled the mouse stuff out of the INF file and changed a few other things and to my amazement, my device was recognized by the user app with the driver installed. In addition, the user app was able to send and receive I/O to and from the device. I then revised the toaster filter sample INF file to be similar to the modified firefly driver and that worked also. I set up the local computer for kernel mode debugging with the “bcdedit /debug on” and “bcdedit /dbgsettings local” commands, rebooted and opened up WinDbg in local Kernel debugging mode, issued the !dbgprint command and expected to receive DbgPrint and/or KdPrint output when my driver loaded and received IOCTL traffic. Alas, nothing was displayed. However, I then found that the program DebugView would now display these messages, when it didn’t before. I could then verify that the driver loads and IOCTL traffic does pass thru. I was disappointed that Read and Write were not among the traffic received by the filter driver and I hope that capturing these does not prove to be as frustrating as nearly everything else has been up to this point.
Thanks for your previous feedback, I’m sure I’m not done asking questions yet, but I think I’m moving forward again.
Randy
Doron,
I must be learning something, I got the EvtIoWrite and EvtIoRead handler functions working on the first try last night. This morning I added an EvtIoRead completion callback routine and got it working after an initial misstep and I can now intercept and modify requests going to the device and those being returned to the user app. This is getting to be fun again!
I would like to ask a question related to the vhidmini2 sample based virtual driver that I created previously. After much experimentation I concluded that the driver never receives user app ReadFile requests, even though it’s able to return responses to the user app. It appears that the framework periodically sends IOCTL_HID_READ_REPORT messages to the driver, regardless of whether the user app has issued a ReadFile request or even if the app is running. As long as the driver completes one of these framework requests, it appears that the framework will return it to the user app when a ReadFile request is sent. Is this correct and if so, how does the framework determine which completed IOCTL_HID_READ_REPORT should be returned for a given user app ReadFile request? This is a mystery to me.
Hidclass uses the report id in the buffer to dispatch the data to the right open app file object
Sent from my Windows 10 phone
From: xxxxx@gmail.commailto:xxxxx
Sent: Monday, February 29, 2016 6:27 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Where are hidusb and hidparse in the driver hiearchy in relation to mshidumdf and a hid minidriver?
Doron,
I must be learning something, I got the EvtIoWrite and EvtIoRead handler functions working on the first try last night. This morning I added an EvtIoRead completion callback routine and got it working after an initial misstep and I can now intercept and modify requests going to the device and those being returned to the user app. This is getting to be fun again!
I would like to ask a question related to the vhidmini2 sample based virtual driver that I created previously. After much experimentation I concluded that the driver never receives user app ReadFile requests, even though it’s able to return responses to the user app. It appears that the framework periodically sends IOCTL_HID_READ_REPORT messages to the driver, regardless of whether the user app has issued a ReadFile request or even if the app is running. As long as the driver completes one of these framework requests, it appears that the framework will return it to the user app when a ReadFile request is sent. Is this correct and if so, how does the framework determine which completed IOCTL_HID_READ_REPORT should be returned for a given user app ReadFile request? This is a mystery to me.
—
NTDEV is sponsored by OSR
Visit the list online at: https:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:
To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:></mailto:xxxxx></mailto:xxxxx>