Compiling USB UMDF driver for Vista 64-bit

NTDEV
1

Hi,
I’m trying to compile my driver for a 64-bit system.
It compiles and works fine when installed on a Dual Core system (Intel Core™2 CPU) with Vista Ultimate, 32-bit Operating System, compiled with WDK 6000 UMDF 1.5, Vista x86 Checked environment.
I have a system with a similar configuration, besides the fact that it is a 64-bit Operating System.
Installing the driver compiled with x86 env fails, and so does installing a driver compiled with Longhorn IA-64 checked. I assume that the AMD env is only for AMD processors, and therefore irrelevant.
The message I get in the properties section of the Device Manager is “the device is not configured correctly (code 1)”.
How can I compile it correctly? Or are there changes in the inf file I need to do in order for it to be installed correctly?
Attached below is my inf for 32-bit systems (the one that works).
Thanks,
Gadi

;
; WUDFOsrUsbFx2.inf - Install the OSR USB user-mode driver
;

[Version]
Signature=“$Windows NT$”
Class=HIDClass
;ClassGuid={78A1C341-4539-11d3-B88D-00C04FAD5171}
Provider=%MSFTUMDF%
DriverVer=25/04/2007,1.0.0000.00009
CatalogFile=wudf.cat

[Manufacturer]
%MSFTUMDF%=Microsoft,NTx86

[Microsoft.NTx86]
%OsrUsbDeviceName%=OsrUsb_Install, USB\Vid_1b96&Pid_0001&mi_02

[ClassInstall32]
AddReg=SampleClass_RegistryAdd

[SampleClass_RegistryAdd]
HKR,%ClassName%
HKR,Icon,“-24”

[SourceDisksFiles]
WUDFOsrUsbFx2.dll=1
WudfUpdate_01005.dll=1
WdfCoInstaller01005.dll=1
WinUsbCoinstaller.dll = 1

[SourceDisksNames]
1 = %MediaDescription%

; =================== UMDF OsrUsb Device ==================================

[OsrUsb_Install.NT]
CopyFiles=UMDriverCopy
Include=WINUSB.INF ; Import sections from WINUSB.INF
Needs=WINUSB.NT ; Run the CopyFiles & AddReg directives for WinUsb.INF

[OsrUsb_Install.NT.hw]
AddReg=OsrUsb_Device_AddReg

[OsrUsb_Install.NT.Services]
AddService=WUDFRd,0x000001fa,WUDFRD_ServiceInstall ; flag 0x2 sets this as the service for the device
AddService=WinUsb,0x000001f8,WinUsb_ServiceInstall ; this service is installed because its a filter.

[OsrUsb_Install.NT.Wdf]
KmdfService=WINUSB, WinUsb_Install
UmdfDispatcher=WinUsb
UmdfService=WUDFOsrUsbFx2, WUDFOsrUsbFx2_Install
UmdfServiceOrder=WUDFOsrUsbFx2

[OsrUsb_Install.NT.CoInstallers]
AddReg=CoInstallers_AddReg
CopyFiles=CoInstallers_CopyFiles

[WinUsb_Install]
KmdfLibraryVersion = 1.0

[WUDFOsrUsbFx2_Install]
UmdfLibraryVersion=1.5.0
;DriverCLSID=“{7bf5cb94-b686-4721-955e-878e48933a2c}”
DriverCLSID=“{DACA6A6E-CB6F-4851-BAFE-8F75013F66C8}”
ServiceBinary = “%12%\UMDF\WUDFOsrUsbFx2.dll”

[OsrUsb_Device_AddReg]
HKR,“LowerFilters”,0x00010008,“WinUsb” ; FLG_ADDREG_TYPE_MULTI_SZ | FLG_ADDREG_APPEND

[WUDFRD_ServiceInstall]
DisplayName = %WudfRdDisplayName%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %12%\WUDFRd.sys
LoadOrderGroup = Base

[WinUsb_ServiceInstall]
DisplayName = %WinUsb_SvcDesc%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %12%\WinUSB.sys

