kmdf USB filter driver, AddDevice never called?

OSR_Community_User · July 16, 2010, 7:31pm

Hi all,

I wrote a filter driver meant to be loaded for a specific device on the USB bus. I first thought of having it installed as an upper filter driver for the usbhub system driver. The idea is to be able to intercept the IOCTL_INTERNAL_USB_SUBMIT_URB and possibly modify the values in a completion routine.

Right now I have problems installing the driver. I’m testing it on a XP system and I can see that the inf file puts the apparently right information in the registry: under …\USB\Enum.… the entry seems to have everything in place with my driver set as UpperFilter. I can also see the log trace from the DriverEntry but then no AddDevice gets called.

Just for more information, the device I’m trying to handle is a HID device, so my inf has an include=input.inf and a needs=HID_Inst.NT.Services in the Services section. That seems to work correctly since the device works fine. Simply my driver seems not to be placed in the right place in the stack.

I remember doing something like that in the past for testing purposes with a WDM driver and just adding the UpperFilter key in the registry for the right entry worked fine. I wonder if my problem has to do with the additional setup stage required by the WDF.

Could anybody point me in the right direction?

Thank you so much in advance,
Marco.

PS: even if the device is a HID device I need to be able to access it at USB level since I need to be able so send down some device requests. So writing a HID filter driver was not possible in this case.

Doron_Holan · July 16, 2010, 9:47pm

Post your inf. If you want to filter urbs then you need to be a lower filter below hidusb, not an upper filter of usbhub.

d

dent from a phpne with no keynoard

-----Original Message-----
From: xxxxx@laurenzano.it
Sent: July 16, 2010 4:31 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] kmdf USB filter driver, AddDevice never called?

Hi all,

I wrote a filter driver meant to be loaded for a specific device on the USB bus. I first thought of having it installed as an upper filter driver for the usbhub system driver. The idea is to be able to intercept the IOCTL_INTERNAL_USB_SUBMIT_URB and possibly modify the values in a completion routine.

Right now I have problems installing the driver. I’m testing it on a XP system and I can see that the inf file puts the apparently right information in the registry: under …\USB\Enum.… the entry seems to have everything in place with my driver set as UpperFilter. I can also see the log trace from the DriverEntry but then no AddDevice gets called.

Just for more information, the device I’m trying to handle is a HID device, so my inf has an include=input.inf and a needs=HID_Inst.NT.Services in the Services section. That seems to work correctly since the device works fine. Simply my driver seems not to be placed in the right place in the stack.

I remember doing something like that in the past for testing purposes with a WDM driver and just adding the UpperFilter key in the registry for the right entry worked fine. I wonder if my problem has to do with the additional setup stage required by the WDF.

Could anybody point me in the right direction?

Thank you so much in advance,
Marco.

PS: even if the device is a HID device I need to be able to access it at USB level since I need to be able so send down some device requests. So writing a HID filter driver was not possible in this case.

—
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

OSR_Community_User · July 17, 2010, 11:57am

Hi Doron,

first I want to thank you. I’ve been following this forum for some time now and I’ve got really valuable help from you and others and never stopped to thank you.

At the bottom of this post you’ll find my current inf file. Actually this one is the first one I tried and it’s the one that still makes the most sense to me. To be honest I have some experience in writing drivers for the HID stack but I never attempted anything like this and some things are probably not really clear in my mind. One for example is, you said that I should write a lower filter for hidusb and not an upperfilter for ubshub if I want to see the URBs. I can see the reason in this specific case but in general, for a generic USB device, wouldn’t an upperfilter of usbhub a more general approach?

Thanks,
Marco.

; INF file
[Version]
Signature=“$Windows NT$”
Provider=%Company%
ClassGUID={745A17A0-74D3-11D0-B6FE-00A0C90F57DA}
Class=HIDClass
CatalogFile=cntmou.cat
LayoutFile=layout.inf
DriverPackageType=PlugAndPlay

DriverVer=07/17/2010,2.0.0.0

[DestinationDirs]
DefaultDestDir = 12

;
; Driver information
;

[Manufacturer]
%Company% = Company.Mfg,NTx86

; For Win2K
[Company.Mfg]
%USB\Vid_feed&Pid_beef.DeviceDesc%=cntmou_Inst, USB\Vid_feed&Pid_beef

