Printer Driver hangs in installation on Vista

[DB]

I'm working on transferring a Kernel Mode printer driver to User Mode
driver. I have made changes to the driver according to the document provided
at http://www.unixwiz.net/techtips/win32-pdriver-ktou.html, but the Vista
system still thinks it's a Kernel mode driver.

Some documents suggested signing the driver's .cat file, which I did. But
that did not solve the hanging problem.

After many days of debugging and searching on the net, I tracked down the
point where I think the user privilege might be culprit. I tried to use the
UploadPrinterDriverPackage() and InstallPrinterDriverFromPackage().
Apparently, UploadPrinterDriverPackage() runs sucessfully, but the call to
InstallPrinterDriverFromPackage() would hang.

I'm developing this on Windows Vista Business, service pack 1. The whole
thing works fine on Windows XP.

Dave

[Christoph Lindemann]

I dont know if this helps, but I have had troubles before with this
when you have build your driver files checkout;

-the VS_FIXEDFILEINFO structure:
dwFileOS == VOS_NT_WINDOWS32
dwFileType == VFT_DRV
dwFileSubtype == VFT2_DRV_PRINTER or VFT2_DRV_VERSIONED_PRINTER
VER_FILEVERSION:
----------------------------------------------------------
First WORD | Ignore; Should be 0x0000
----------------------------------------------------------
Second WORD | 0x0003 = user-mode driver
| 0x0002 = kernel-mode driver
----------------------------------------------------------
Third WORD | 0x05 major feature set release / OS version
High byte |
----------------------------------------------------------
Low byte | 0x00 minor feature set release / OS version
----------------------------------------------------------
Fourth WORD | bug fix or service pack release / OS version
----------------------------------------------------------

-and more subtle, if the driver is compiled with some NT4 sdk the subsystem
specified in the PE Header was IMAGE_SUBSYSTEM_NATIVE,
so make sure the PE Header of you drivers for Win2K and later is
IMAGE_SUBSYSTEM_WINDOWS_GUI
IMAGE_NT_HEADERS->IMAGE_OPTIONAL_HEADER->Subsystem ==
IMAGE_SUBSYSTEM_WINDOWS_GUI

-Support "DrvQueryDriverInfo"

-Support correct version in "DrvEnableDriver"

-Support "DrvQueryDeviceSupport"

-build TARGETTYPE must be DYNLINK. Check that the files are linked against
umpdddi.lib and gdi32.lib

-Preprocessor macro USERMODE_DRIVER must be defined in source files before
winddi.h is included.

--
Christoph Lindemann
Undocumented Printing
http://www.undocprint.org/

"DB" <dbu...@newsgroup.nospam> wrote in message
news:umyZ442P...@TK2MSFTNGP04.phx.gbl...

[Dave Burns]

Thanks for your reply, Christoph.

I'm using Visual Stduio 8 to compile the driver project.

So the version string in VER_FILEVERSION should be something like 0,3,5,0?

Also, I don't see any mention of IMAGE_SUBSYSTEM_NATIVE in the code, is it
the 'Subsystem' in the 'Propperties' page? Under 'Link->system->subsytem', I
do see some choices like '/SUBSYSTEM:NATIVE' but I don't have a choice of
'/SUBSYSTEM:IMAGE_SUBSYSTEM_WINDOWS_GUI'. Am I looking at the wrong place?

In the driver, there is another version in the GDIINFO, ulVersion. What
version value should I set for Vista? I'm using 0x501 now, would that be ok?

> -Support "DrvQueryDriverInfo"

I have this one and it's exported in the .DEF file too. It returns TRUE when
querying with DRVQUERY_USERMODE.

> -Support correct version in "DrvEnableDriver"

I have this one and it's exported in the .DEF file too. It sets the
iDriverVersion of the DRVENABLEDATA to DDI_DRIVER_VERSION_NT5_01.

> -Support "DrvQueryDeviceSupport"

I did not have this function. Do I have to implement this and export it in
the ,DEF file? I just added a dummy implementaion now (just returning TRUE).

> -build TARGETTYPE must be DYNLINK. Check that the files are linked against

> umpdddi.lib and gdi32.lib

In Visual Studio 8, where do you specify TARGETTYPE = DYNLINK? I had it in
the 'Preprocessor Definitions' section.