[CoInstallers_AddReg]
HKR,CoInstallers32,0x00010000,“WudfUpdate_01005.dll”, “WdfCoInstaller01005.dll,WdfCoInstaller”, “WinUsbCoInstaller.dll”

[CoInstallers_CopyFiles]
WudfUpdate_01005.dll
WdfCoInstaller01005.dll
WinUsbCoinstaller.dll

[DestinationDirs]
UMDriverCopy=12,UMDF ; copy to driversMdf
CoInstallers_CopyFiles=11

[UMDriverCopy]
WUDFOsrUsbFx2.dll

; =================== Generic ==================================

[Strings]
MSFTUMDF=“N-trig Innovative Technologies”
MediaDescription=“N-trig HID Tablet Digitizer - USB Driver Installation Media”
;ClassName=“N-trig”
WudfRdDisplayName=“Windows Driver Foundation - User-mode Driver Framework Reflector”
OsrUsbDeviceName=“N-Trig HID Tablet Digitizer”
WinUsb_SvcDesc=“WinUSB Driver”

2

No, AMD64 is the 64 bit OS for AMD and Intels EMT64 (a clone of AMD)
processors. You need to build for AMD.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> Hi,
> I’m trying to compile my driver for a 64-bit system.
> It compiles and works fine when installed on a Dual Core system (Intel
> Core™2 CPU) with Vista Ultimate, 32-bit Operating System, compiled
> with WDK 6000 UMDF 1.5, Vista x86 Checked environment.
> I have a system with a similar configuration, besides the fact that it is
> a 64-bit Operating System.
> Installing the driver compiled with x86 env fails, and so does installing
> a driver compiled with Longhorn IA-64 checked. I assume that the AMD env
> is only for AMD processors, and therefore irrelevant.
> The message I get in the properties section of the Device Manager is “the
> device is not configured correctly (code 1)”.
> How can I compile it correctly? Or are there changes in the inf file I
> need to do in order for it to be installed correctly?
> Attached below is my inf for 32-bit systems (the one that works).
> Thanks,
> Gadi
>
> ;
> ; WUDFOsrUsbFx2.inf - Install the OSR USB user-mode driver
> ;
>
> [Version]
> Signature=“$Windows NT$”
> Class=HIDClass
> ;ClassGuid={78A1C341-4539-11d3-B88D-00C04FAD5171}
> Provider=%MSFTUMDF%
> DriverVer=25/04/2007,1.0.0000.00009
> CatalogFile=wudf.cat
>
> [Manufacturer]
> %MSFTUMDF%=Microsoft,NTx86
>
> [Microsoft.NTx86]
> %OsrUsbDeviceName%=OsrUsb_Install, USB\Vid_1b96&Pid_0001&mi_02
>
> [ClassInstall32]
> AddReg=SampleClass_RegistryAdd
>
> [SampleClass_RegistryAdd]
> HKR,%ClassName%
> HKR,Icon,“-24”
>
> [SourceDisksFiles]
> WUDFOsrUsbFx2.dll=1
> WudfUpdate_01005.dll=1
> WdfCoInstaller01005.dll=1
> WinUsbCoinstaller.dll = 1
>
> [SourceDisksNames]
> 1 = %MediaDescription%
>
> ; =================== UMDF OsrUsb Device
> ==================================
>
> [OsrUsb_Install.NT]
> CopyFiles=UMDriverCopy
> Include=WINUSB.INF ; Import sections from WINUSB.INF
> Needs=WINUSB.NT ; Run the CopyFiles & AddReg
> directives for WinUsb.INF
>
> [OsrUsb_Install.NT.hw]
> AddReg=OsrUsb_Device_AddReg
>
> [OsrUsb_Install.NT.Services]
> AddService=WUDFRd,0x000001fa,WUDFRD_ServiceInstall ; flag 0x2 sets this
> as the service for the device
> AddService=WinUsb,0x000001f8,WinUsb_ServiceInstall ; this service is
> installed because its a filter.
>
> [OsrUsb_Install.NT.Wdf]
> KmdfService=WINUSB, WinUsb_Install
> UmdfDispatcher=WinUsb
> UmdfService=WUDFOsrUsbFx2, WUDFOsrUsbFx2_Install
> UmdfServiceOrder=WUDFOsrUsbFx2
>
> [OsrUsb_Install.NT.CoInstallers]
> AddReg=CoInstallers_AddReg
> CopyFiles=CoInstallers_CopyFiles
>
> [WinUsb_Install]
> KmdfLibraryVersion = 1.0
>
> [WUDFOsrUsbFx2_Install]
> UmdfLibraryVersion=1.5.0
> ;DriverCLSID=“{7bf5cb94-b686-4721-955e-878e48933a2c}”
> DriverCLSID=“{DACA6A6E-CB6F-4851-BAFE-8F75013F66C8}”
> ServiceBinary = “%12%\UMDF\WUDFOsrUsbFx2.dll”
>
> [OsrUsb_Device_AddReg]
> HKR,“LowerFilters”,0x00010008,“WinUsb” ; FLG_ADDREG_TYPE_MULTI_SZ |
> FLG_ADDREG_APPEND
>
> [WUDFRD_ServiceInstall]
> DisplayName = %WudfRdDisplayName%
> ServiceType = 1
> StartType = 3
> ErrorControl = 1
> ServiceBinary = %12%\WUDFRd.sys
> LoadOrderGroup = Base
>
>
> [WinUsb_ServiceInstall]
> DisplayName = %WinUsb_SvcDesc%
> ServiceType = 1
> StartType = 3
> ErrorControl = 1
> ServiceBinary = %12%\WinUSB.sys
>
> [CoInstallers_AddReg]
> HKR,CoInstallers32,0x00010000,“WudfUpdate_01005.dll”,
> “WdfCoInstaller01005.dll,WdfCoInstaller”, “WinUsbCoInstaller.dll”
>
> [CoInstallers_CopyFiles]
> WudfUpdate_01005.dll
> WdfCoInstaller01005.dll
> WinUsbCoinstaller.dll
>
> [DestinationDirs]
> UMDriverCopy=12,UMDF ; copy to driversMdf
> CoInstallers_CopyFiles=11
>
> [UMDriverCopy]
> WUDFOsrUsbFx2.dll
>
> ; =================== Generic ==================================
>
> [Strings]
> MSFTUMDF=“N-trig Innovative Technologies”
> MediaDescription=“N-trig HID Tablet Digitizer - USB Driver Installation
> Media”
> ;ClassName=“N-trig”
> WudfRdDisplayName=“Windows Driver Foundation - User-mode Driver Framework
> Reflector”
> OsrUsbDeviceName=“N-Trig HID Tablet Digitizer”
> WinUsb_SvcDesc=“WinUSB Driver”
>
>
>