; For XP and above
[Company.Mfg.NTx86]
%USB\Vid_feed&Pid_beef.DeviceDesc%=cntmou_Inst, USB\Vid_feed&Pid_beef

;
; General installation section
;

[cntmou_Inst.NT]
; Copy the driver over
CopyFiles=cntmou_Inst.CopyFiles

;
; File sections
;

[cntmou_Inst.CopyFiles]
cntmou.sys

;
; Service Installation
;

[cntmou_Inst.NT.Services]
AddService = cntmou,2,cntmou_Service_Inst
Include=input.inf
Needs=HID_Inst.NT.Services

[cntmou_Service_Inst]
DisplayName = %cntmou.SvcDesc%
ServiceType = 1 ; SERVICE_KERNEL_DRIVER
StartType = 3 ; SERVICE_DEMAND_START
ErrorControl = 1 ; SERVICE_ERROR_IGNORE
ServiceBinary = %12%\cntmou.sys

[cntmou_Inst.NT.HW]
; Add the device filter
AddReg = cntmou_Inst.HW.AddReg

[cntmou_Inst.HW.AddReg]
HKR,“LowerFilters”,0x00010000,“cntmou”

;
; Source file information
;

[SourceDisksNames]
1 = %DiskId1%,

[SourceDisksFiles]
cntmou.sys = 1,

;
;— cntmou Coinstaller installation ------
;

[DestinationDirs]
cntmou_CoInstaller_CopyFiles = 11

[cntmou_Inst.NT.CoInstallers]
AddReg=cntmou_CoInstaller_AddReg
CopyFiles=cntmou_CoInstaller_CopyFiles

[cntmou_CoInstaller_AddReg]
HKR,CoInstallers32,0x00010000, “WdfCoInstaller01009.dll,WdfCoInstaller”

[cntmou_CoInstaller_CopyFiles]
WdfCoInstaller01009.dll

[SourceDisksFiles]
WdfCoInstaller01009.dll=1 ; make sure the number matches with SourceDisksNames

[cntmou_Inst.NT.Wdf]
KmdfService = cntmou, cntmou_wdfsect

[cntmou_wdfsect]
KmdfLibraryVersion = 1.9

[Strings]

;
; Non-Localizable Strings
;

REG_SZ = 0x00000000
REG_MULTI_SZ = 0x00010000
REG_EXPAND_SZ = 0x00020000
REG_BINARY = 0x00000001
REG_DWORD = 0x00010001
SERVICEROOT = “System\CurrentControlSet\Services”

;
; Localizable Strings
;

DiskId1 = “Test installation disk”
Company = “My Company”
cntmou.SvcDesc = “Test driver”
USB\Vid_feed&Pid_beef.DeviceDesc = “My test HID device”

OSR_Community_User · July 17, 2010, 5:55pm

Just an update.

With the inf file posted above I have been actually able to load the driver. Thank you for the hint.

I have now a different problem: in the prepare hardware callback I create successfully a USB target object. The first thing I try to do is to get device descriptor.
The interesting thing is that apparently, with the wdf verifier on, the WdfUsbTargetDeviceGetDeviceDescriptor breaks into the debugger and I can see that the numbers returned in the device descriptor buffer make really no sense. If I attempt a second get descriptor, it return garbage but different numbers.

My first thought was to get the device descriptor in the prepare hardware right after the create of the USB target. I also tried to do it later in the code after the device has been certainly initialized (the device works) but still no luck.

Is there anything that I may be forgetting that can cause this problem?

Thanks a lot
Marco

Doron_Holan · July 17, 2010, 6:31pm

Post your code.

d

dent from a phpne with no keynoard

-----Original Message-----
From: xxxxx@laurenzano.it
Sent: July 17, 2010 2:55 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] kmdf USB filter driver, AddDevice never called?

Just an update.

With the inf file posted above I have been actually able to load the driver. Thank you for the hint.

I have now a different problem: in the prepare hardware callback I create successfully a USB target object. The first thing I try to do is to get device descriptor.
The interesting thing is that apparently, with the wdf verifier on, the WdfUsbTargetDeviceGetDeviceDescriptor breaks into the debugger and I can see that the numbers returned in the device descriptor buffer make really no sense. If I attempt a second get descriptor, it return garbage but different numbers.