> -Preprocessor macro USERMODE_DRIVER must be defined in source files before

> winddi.h is included.

I had that, it's in the 'Preprocessor Definitions' .

Regards, Dave

[Christoph Lindemann]

Hi Dave,

I strongly suggest to build the driver with the DDK, and not to use Visual
Studio for this. (You can of course use it as you editor) There are subtle
differences between the DDK include files and the VS/Platform include files.
I have had nothing than trouble building with VS (even thoug it is a >user
mode< printer driver), so I went back to build everything with the DDK.

Additional comments below:

> I'm using Visual Stduio 8 to compile the driver project.

I strongly suggest you use the DDK.

> So the version string in VER_FILEVERSION should be something like 0,3,5,0?

0x0000.0x0003.0x0500.0x0000
or
0x0000.0x0003.0x0501.0x0000

> Also, I don't see any mention of IMAGE_SUBSYSTEM_NATIVE in the code, is it
> the 'Subsystem' in the 'Propperties' page? Under 'Link->system->subsytem',
> I do see some choices like '/SUBSYSTEM:NATIVE' but I don't have a choice
> of '/SUBSYSTEM:IMAGE_SUBSYSTEM_WINDOWS_GUI'. Am I looking at the wrong
> place?

I dont know where to set it in VS. Check out the build DLL. Look in the PE
header.
When you build with the DDK, you should not need to set this.

> In the driver, there is another version in the GDIINFO, ulVersion. What
> version value should I set for Vista? I'm using 0x501 now, would that be
> ok?

it should be 0x0500 or 0x0501 depending on what system you want to support,
VER_FILEVERSION should be set to same.

>> -Support "DrvQueryDeviceSupport"
>
> I did not have this function. Do I have to implement this and export it in
> the ,DEF file? I just added a dummy implementaion now (just returning
> TRUE).

You don't have to according to DDK.

Remember DEVMODE.dmSpecVersion should be 0x0401 for Windows 2000 and later.
The same for DrvDeviceCapabilities DC_VERSION

[Dave Burns]

Thank you for your quick reply. I'm in process of making the WDK Build
utility to compile the driver, but I'm having the following problems.

error C2220: warning treated as error - no 'object' file generated

But my SOURCES file specifically removes the /Wx flag. Here is my SOURCES
file, could you see any problem with this file?

I copied this one from a friend of mine, but I don't see anything about the
VS_FIXEDFILEINFO or PE Header. Where should I specify those?

Any directions will be greatly appreciated.

Dave

# Printer Graphic Driver Source File

TARGETNAME=CCDXPVISTA

TARGETTYPE=DYNLINK

!IF 0

TARGETPATH=$(BASEDIR)\lib

!ENDIF

TARGETPATH=obj

INCLUDES=.;..\inc;..\..\..\inc;..\..\..\..\inc

C_DEFINES=$(C_DEFINES) -DSTRICT -DUNICODE -DUSERMODE_DRIVER -DEVE40 -DEVE30
-DEVE_WIDECARD -DUSE_OUTER_DLL -D_USE_RGBTRIPLE_

USE_MSVCRT=1

TARGETLIBS=$(SDK_LIB_PATH)\winspool.lib \

$(SDK_LIB_PATH)\user32.lib \

$(SDK_LIB_PATH)\gdi32.lib \

$(SDK_LIB_PATH)\advapi32.lib \

$(SDK_LIB_PATH)\umpdddi.lib \

USE_NOLIBS=1

###

### for DDK

###

DLLENTRY=DllMain

###

### for WDK

###

### need DllMain()

#DLLENTRY=_DllMainCRTStartup

NTPROFILEINPUT=yes

### !IFNDEF MSC_WARNING_LEVEL

### MSC_WARNING_LEVEL=/W2

### !ENDIF

MSC_WARNING_LEVEL=/W1

SOURCES= ccd2kxp.c \

ccd2kxpUtils.c \

RimageRes300UIDriver.c \

ccd2kxp.RC

#PRECOMPILED_INCLUDE=rimeveg.h

#PRECOMPILED_PCH=precomp.pch

#PRECOMPILED_OBJ=precomp.obj

[Dave Burns]