3

The WDK build environments indicate the TARGET machine architecture, and not the HOST or DEVELOPMENT machine’s architecture.

The AMD environment (which is call x64 specifically because it supports both Intel and AMD 64-bit extensions to the x86 architecture) is actually the one you want unless your 64-bit machine is an Itanium.

Since you say the machine “has a similar configuration”, I assume you mean it has the Intel 64-bit processors, so one problem is you are installing the wrong driver. You need exactly the one you thought you didn’t.

Since your device is configured with an unloadable driver binary, it “is not configured correctly”, so code 1 is appropriate…

4

Bob Kjelgaard wrote:

The AMD environment (which is call x64 specifically because it
supports both Intel and AMD 64-bit extensions to the x86
architecture) is actually the one you want unless your 64-bit machine
is an Itanium.

Since you say the machine “has a similar configuration”, I assume you
mean it has the Intel 64-bit processors, so one problem is you are
installing the wrong driver. You need exactly the one you thought
you didn’t.

Just to clarify the naming:

IA16=iAPX86==x86 : Intel Architecture 16: The 16 bit instruction set
invented by Intel for its 8086/iAPX86 and compatible processors
(including the latest quadcore Xeon) and cloned by AMD, Cyrix, TransMeta
and others.

IA32==i386==x86 : Intel Architecture 32: The 32 bit instruction set
invented by Intel for its i386 and compatible processors (including the
latest quadcore Xeon) and cloned by AMD, Cyrix, TransMeta and others.