My first thought was to get the device descriptor in the prepare hardware right after the create of the USB target. I also tried to do it later in the code after the device has been certainly initialized (the device works) but still no luck.

Is there anything that I may be forgetting that can cause this problem?

Thanks a lot
Marco

—
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

OSR_Community_User · July 17, 2010, 6:44pm

Hi,

here are the parts that deal with the USB (at least for now).

Thanks!

NTSTATUS EvtPrepareHardware(WDFDEVICE hDevice, WDFCMRESLIST Resources, WDFCMRESLIST ResourcesTranslated)
{
PDEVICE_EXTENSION filterExt;
NTSTATUS status = STATUS_SUCCESS;

PAGED_CODE();

DebugPrint((“CNTMOU EvtPrepareHardware\n”));

filterExt = FilterGetData(hDevice);

// Create the USB framework object to send URBs down when is needed.
if(filterExt->UsbDevice == NULL)
{
WDF_USB_DEVICE_SELECT_CONFIG_PARAMS configParams;

DebugPrint((“CNTMOU Creating USB Target object\n”));
status = WdfUsbTargetDeviceCreate(hDevice, WDF_NO_OBJECT_ATTRIBUTES, &filterExt->UsbDevice);
if(!NT_SUCCESS(status))
{
DebugPrint((“WdfUsbTargetDeviceCreate failed 0x%x\n”, status));
return status;
}
}

if(filterExt->UsbDevice != NULL)
{
NTSTATUS status;

status = filterGetDeviceType(filterExt->UsbDevice, &filterExt->deviceType);
if(!NT_SUCCESS(status))
{
DebugPrint((“CNTMOU GetDeviceType failed 0x%x\n”, status));
}

if(filterIsTimerRequired(filterExt->deviceType))
{
status = WdfTimerStart(filterExt->TimerHandle, WDF_REL_TIMEOUT_IN_MS(ENDDETECTIONHACK_TIMER_MS));
if(!NT_SUCCESS(status))
{
DebugPrint((“CNTMOU WdfTimerStart failed 0x%x\n”, status));
}
}
}

return status;
}

NTSTATUS filterGetDeviceType(WDFUSBDEVICE usbDevice, CNTMOU_TYPE *deviceType)
{
NTSTATUS status;
USHORT vid, pid, revision, numchars;
USHORT manufacturer[64];

RtlZeroMemory(manufacturer, sizeof(manufacturer));

*deviceType = CONTOURMOUSE_TYPE_UNKNOWN;

if((status = usbGetDeviceDescriptor(usbDevice, &vid, &pid, &revision, manufacturer, &numchars)) == STATUS_SUCCESS)
{
if(vid == 0xfeed)
{
switch(pid)
{
case 0xbeef:
if(revision == 0x0202)
{
*deviceType = TYPE_1;
status = STATUS_SUCCESS;
}
else
{
*deviceType = TYPE_0;
status = STATUS_SUCCESS;
}
break;

}
}
}

return status;
}

NTSTATUS usbGetDeviceDescriptor(WDFUSBDEVICE usbDevice, USHORT *vid, USHORT *pid, USHORT *revision, USHORT *manufacturer, USHORT *numchars)
{
USB_DEVICE_DESCRIPTOR descriptor;

WdfUsbTargetDeviceGetDeviceDescriptor(usbDevice, &descriptor);

descriptor.idVendor = *vid;
descriptor.idProduct = *pid;
descriptor.bcdDevice = *revision;

DebugPrint((“CNTMOU Device Type: VID%x PID%x REV%x iMN%x\n”, descriptor.idVendor, descriptor.idProduct, descriptor.bcdDevice, descriptor.iManufacturer));

return WdfUsbTargetDeviceQueryString(usbDevice, NULL, NULL, manufacturer, numchars, descriptor.iManufacturer, 0x0409);
}

OSR_Community_User · July 17, 2010, 7:48pm

Nevermind. It was an obvious C mistake. Typical when you code at 2am for days in a row.

Thank you for your help!
M.

Gary_Little-3 · July 17, 2010, 8:01pm

… It’s called sleep. Amazing what it can do for you.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@laurenzano.it
Sent: Saturday, July 17, 2010 6:47 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] kmdf USB filter driver, AddDevice never called?

Nevermind. It was an obvious C mistake. Typical when you code at 2am for
days in a row.

Thank you for your help!
M.

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