Finally got it compiled by correcting the code that caused the warnings, but
still don't know why it still thinks I'm "treating warning" as error.

At the end of the linking, I got the following error:

Linking Executable - objfre_wlh_x86\i386\ccdxpvista.dll
errors in directory c:\houyaocode\prismprinter\ccdvista
link : error LNK1104: cannot open file 'CCDXPVISTA.prf'
BUILD: Finish time: Wed Nov 12 11:25:26 2008
BUILD: Done

6 files compiled - 1 Warning
1 library built
1 executable built - 1 Error

What is a .PRF file? Any idea?

Regards, Dave.

[Tim Roberts]

"Dave Burns" <dbu...@newsgroup.nospam> wrote:
>
>Finally got it compiled by correcting the code that caused the warnings, but
>still don't know why it still thinks I'm "treating warning" as error.

The stock makefile automatically selects /WX unless you specifically
override it by setting
BUILD_ALLOW_COMPILER_WARNINGS=1

Howver, the path YOU took is the better one: fix the warnings.

>Linking Executable - objfre_wlh_x86\i386\ccdxpvista.dll
>errors in directory c:\houyaocode\prismprinter\ccdvista
>link : error LNK1104: cannot open file 'CCDXPVISTA.prf'
>BUILD: Finish time: Wed Nov 12 11:25:26 2008
>BUILD: Done
>
> 6 files compiled - 1 Warning
> 1 library built
> 1 executable built - 1 Error
>
>What is a .PRF file? Any idea?

Do you know that you have the full source for the makefile used by "build"
in the DDK in bin\makefile.new? The .PRF file is a profile input. Your
sources file includes
NTPROFILEINPUT=yes

That tells it to try to do profiling. That's the danger of working with a
"sources" file without understanding what the settings do.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Dave Burns]

Thank you, Tim and Christoph. I added the BUILD_ALLOW_COMPILER_WARNINGS
line, and the "warning as error" messages went away. I know I should fix the
problems, but it's nice to know why.

Now I can actually install the printer, but it would not print. I suspect
there might be something wrong in my .INF file:

[MyCompany]
%String_MODEL%=RIMCCD.Install,USBPRINT\VID_047E&PID_1001,Rimage_Perfect_Image_Printer_PF
;%String_MODEL%=RIMCCD.Install,USBPRINT\Rimage_Perfect_Image_Printer_PF

In my other driver (which I did not start), I actually have a 4-digit hex
number attached to Rimage_Perfect_Image_Printer_PF, like
Rimage_Perfect_Image_Printer_PF
XXXX, I believe it's the checksum of the string
"Rimage_Perfect_Image_Printer_PF". But I don't know how that checksum is
calculated. Any idea on how that number is calculated?

Another suspect is that the DrvConvertDevMode() is not returning TRUE. The
version conversion is quite confusing, our DRIVER_VERSION_INFO data is
defined like this:

static DRIVER_VERSION_INFO psDriverVersions = { //defined in plotlib.h/used
by devmode.c

// Current driver version number and private devmode size
DRIVER_VERSION, sizeof(CDDEVMODE)-sizeof(DEVMODE),

// 3.51 driver version number and private devmode size
DRIVER_VERSION_351, sizeof(CDDEVMODE)-sizeof(DEVMODE)-sizeof(BOOL),
};

Note that CCDSVMODE is our private DEVMODE.

Am I doing something wrong?

When I try to print, I can see from debugging messages that it's actually
calling some routines in my driver, but never prints anything out.

Any directions will be appreciated.

Dave

[Christoph Lindemann]

For the device id check:
http://msdn.microsoft.com/en-us/library/ms791081.aspx
and
http://msdn.microsoft.com/en-us/library/ms802216.aspx

Hey, why not read the complete "Installing and Configuring Printer Drivers"
section ;)
http://msdn.microsoft.com/en-us/library/ms802217.aspx

--
Christoph Lindemann
Undocumented Printing
http://www.undocprint.org/

"Dave Burns" <dbu...@newsgroup.nospam> wrote in message
news:Oreuq8bR...@TK2MSFTNGP03.phx.gbl...

[Dave Burns]