IA64 : Intel Architecture 64: The 64 bit instruction set
invented by Intel for its Itanium and compatible processors (including
Itanium 2) and NOT cloned by AMD.

AMD64==x64==x86_64: AMD x86 64 bit extensions: The 64 bit instruction
set invented by AMD as a straightforward extension of the IA32/x86
architecture and cloned by Intel in its Xeon EM64T processors.

So the phrase “Intel 64-bit processors” is ambiguous and should be
avoided. Say “Intel Itanium processors” (IA64) and “Intel EM64T
processors” (AMD64-compatible).

–
Jakob B?hm, M.Sc.Eng. * xxxxx@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right

5

Hi,
Thanks for the replies.
I’ve tried installing a driver compiled with the Vista x64 env, and I get this message “This device is not working properly because Windows cannot load the drivers required for this device. (Code 31)”.
I’ve tried installing it with and without the WinUsbCoinstaller.dll. Both gave same results.
What drivers is this message referring to?
I attach my new inf below.
Thanks,
Gadi

;
; WUDFOsrUsbFx2.inf - Install the OSR USB user-mode driver
;

[Version]
Signature=“$Windows NT$”
Class=HIDClass
;ClassGuid={78A1C341-4539-11d3-B88D-00C04FAD5171}
Provider=%MSFTUMDF%
DriverVer=29/04/2007,1.0.0001.00007
CatalogFile=wudf.cat

[Manufacturer]
%MSFTUMDF%=Microsoft,NTAMD64

[Microsoft.NTAMD64]
%OsrUsbDeviceName%=OsrUsb_Install, USB\Vid_1b96&Pid_0001&mi_02

[ClassInstall32]
AddReg=SampleClass_RegistryAdd

[SampleClass_RegistryAdd]
HKR,%ClassName%
HKR,Icon,“-24”

[SourceDisksFiles]
WUDFOsrUsbFx2.dll=1
WudfUpdate_01005.dll=1
WdfCoInstaller01005.dll=1
WinUsbCoinstaller.dll = 1

[SourceDisksNames]
1 = %MediaDescription%

; =================== UMDF OsrUsb Device ==================================

[OsrUsb_Install.NT]
CopyFiles=UMDriverCopy
Include=WINUSB.INF ; Import sections from WINUSB.INF
Needs=WINUSB.NT ; Run the CopyFiles & AddReg directives for WinUsb.INF

[OsrUsb_Install.NT.hw]
AddReg=OsrUsb_Device_AddReg

[OsrUsb_Install.NT.Services]
AddService=WUDFRd,0x000001fa,WUDFRD_ServiceInstall ; flag 0x2 sets this as the service for the device
AddService=WinUsb,0x000001f8,WinUsb_ServiceInstall ; this service is installed because its a filter.

[OsrUsb_Install.NT.Wdf]
KmdfService=WINUSB, WinUsb_Install
UmdfDispatcher=WinUsb
UmdfService=WUDFOsrUsbFx2, WUDFOsrUsbFx2_Install
UmdfServiceOrder=WUDFOsrUsbFx2

[OsrUsb_Install.NT.CoInstallers]
AddReg=CoInstallers_AddReg
CopyFiles=CoInstallers_CopyFiles

[WinUsb_Install]
KmdfLibraryVersion = 1.0

[WUDFOsrUsbFx2_Install]
UmdfLibraryVersion=1.5.0
;DriverCLSID=“{7bf5cb94-b686-4721-955e-878e48933a2c}”
DriverCLSID=“{DACA6A6E-CB6F-4851-BAFE-8F75013F66C8}”
ServiceBinary = “%12%\UMDF\WUDFOsrUsbFx2.dll”

[OsrUsb_Device_AddReg]
HKR,“LowerFilters”,0x00010008,“WinUsb” ; FLG_ADDREG_TYPE_MULTI_SZ | FLG_ADDREG_APPEND

