I’m writing a filter driver that makes any USB printer connected to the computer looking like my own fictional printer. Everything works fine with simple USB printers. The problem is that I have to support the composite devices too. Is it possible to customize the enumeration of USB composite printer with multiple interfaces so that it seems to the OS like simple printer (one USB Printing Support device)? I’m working with XP SP3.
I’m writing a filter driver that makes any USB printer connected to the computer looking like my own fictional printer. Everything works fine with simple USB printers. The problem is that I have to support the composite devices too. Is it possible to customize the enumeration of USB composite printer with multiple interfaces so that it seems to the OS like simple printer (one USB Printing Support device)?
No, of course that won’t work. However, it shouldn’t be necessary.
When a printer is a composite device, it’s usually because they have one
interface for a scanner, one for a printer, and maybe one for a built-in
CD player. In that case, the “generic composite parent” driver,
usbccgp.sys, splits up the interfaces and makes three separate device
objects, each of which thinks it is running a single interface device.
That’s what the &MI_00 and &MI_01 designations are in device IDs.
You just need to make sure you are filtering the USB printer class
interface, not the composite interface. How have you installed your filter?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
All I need to support for the printer device is its printing functionality. The problem of devices enumerated by generic parent driver is that the device name differs from simple USB printers (USB\VID_xxxx&PID_yyyy&MI_xx vs. USB\VID_xxxx&PID_yyyy\sernum).
My idea was not to use usbccgp and enumerate the composite device inside the filter driver - filter out all non-printer interfaces so that even the composite device seems to be simple USB printer.
Currently the filter is attached to all usb hub (USB\ROOT_HUB and USB\Class_09) device stacks. Iniside IRP_MN_QUERY_DEVICE_RELATIONS completion routine new FDO is created for each printer device and IRP_MN_QUERY_ID and IRP_MN_QUERY_DEVICE_TEXT responses are changed so that each printer seems to be my own fictional printer device.
So you will have to also filter devices enumerated by usbccgp.
Mark Roddy
On Thu, Aug 26, 2010 at 3:16 AM, wrote:
> Thanks for your response. > > All I need to support for the printer device is its printing functionality. > The problem of devices enumerated by generic parent driver is that the > device name differs from simple USB printers (USB\VID_xxxx&PID_yyyy&MI_xx > vs. USB\VID_xxxx&PID_yyyy\sernum). > > My idea was not to use usbccgp and enumerate the composite device inside > the filter driver - filter out all non-printer interfaces so that even the > composite device seems to be simple USB printer. > > Currently the filter is attached to all usb hub (USB\ROOT_HUB and > USB\Class_09) device stacks. Iniside IRP_MN_QUERY_DEVICE_RELATIONS > completion routine new FDO is created for each printer device and > IRP_MN_QUERY_ID and IRP_MN_QUERY_DEVICE_TEXT responses are changed so that > each printer seems to be my own fictional printer device. > > — > 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 >
All I need to support for the printer device is its printing functionality. The problem of devices enumerated by generic parent driver is that the device name differs from simple USB printers (USB\VID_xxxx&PID_yyyy&MI_xx vs. USB\VID_xxxx&PID_yyyy\sernum).
Why does that matter? Sooner or later, it creates an ID that maps to
print class.
Currently the filter is attached to all usb hub (USB\ROOT_HUB and USB\Class_09) device stacks. Iniside IRP_MN_QUERY_DEVICE_RELATIONS completion routine new FDO is created for each printer device and IRP_MN_QUERY_ID and IRP_MN_QUERY_DEVICE_TEXT responses are changed so that each printer seems to be my own fictional printer device.
At the risk of diverting ourselves down a rathole, what’s the point of
this? How could this possibly be useful?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
We have a system running on XP embedded that should support given set of printers. The user works with that system with restricted rights. The point is to avoid “Found new hardware” messages. We would like to install drivers for supported printers all mapped to the same port (e.g. usb001) and a driver for fictional printer mapped to usb001 moreover we will prepare the registry entries needed for mapping of the fictional printer to the correct port:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses{28d78fad-5a12-11d1-ae5b-0000f803a8c2}##?#USB#Vid_xxxx&Pid_xxxx#sernum#{28d78fad-5a12-11d1-ae5b-0000f803a8c2}#\Device Parameters\Port Number
The hw is identified by the Vid, Pid and serial number. The point is that if all printers seems to be the same one “Found new hardware” messages are completely suppressed.
Problem is that devices reported by usbccgp are identified by Vid, Pid and MI_xx so that more devices entries must be in registry and if more than one devices are mapped to the same port the system does not allow to print.
The customer wants to use this solution and moreover it seams that Driver Store is supported since Windows Vista.
Could someone tell me how to enumerate only specific interface of USB composite device or how to customize - rename - the devices enumerated by generic parent driver on Windows XP?
The point is to avoid “Found new hardware” messages. We
would like to install drivers for supported printers all mapped
to the same port (e.g. usb001) and a driver for fictional printer
mapped to usb001 moreover we will prepare the registry entries
needed for mapping of the fictional printer to the correct port:
Oh, okay. So what you really want is help with compromising security, bypassing WHQL, and sabotaging people’s registries. Well, I don’t think you are going to get much help with that here.
The customer wants to use this solution and moreover it seams that Driver Store is supported since Windows Vista.
Wrong. DPInst on Windows XP puts the files into
\Windows\System32\DRVSTORE, and then adds that to the list of places to
search automatically. It works exactly like the DriverStore on Vista
and beyond.
Could someone tell me how to enumerate only specific interface of USB composite device or how to customize - rename - the devices enumerated by generic parent driver on Windows XP?
You are simply trying to solve this problem in the wrong way. You are
signing yourself up for pain and suffering, and an endless support
burden. What happens when you get a printer six months from now that
includes a hub inside with some even more complicated setup?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
wrote in message news:xxxxx@ntdev… > The customer wants to use this solution and moreover it seams that Driver > Store is supported since Windows Vista. > > Could someone tell me how to enumerate only specific interface of USB > composite device or how to customize - rename - the devices enumerated by > generic parent driver on Windows XP? >
Maybe you want to look for a “virtualized” solution like ThinPrint, where all client machines see the same virtual printer device, which is later materialized by print server(s). You can fully control the setup of the virtual printers.