Thank you for your response. Now I'm able to install the printer
successfully (at least apparently), but I still can't print anything yet. I
can see the "Properties" pages and settings, but as soon as a document is
sent to printer, it says "printer error". From Windows event viewer, I can
see errors "Win32 error code returned by the print processor: 2. The system
cannot find the file specified.", or error 6 (The handle is invalid). But
the system does not give any more specific information about what "file" or
what "handle".

From the debug messages I put in the code, I can see it DrvEnablePDEV(), all
OK; then DrvDeviceCapabilities(), all seem to be fine. Then the DLL (the GDI
Graphic DLL) is unloaded. What are supposed to happen next? I thought the
will be called, but apparently it never did. Are there any specific values
of iDevCap of DrvDeviceCapabilities() that have to be processed for Vista?
Currently, I'm handling DC_PAPERS, DC_MINEXTENT, DC_MAXEXTENT, DC_PAPERSIZE,
DC_PAPERNAMES, DC_BINS, DC_BINNAMES, DC_FIELDS, DC_DUPLEX, DC_SIZE,
DC_EXTRA, DC_VERSION (returning 0x401), DC_DRIVER (returning 0x501),
DC_ENUMRESOLUTIONS, DC_FILEDEPENDENCIES, DC_TRUETYPE, DC_ORIENTATION and
DC_COPIES. Am I missing something for Vista?

Thanks, Dave

"Christoph Lindemann" <clind...@newsgroups.nospam> wrote in message
news:%23lBKGkJ...@TK2MSFTNGP06.phx.gbl...

[Christoph Lindemann]

Are you using the default print processor?

Are you opening any other obejcts (pipe, event, mutex, file, printer....)
from within you driver? And in the "open" request, are you requesting the
correct permissions? Watch out for requesting "full access", as the thread
token might not have permission for this. Only request the lowest needed
permissions. Vista removes lots of "default" permissions, so code that
worked on XP might not work any more.

You can try to use the sysinternals "Process Monitor" to monitor the system
for handle problems.

--
Christoph Lindemann
Undocumented Printing
http://www.undocprint.org/

"Dave Burns" <dbu...@newsgroup.nospam> wrote in message

news:%23lFQcJb...@TK2MSFTNGP03.phx.gbl...

[Dave Burns]

Our printer uses a USB to PARALLEL converter chip (PL2305 chip) to
communicate via USB with Windows. This chip is commonly used for a USB to
PARALLEL adapter cable for PCs that don't have a parallel port but have USB.
This chip has an external ROM that holds the descriptor information. We
currently send a device descriptor that uses the idVendor of 047E (hex) and
idProduct of 1001 (hex) which describes the vendor and product id of the
PL2305 chip. The iProduct field of the device descriptor identifies a
string that contains the name of our product (Prism Plus). There is no
serial number. The interfaceclass and interfacesubclass is declared a
printer in the interface descriptor sections of the configuration
descriptor chains.

When I plug the USB cable in, we can see the device manager recognizing the
device as "Prism Plus", then it searches INF files on the system and found
none matching. It should have found our driver because I have
%String_MODEL%=RIMCCD.Install_PnP.NT,USBPRINT\prism_plusDECE (see the INF
file below). Instead, it settles for the default "UnknownPrinter", and then
says "Your printer is ready for use" (of course, it is not). I can also use
"Add Printer" in control panel, it seems to add it "successfully", but when
I try to print, it says "Printer Error". I can guess it errors out because
the printer is not talking to the port USB1.

Here is our INF file. Some of the lines are from the older version of the
driver, and I'm not sure if they are absolutely needed. Anything wrong with
this INF file?

[Strings]

String_OEM="Rimage"

Class=%PTR_CLASS%

;;String_OEM="Rimage Corporation"

;;String_MODEL="Rimage Perfect Image Printer PF"

;;String_MODEL="Rm Perfect Image PF"

String_MODEL="Prism Plus"

String_DISK="Rimage Printer Disk"

PTR_CLASS="Printer"

[Version]

;;this driver does not support 9x/me versions of windows

Signature="$Windows NT$"

Class=Printer

ClassGUID={4D36E979-E325-11CE-BFC1-08002BE10318}

Provider=%String_OEM%

CatalogFile=ccdxpvista.cat

DriverVer=11/24/2008,5.3.0.96

[ClassInstall32.NT]

AddReg=printer_class_addreg

;;DelReg=printer_class_delreg