[WUDFRD_ServiceInstall]
DisplayName = %WudfRdDisplayName%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %12%\WUDFRd.sys
LoadOrderGroup = Base

[WinUsb_ServiceInstall]
DisplayName = %WinUsb_SvcDesc%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %12%\WinUSB.sys

[CoInstallers_AddReg]
HKR,CoInstallers32,0x00010000,“WudfUpdate_01005.dll”, “WdfCoInstaller01005.dll,WdfCoInstaller”, “WinUsbCoInstaller.dll”

[CoInstallers_CopyFiles]
WudfUpdate_01005.dll
WdfCoInstaller01005.dll
WinUsbCoinstaller.dll

[DestinationDirs]
UMDriverCopy=12,UMDF ; copy to driversMdf
CoInstallers_CopyFiles=11

[UMDriverCopy]
WUDFOsrUsbFx2.dll

; =================== Generic ==================================

[Strings]
MSFTUMDF=“N-trig Innovative Technologies”
MediaDescription=“N-trig HID Tablet Digitizer - USB Driver Installation Media”
;ClassName=“N-trig”
WudfRdDisplayName=“Windows Driver Foundation - User-mode Driver Framework Reflector”
OsrUsbDeviceName=“N-Trig HID Tablet Digitizer”
WinUsb_SvcDesc=“WinUSB Driver”

6

What OS? If this is Vista x64, then you have to test-sign the driver and turn testsigning on with bcdedit. If it is XP 64-bit, then you’ll need to look at setupapi.log and are probably going to need a debugger before long.

7

Well it was unambiguous in context, since OP had identified the processors in use on the first machine (x64 processors with a 32-bit OS installed).

I prefer x64 because for most purposes I don’t care who made it, and em64t is non-mnemonic gibberish.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jakob Bohm
Sent: Tuesday, May 01, 2007 7:08 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Compiling USB UMDF driver for Vista 64-bit

Bob Kjelgaard wrote:

The AMD environment (which is call x64 specifically because it
supports both Intel and AMD 64-bit extensions to the x86
architecture) is actually the one you want unless your 64-bit machine
is an Itanium.

Since you say the machine “has a similar configuration”, I assume you
mean it has the Intel 64-bit processors, so one problem is you are
installing the wrong driver. You need exactly the one you thought
you didn’t.

Just to clarify the naming:

IA16=iAPX86==x86 : Intel Architecture 16: The 16 bit instruction set
invented by Intel for its 8086/iAPX86 and compatible processors
(including the latest quadcore Xeon) and cloned by AMD, Cyrix, TransMeta
and others.

IA32==i386==x86 : Intel Architecture 32: The 32 bit instruction set
invented by Intel for its i386 and compatible processors (including the
latest quadcore Xeon) and cloned by AMD, Cyrix, TransMeta and others.

IA64 : Intel Architecture 64: The 64 bit instruction set
invented by Intel for its Itanium and compatible processors (including
Itanium 2) and NOT cloned by AMD.

AMD64==x64==x86_64: AMD x86 64 bit extensions: The 64 bit instruction
set invented by AMD as a straightforward extension of the IA32/x86
architecture and cloned by Intel in its Xeon EM64T processors.

So the phrase “Intel 64-bit processors” is ambiguous and should be
avoided. Say “Intel Itanium processors” (IA64) and “Intel EM64T
processors” (AMD64-compatible).

–
Jakob B?hm, M.Sc.Eng. * xxxxx@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right

8

Are you using the amd64 versions of WinUsbCoinstaller.dll & WudfUpdate_01005.dll as well as your driver binary?

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@n-trig.com
Sent: Tuesday, May 01, 2007 7:26 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Compiling USB UMDF driver for Vista 64-bit

Hi,
Thanks for the replies.
I’ve tried installing a driver compiled with the Vista x64 env, and I get this message “This device is not working properly because Windows cannot load the drivers required for this device. (Code 31)”.
I’ve tried installing it with and without the WinUsbCoinstaller.dll. Both gave same results.
What drivers is this message referring to?
I attach my new inf below.
Thanks,
Gadi