[ClassDelReg]

HKLM,"System\CurrentControlSet\Services\Class\Printer","NoUseClass"

[printer_class_addreg]

HKR,,,,%PrinterClassName%

HKR,,Installer32,,"ntprint.dll,ClassInstall32"

HKR,,Icon,,"-4"

HKR,,NoDisplayClass,,1

HKR,,EnumPropPages32,,"printui.dll,PrinterPropPageProvider"

[Manufacturer]

%String_OEM%=RIMAGE

[DestinationDirs]

DefaultDestDir=66000

RIMCCD_DRV=66000

[Environment]

AddReg=Environment_Reg

[Environment_Reg]

HKR,,LocationInformationOverride,,"Prism Plus"

[RIMAGE]

;;%String_MODEL%=RIMCCD.Install,USBPRINT\VID_047E&PID_1001,RM_Perfect_Image_PF0904

;;%String_MODEL%=RIMCCD.Install,LPTENUM\RM_Perfect_Image_PF

;;%String_MODEL%=RIMCCD.Install_PnP.NT,Rimage_Perfect_Image_Printer_PF

;;%String_MODEL%=RIMCCD.Install.NT,USBPRINT\rimage_perfect_imageAE00

%String_MODEL%=RIMCCD.Install_PnP.NT,USBPRINT\prism_plusDECE

;;

;; for NT

;;

;;[RIMCCD.Install.NT]

[RIMCCD.Install_PnP.NT]

DriverVer=11/24/2008,5.3.0.96

CopyFiles=RIMCCD_DRV

Include=NTPRINT.INF

DataSection=RIMCCD_DATA

DataFile=ccdxpvista.dll

[RIMCCD_DRV]

ccdxpvista.dll,,0x2008

ccdxpvistaui.dll,,0x2008

ccdxpvistaui.hlp,,0x2008

bcard58.bmp,,0x2008

bcard61.bmp,,0x2008

bcard63.bmp,,0x2008

mini80.bmp,,0x2008

rcard58.bmp,,0x2008

std120.bmp,,0x2008

[RIMCCD_DATA]

DriverFile=ccdxpvista.dll

ConfigFile=ccdxpvistaui.dll

[SourceDisksNames]

1=%String_DISK%,,,

[SourceDisksFiles]

ccdxpvista.dll=1

ccdxpvistaui.dll=1

ccdxpvistaui.hlp=1

bcard58.bmp=1

bcard61.bmp=1

bcard63.bmp=1

mini80.bmp=1

rcard58.bmp=1

std120.bmp=1

Regards, Dave

[Christoph Lindemann]

Could you dump the USB device descriptor and the IEEE 1284 ID?

"Dave Burns" <dbu...@newsgroup.nospam> wrote in message

news:OhvmwuxT...@TK2MSFTNGP02.phx.gbl...

[Dave Burns]

We would like to adapt our current printer driver to develop a PNP
compatible WHQL signed driver for use on Windows 2000, XP, Vista, Server
2003, Server 2008 for 32 and 64 bit versions but without changing the USB
descriptors in the hardware if possible. At device detection, the driver
installers would have to key off of "Prism Plus" in the iProduct string to
uniquely identify the product and instantiate the device. Multiple devices
must be able to instantiate then operate simultaneously while attached to
the same host computer.

Attached is the dump for the USB device descriptor.

Regards, Dave

[Dave Burns]

We would like to adapt our current printer driver to develop a PNP
compatible WHQL signed driver for use on Windows 2000, XP, Vista, Server
2003, Server 2008 for 32 and 64 bit versions but without changing the USB
descriptors in the hardware if possible. At device detection, the driver
installers would have to key off of "Prism Plus" in the iProduct string to
uniquely identify the product and instantiate the device. Multiple devices
must be able to instantiate then operate simultaneously while attached to
the same host computer.

Here is the dump for the USB device descriptor.

Regards, Dave