;
; WUDFOsrUsbFx2.inf - Install the OSR USB user-mode driver
;

[Version]
Signature=“$Windows NT$”
Class=HIDClass
;ClassGuid={78A1C341-4539-11d3-B88D-00C04FAD5171}
Provider=%MSFTUMDF%
DriverVer=29/04/2007,1.0.0001.00007
CatalogFile=wudf.cat

[Manufacturer]
%MSFTUMDF%=Microsoft,NTAMD64

[Microsoft.NTAMD64]
%OsrUsbDeviceName%=OsrUsb_Install, USB\Vid_1b96&Pid_0001&mi_02

[ClassInstall32]
AddReg=SampleClass_RegistryAdd

[SampleClass_RegistryAdd]
HKR,%ClassName%
HKR,Icon,“-24”

[SourceDisksFiles]
WUDFOsrUsbFx2.dll=1
WudfUpdate_01005.dll=1
WdfCoInstaller01005.dll=1
WinUsbCoinstaller.dll = 1

[SourceDisksNames]
1 = %MediaDescription%

; =================== UMDF OsrUsb Device ==================================

[OsrUsb_Install.NT]
CopyFiles=UMDriverCopy
Include=WINUSB.INF ; Import sections from WINUSB.INF
Needs=WINUSB.NT ; Run the CopyFiles & AddReg directives for WinUsb.INF

[OsrUsb_Install.NT.hw]
AddReg=OsrUsb_Device_AddReg

[OsrUsb_Install.NT.Services]
AddService=WUDFRd,0x000001fa,WUDFRD_ServiceInstall ; flag 0x2 sets this as the service for the device
AddService=WinUsb,0x000001f8,WinUsb_ServiceInstall ; this service is installed because its a filter.

[OsrUsb_Install.NT.Wdf]
KmdfService=WINUSB, WinUsb_Install
UmdfDispatcher=WinUsb
UmdfService=WUDFOsrUsbFx2, WUDFOsrUsbFx2_Install
UmdfServiceOrder=WUDFOsrUsbFx2

[OsrUsb_Install.NT.CoInstallers]
AddReg=CoInstallers_AddReg
CopyFiles=CoInstallers_CopyFiles

[WinUsb_Install]
KmdfLibraryVersion = 1.0

[WUDFOsrUsbFx2_Install]
UmdfLibraryVersion=1.5.0
;DriverCLSID=“{7bf5cb94-b686-4721-955e-878e48933a2c}”
DriverCLSID=“{DACA6A6E-CB6F-4851-BAFE-8F75013F66C8}”
ServiceBinary = “%12%\UMDF\WUDFOsrUsbFx2.dll”

[OsrUsb_Device_AddReg]
HKR,“LowerFilters”,0x00010008,“WinUsb” ; FLG_ADDREG_TYPE_MULTI_SZ | FLG_ADDREG_APPEND

[WUDFRD_ServiceInstall]
DisplayName = %WudfRdDisplayName%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %12%\WUDFRd.sys
LoadOrderGroup = Base

[WinUsb_ServiceInstall]
DisplayName = %WinUsb_SvcDesc%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %12%\WinUSB.sys

[CoInstallers_AddReg]
HKR,CoInstallers32,0x00010000,“WudfUpdate_01005.dll”, “WdfCoInstaller01005.dll,WdfCoInstaller”, “WinUsbCoInstaller.dll”

[CoInstallers_CopyFiles]
WudfUpdate_01005.dll
WdfCoInstaller01005.dll
WinUsbCoinstaller.dll

[DestinationDirs]
UMDriverCopy=12,UMDF ; copy to driversMdf
CoInstallers_CopyFiles=11

[UMDriverCopy]
WUDFOsrUsbFx2.dll

; =================== Generic ==================================

[Strings]
MSFTUMDF=“N-trig Innovative Technologies”
MediaDescription=“N-trig HID Tablet Digitizer - USB Driver Installation Media”
;ClassName=“N-trig”
WudfRdDisplayName=“Windows Driver Foundation - User-mode Driver Framework Reflector”
OsrUsbDeviceName=“N-Trig HID Tablet Digitizer”
WinUsb_SvcDesc=“WinUSB Driver”

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

9

My bad- kernel drivers need signing on Vista x64. UMDF maybe not.

10

Bob Kjelgaard wrote:

What OS? If this is Vista x64, then you have to test-sign the driver and turn testsigning on with bcdedit. If it is XP 64-bit, then you’ll need to look at setupapi.log and are probably going to need a debugger before long.

OK, now, wait a minute. I thought the “test-signing” thing was only to
simulate the WHQL signature, and that the ONLY way to bypass the code
signing requirement was to attach a kernel debugger or to use the
press-F8-at-boot-time nonsense. I just sent lengthy explanations to two
different clients describing this process, because I thought I finally
understood it. Am I still in the weeds here?

Darn it, my head is spinning again.

Hasn’t anybody written a virus that bypasses this code-signing stuff
yet, he said, only half joking?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

11

Bcdedit /set testsigning on (you need to be running as admin of course)

is another way to do this, and doesn’t require all the boot time intervention. I’m not sure just having a debugger attached is enough (but I just always do it this way, debugger or not, so it might). Ditto with the other (once I found something that worked, I just stuck with it).

I’m sure this is documented somewhere on WHDC…

The driver binary MUST be tied to a certificate [either embedded or signed via catalog] though, or it will not load in the kernel. Normally the certificate has to track to a trusted root [I’m probably being imprecise, because I never wanted to be an authority on this sort of thing].

This setting bypasses the root authority checks so you can get by with certificates you create with MakeCert, etc. When it is active, the display shows “Test mode” in all 4 corners so you can remember to turn it off when you want to see if the driver package would work on an end user’s machine with the checks on.

UMDF, though isn’t loaded in the kernel (rather the parts that are signed by Microsoft). I said maybe because I was thinking about DRM, but audio via UMDF isn’t feasible yet, to the best of my knowledge.

FWIW, I agree that it is a pain. Doesn’t help that it changed a few times during the Beta (but that’s betas for you).

I went through the process a few times manually when we were first testing the KMDF WDK content, and it struck me as pretty daunting stuff- not exactly documented in driver developer-speak, either.

Fortunately most of the time, it’s all pretty much automatic for my own work

>> In response to:

OK, now, wait a minute. I thought the “test-signing” thing was only to
simulate the WHQL signature, and that the ONLY way to bypass the code
signing requirement was to attach a kernel debugger or to use the
press-F8-at-boot-time nonsense. I just sent lengthy explanations to two
different clients describing this process, because I thought I finally
understood it. Am I still in the weeds here?

Darn it, my head is spinning again.

Hasn’t anybody written a virus that bypasses this code-signing stuff
yet, he said, only half joking?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

12

Bob Kjelgaard wrote:

Bcdedit /set testsigning on (you need to be running as admin of course)

is another way to do this, and doesn’t require all the boot time intervention. I’m not sure just having a debugger attached is enough (but I just always do it this way, debugger or not, so it might). Ditto with the other (once I found something that worked, I just stuck with it).

I’m sure this is documented somewhere on WHDC…

The driver binary MUST be tied to a certificate [either embedded or signed via catalog] though, or it will not load in the kernel. Normally the certificate has to track to a trusted root [I’m probably being imprecise, because I never wanted to be an authority on this sort of thing].

A common desire, apparently.

This setting bypasses the root authority checks so you can get by with certificates you create with MakeCert, etc. When it is active, the display shows “Test mode” in all 4 corners so you can remember to turn it off when you want to see if the driver package would work on an end user’s machine with the checks on.

Ah, OK, so with the bcdedit switch, the driver still has to be signed,
but it can be signed with a certificate of my own invention, rather than
one from Verisign. On the other hand, with the F8 boot switch, the
driver doesn’t have to be signed at all. That’s a useful thing to know.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

13

> OK, now, wait a minute. I thought the “test-signing” thing was only to

simulate the WHQL signature, and that the ONLY way to bypass the code