Device descriptor
Name Value Dec Hex Bin
bLength 18 18 0x12 10010
bDescriptorType DEVICE 1 0x01 1
bcdUSB 1 256 0x0100 1
bDeviceClass Class defined at interface level 0 0x00 0
bDeviceSubClass Subclass defined at interface level 0 0x00 0
bDeviceProtocol None 0 0x00 0
bMaxPacketSize0 8 8 0x08 1000
idVendor Agere Systems Inc. "1,150" 0x047E 100
idProduct USS720 Parallel Port "4,097" 0x1001 10000
bcdDevice 2.0.2 514 0x0202 10
iManufacturer 1 1 0x01 1
iProduct "2 ""Prism Plus""" 2 0x02 10
iSerialNumber 0 0 0x00 0
bNumConfigurations 1 1 0x01 1

Name Value Dec Hex Bin
bLength Valid 9 0x09 1001
bDescriptorType CONFIGURATION 2 0x02 10
wTotalLength 78 bytes 78 0x004E 0
bNumInterface 1 1 0x01 1
bConfigurationValue 1 1 0x01 1
iConfiguration 0 0 0x00 0
bmAttributes. Reserved Zero 0 0x00 0
bmAttributes. RemoteWakeup Not supported 0 0x0 0
bmAttributes. SelfPowered Yes 1 0x1 1
bmAttributes. Reserved7 Invalid 0 0x0 0
bMaxPower 100 mA 50 0x32 110010

Configuration descriptor
Name Value Dec Hex Bin
bLength Valid 9 0x09 1001
bDescriptorType CONFIGURATION 2 0x02 10
wTotalLength 78 bytes 78 0x004E 0
bNumInterface 1 1 0x01 1
bConfigurationValue 1 1 0x01 1
iConfiguration 0 0 0x00 0
bmAttributes. Reserved Zero 0 0x00 0
bmAttributes. RemoteWakeup Not supported 0 0x0 0
bmAttributes. SelfPowered Yes 1 0x1 1
bmAttributes. Reserved7 Invalid 0 0x0 0
bMaxPower 100 mA 50 0x32 110010

Interface descriptor
Name Value Dec Hex Bin
bLength Valid 9 0x09 1001
bDescriptorType INTERFACE 4 0x04 100
bInterfaceNumber 0 0 0x00 0
bAlternateSetting 0 0 0x00 0
bNumEndpoints 1 1 0x01 1
bInterfaceClass Printer 7 0x07 111
bInterfaceSubClass Printer 1 0x01 1
bInterfaceProtocol Unidirectional 1 0x01 1
iInterface 0 0 0x00 0

Endpoint descriptor
Name Value Dec Hex Bin
bLength Valid 7 0x07 111
bDescriptorType ENDPOINT 5 0x05 101
bEndpointAddress 1 OUT 1 0x01 1
bmAttributes. TransferType Bulk 2 0x2 10
bmAttributes. Reserved Zero 0 0x00 0
wMaxPacketSize 64 bytes 64 0x0040 0
bInterval Ignored for Bulk endpoints 0 0x00 0

Interface descriptor
Name Value Dec Hex Bin
bLength Valid 9 0x09 1001
bDescriptorType INTERFACE 4 0x04 100
bInterfaceNumber 0 0 0x00 0
bAlternateSetting 1 1 0x01 1
bNumEndpoints 2 2 0x02 10
bInterfaceClass Printer 7 0x07 111
bInterfaceSubClass Printer 1 0x01 1
bInterfaceProtocol Bidirectional 2 0x02 10
iInterface 0 0 0x00 0

Endpoint descriptor
Name Value Dec Hex Bin
bLength Valid 7 0x07 111
bDescriptorType ENDPOINT 5 0x05 101
bEndpointAddress 1 OUT 1 0x01 1
bmAttributes. TransferType Bulk 2 0x2 10
bmAttributes. Reserved Zero 0 0x00 0
wMaxPacketSize 64 bytes 64 0x0040 0
bInterval Ignored for Bulk endpoints 0 0x00 0

Endpoint descriptor
Name Value Dec Hex Bin
bLength Valid 7 0x07 111
bDescriptorType ENDPOINT 5 0x05 101
bEndpointAddress 2 IN 130 0x82 10000010
bmAttributes. TransferType Bulk 2 0x2 10
bmAttributes. Reserved Zero 0 0x00 0
wMaxPacketSize 64 bytes 64 0x0040 0
bInterval Ignored for Bulk endpoints 0 0x00 0