No. Vista64 kernel signing has nearly nothing to do with WHQL.

You do not need to pass the tests, and the WHQL submission. You sign the driver
in your own lab by your corporate certificate, that’s all.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

14

Thanks, Tim- that made it clearer to me, as well.

Sorry about the fuzzy language- too much multi-tasking today- as in doing many things poorly…

Back to the OP- if it is a Vista machine, the setupapi.dev.log and setupapi.app.log will be in %windir%\inf. On XP, it will be %windir%\setupapi.log. They are useful in understanding install issues if you have one. Coinstaller issue as Peter suggested is quite likely.

15

Code signing most likely isn’t the issue here. UMDF driver packages need to be signed but the binaries do not (though I would still recommend signing them to make it harder to tamper with them)

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, May 01, 2007 11:34 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Compiling USB UMDF driver for Vista 64-bit

Bob Kjelgaard wrote:

Bcdedit /set testsigning on (you need to be running as admin of course)

is another way to do this, and doesn’t require all the boot time intervention. I’m not sure just having a debugger attached is enough (but I just always do it this way, debugger or not, so it might). Ditto with the other (once I found something that worked, I just stuck with it).

I’m sure this is documented somewhere on WHDC…

The driver binary MUST be tied to a certificate [either embedded or signed via catalog] though, or it will not load in the kernel. Normally the certificate has to track to a trusted root [I’m probably being imprecise, because I never wanted to be an authority on this sort of thing].

A common desire, apparently.

This setting bypasses the root authority checks so you can get by with certificates you create with MakeCert, etc. When it is active, the display shows “Test mode” in all 4 corners so you can remember to turn it off when you want to see if the driver package would work on an end user’s machine with the checks on.

Ah, OK, so with the bcdedit switch, the driver still has to be signed,
but it can be signed with a certificate of my own invention, rather than
one from Verisign. On the other hand, with the F8 boot switch, the
driver doesn’t have to be signed at all. That’s a useful thing to know.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

16

Bob Kjelgaard wrote:

Bcdedit /set testsigning on (you need to be running as admin of course)

is another way to do this, and doesn’t require all the boot time intervention. I’m not sure just having a debugger attached is enough (but I just always do it this way, debugger or not, so it might). Ditto with the other (once I found something that worked, I just stuck with it).

I’m sure this is documented somewhere on WHDC…

The driver binary MUST be tied to a certificate [either embedded or signed via catalog] though, or it will not load in the kernel. Normally the certificate has to track to a trusted root [I’m probably being imprecise, because I never wanted to be an authority on this sort of thing].

I never should have doubted you. :wink: I created my own certificate,
signed my driver, enabled testsigning mode on the Vista 64 target, and
it all works like a charm. It’s certainly a heck of a lot easier then
pounding F8 at every boot.

There’s still an awful lot of “magic spells” in here (“type exactly this
command with exactly these parameters, don’t bother asking why”), but
gradually this signature stuff is getting less mysterious to me. It’s
down to merely “annoying”.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

17

Off-topic:

>
I never should have doubted you. :wink:
<<

I’m fine if people doubt me- particularly if I get feedback from them when I’ve got it wrong. Better to find out sooner than later (for all parties, eventually). Not that it’s fun to get it- just necessary…

>
There’s still an awful lot of “magic spells” in here
<<
Some sci-fi author (Clarke? Asimov? too lazy to look it up) once said (probably an inexact quote) “any sufficiently advanced technology is indistinguishable from magic”. Scary though that it can now apply to practicing mages. :wink:

On-topic:

Gadi-

I noticed that your inf lists the KMDF library version for WinUSB as 1.0. I’m pretty sure it should be 1.5- I’m not certain that can cause your problem (and I’m not in a position to find out anything more at the moment), but it’s an easy change that’s worth a try. I’ve got a nagging sense we had some bad samples at one point with this bug in them (but while I may post from home- I keep the corporate network out- work/life balance sort of thing).

18

Yep, the amd64 versions of WinUsbCoinstaller.dll & WudfUpdate_01005.dll sloved the issue.
No testsigning was needed.
Thanks!