Interface descriptor
Name Value Dec Hex Bin
bLength Valid 9 0x09 1001
bDescriptorType INTERFACE 4 0x04 100
bInterfaceNumber 0 0 0x00 0
bAlternateSetting 2 2 0x02 10
bNumEndpoints 3 3 0x03 11
bInterfaceClass Vendor-specific 255 0xFF 11111111
bInterfaceSubClass Vendor-specific 0 0x00 0
bInterfaceProtocol Vendor-specific 255 0xFF 11111111
iInterface 0 0 0x00 0

Endpoint descriptor
Name Value Dec Hex Bin
bLength Valid 7 0x07 111
bDescriptorType ENDPOINT 5 0x05 101
bEndpointAddress 1 OUT 1 0x01 1
bmAttributes. TransferType Bulk 2 0x2 10
bmAttributes. Reserved Zero 0 0x00 0
wMaxPacketSize 64 bytes 64 0x0040 0
bInterval Ignored for Bulk endpoints 0 0x00 0

Endpoint descriptor
Name Value Dec Hex Bin
bLength Valid 7 0x07 111
bDescriptorType ENDPOINT 5 0x05 101
bEndpointAddress 2 IN 130 0x82 10000010
bmAttributes. TransferType Bulk 2 0x2 10
bmAttributes. Reserved Zero 0 0x00 0
wMaxPacketSize 64 bytes 64 0x0040 0
1000000
bInterval Ignored for Bulk endpoints 0 0x00 0

Endpoint descriptor
Name Value Dec Hex Bin
bLength Valid 7 0x07 111
bDescriptorType ENDPOINT 5 0x05 101
bEndpointAddress 3 IN 131 0x83 10000011
bmAttributes. TransferType Interrupt 3 0x3 11
bmAttributes. Reserved Zero 0 0x00 0
wMaxPacketSize 4 bytes 4 0x0004 0
bInterval 1 frame (1 ms) 1 0x01 1

String descriptor
Name Value Dec Hex Bin
bLength 4 4 0x04 100
bDescriptorType STRING 3 0x03 11
wLANGID[0] English (US) "1,033" 0x0409 100
1001

String descriptor
Name Value Dec Hex Bin
bLength 22 22 0x16 10110
bDescriptorType STRING 3 0x03 11
Content """Prism Plus"""

[Tim Roberts]

Your iManufacturer string descriptor appears to be empty. Is that right?

You've double-checked the checksum (DECE)?

Does the registry key for the devnode that gets created have any clues?

[Christoph Lindemann]

Does your printer support the class specific GET_DEVICE_ID request. This
will return the IEEE 1284 Device ID, which windows uses to build the
hardware ID for USB (actually any IEEE 1284 compatible device) print
devices. (The USS-720 chip forwards this request to the connected IEEE 1284
device, if your device does not return this, it will return a 0 length ID)
Checkout "Universal Serial Bus Device Class Definition for Printing Devices
1.1" section "4.2.1 GET_DEVICE_ID"

You should provide a serial number when you want to run several devices
concurrently on 1 machine.

I also suggest that you provide your own values for idVendor, idProduct,
iManufacturer, iProduct... to prevent clashing with other pruducts that are
using the USS720.

--
Christoph Lindemann
Undocumented Printing
http://www.undocprint.org/

"Dave Burns" <dbu...@newsgroup.nospam> wrote in message

news:uLVyu8AU...@TK2MSFTNGP02.phx.gbl...

[Dave Burns]

We are using the Prolific PL-2305H USB to IEEE1284 Bridge ASIC to tie a
unidirectional parallel port printer to USB. The installed base of printers
currently cannot return the IEEE 1284 Device ID to the PL-2305H so the
PL-2305H will return a 0 length response to the GET_DEVICE_ID request. The
PL-2305H loads the USB descriptors from a table in EEPROM which currently is
set up so the PL-2305H appears as a USS-720 to the host.

I can change the descriptors in the EEPROM and I could implement
serialization in the EEPROM but it will take a hardware change to implement
IEEE 1284 nibble mode or other reverse channel to allow the IEEE 1284 Device
ID to be returned. I'm hoping to avoid this change if possible. Is there any
way to implement a WHQL signed and Vista / WIN7 compliant printer driver
based solely on the USB descriptors and without an IEEE 1284 reverse channel
communications path?

Thanks, Dave