I am decidedly new to the world of KMDF drivers, and driver writing in general. I am trying to write a USB filter for a HID gamepad that will send a custom GET_REPORT request at some point during initialization (I’m thinking EvtDeviceD0Entry) and will return a custom HID Descriptor rather than the device provided descriptor on IOCTL_HID_GET_DEVICE_DESCRIPTOR. I get the general flow of driver programming based on the WDF and OSR samples (ie: DriverEntry sets up the DeviceAdd function, DeviceAdd tells the OS it’s a filter driver and changes the function pointers only for the parts you want to override, etc) but I’m pretty fuzzy on how to get anywhere beyond build.
With a standard application, that’s the point I would run the built executable and start my debugging process, likely from within the same IDE used to write the code. Drivers are completely different, and there seems to be a gap in the documentation between building a driver and doing anything in windbg - namely, how do I get the OS to load the driver? How do I view the IFR log for my driver? Is there a standalone utility that can be used, or am I stuck using WinDbg in kernel mode? Can I view it using a local kernel mode debug session? (that last one’s because I can’t get any of the instructions I’ve found to work, and the primary difference is I’m trying to debug it in local mode, whereas they recommend a USB or RS-232 connection).
Are there any good books/sites/documentation for this sort of thign? The announced OSR book looks promising, but there’s no listed release date.
Did you take one of the KMDF samples and install it? Getting the OSR USB
board and using it to understand how the drivers are installed is a good
thing. Since yours is a filter to a standard Microsoft driver, digging into
the details in the WDK can get you started. There is a book from Microsoft
Press about WDF. OSR also offers classes in driver development using KMDF.
wrote in message news:xxxxx@ntdev…
>I am decidedly new to the world of KMDF drivers, and driver writing in
>general. I am trying to write a USB filter for a HID gamepad that will send
>a custom GET_REPORT request at some point during initialization (I’m
>thinking EvtDeviceD0Entry) and will return a custom HID Descriptor rather
>than the device provided descriptor on IOCTL_HID_GET_DEVICE_DESCRIPTOR. I
>get the general flow of driver programming based on the WDF and OSR samples
>(ie: DriverEntry sets up the DeviceAdd function, DeviceAdd tells the OS
>it’s a filter driver and changes the function pointers only for the parts
>you want to override, etc) but I’m pretty fuzzy on how to get anywhere
>beyond build.
> With a standard application, that’s the point I would run the built
> executable and start my debugging process, likely from within the same IDE
> used to write the code. Drivers are completely different, and there seems
> to be a gap in the documentation between building a driver and doing
> anything in windbg - namely, how do I get the OS to load the driver? How
> do I view the IFR log for my driver? Is there a standalone utility that
> can be used, or am I stuck using WinDbg in kernel mode? Can I view it
> using a local kernel mode debug session? (that last one’s because I can’t
> get any of the instructions I’ve found to work, and the primary difference
> is I’m trying to debug it in local mode, whereas they recommend a USB or
> RS-232 connection).
> Are there any good books/sites/documentation for this sort of thign? The
> announced OSR book looks promising, but there’s no listed release date.
>
Welcome. I think David’s suggestion to get an osr board (see the links below) is an excellent one, and his suggestion to take a
class from osr is even better, though not necessarily something that will help you immediately, unless there happens to be one
offered immediately. As far as how to load a driver, as he mentioned, you’re trying to write a filter of an MSFT driver, so I would
recommend that you take take a look at the ‘readme.html’ file in the ‘hidusbfx2’ (I assume that’s a good driver for you to start
with; I really don’t know, but it’s ‘hid’ and it will run on the osr board), and it will tell you what to do.
As far as WinDbg goes, you have no choice - you must use it, and what you’re trying to do with local kernel debugging will not work.
Local kernel debugging is totally useless for anything beyond inspecting memory (and perhaps setting it), because you can’t do
anything that will halt the machine, like set a breakpoint, or anything that will require the machine to be halted, like read a
register. Accordingly, you will need to machines and either a null modem cable, an outrageously expensive and hard to find usb
cable (don’t do this) or a 1394 cable (what most people use, though some swear by serial). In theory, you could just buy a copy of
either MSFT Virtual PC (no thanks) or VMWare and use one machine, but that almost certainly will not work for you, as you are using
real hardware, and this is only an option for people writing software only drivers, like file systems, for example. As far the
documentation goes, yes, it deeply, deeply sucks and no, there really isn’t anything out there in the way of a better tutorial (at
least that I know of), though there is one in a Word file in the root of your WinDbg installation (never read it).
All that being said, it’s possible that a UMDF driver would also work for you, which would be much kinder to a beginner, as those
are user mode. Unfortunately, I don’t know the answer to whether it will work in your case or not, but I think it would, and
someone who knows more about this than I will no doubt correct me if I am wrong certainly sometime tomorrow if not sooner. I would
say without any reservation whatsoever that I would use one of the WDF’s to do this - KMDF or UMDF - over WDM. Were it not for the
rather irritating installation issues that not uncommonly hit users of KMDF (maybe UMDF as well; I don’t know), this would be a no
brainer, but it’s still clearly the way to go, in my opinion. If both KMDF and UMDF are options, then which one would be better
would, in my opinion, depend on your view of the bigger picture. If you want to get something up and running - which makes a lot of
sense - then the later would probably suit you better; if you’re interested in writing drivers generally and have the time and
interest for a more unforgiving learning curve, then I would recommend the former.
Some links:
OSR:
article (old) about osr board - http://www.osronline.com/article.cfm?article=382
kd quick start seminar - http://www.osr.com/quickstart_KD.shtml
kdf seminar - http://www.osr.com/seminars_wwdfdmw_5dlwl.cfm
OTHER:
some projects that use the osr board - http://osrfx2.sourceforge.net/ [I have no idea of what’s on this page]
Good luck,
mm
David Craig wrote:
Did you take one of the KMDF samples and install it? Getting the OSR USB board and using it to understand how the drivers are
installed is a good thing. Since yours is a filter to a standard Microsoft driver, digging into the details in the WDK can get
you started. There is a book from Microsoft Press about WDF. OSR also offers classes in driver development using KMDF.wrote in message news:xxxxx@ntdev…
>> I am decidedly new to the world of KMDF drivers, and driver writing in general. I am trying to write a USB filter for a HID
>> gamepad that will send a custom GET_REPORT request at some point during initialization (I’m thinking EvtDeviceD0Entry) and will
>> return a custom HID Descriptor rather than the device provided descriptor on IOCTL_HID_GET_DEVICE_DESCRIPTOR. I get the general
>> flow of driver programming based on the WDF and OSR samples (ie: DriverEntry sets up the DeviceAdd function, DeviceAdd tells
>> the OS it’s a filter driver and changes the function pointers only for the parts you want to override, etc) but I’m pretty
>> fuzzy on how to get anywhere beyond build. With a standard application, that’s the point I would run the built executable and
>> start my debugging process, likely from within the same IDE used to write the code. Drivers are completely different, and there
>> seems to be a gap in the documentation between building a driver and doing anything in windbg - namely, how do I get the OS to
>> load the driver? How do I view the IFR log for my driver? Is there a standalone utility that can be used, or am I stuck using
>> WinDbg in kernel mode? Can I view it using a local kernel mode debug session? (that last one’s because I can’t get any of the
>> instructions I’ve found to work, and the primary difference is I’m trying to debug it in local mode, whereas they recommend a
>> USB or RS-232 connection). Are there any good books/sites/documentation for this sort of thign? The announced OSR book looks
>> promising, but there’s no listed release date.
>>
>
>
>
>Did you take one of the KMDF samples and install it? Getting the OSR USB
board and using it to understand how the drivers are installed is a good thing.
I’ve installed all of the samples that come with the WDF download. The hidusbfx2 sample looked promising initially, but the problem there is it’s really a completely different purpose - you’re taking a non-HID USB device and adding HID functionality to it. In my case I have a HID USB device and I’d like to add what would in the linux world be referred to as a “quirk”.
As for looking at how hidusbfx2 handled driver installation, I couldn’t get that to install out-of-the box either. I tried copying the appropriate coinstaller and other packages to the same directory as the INF and SYS files and adding a device, which seemed to go very poorly. The setupapi.log and setupact.log files didn’t offer any information on the install, as though the process didn’t even reach that point. I would really appreciate some way to debug an INF installation process so I could see at just what point it fails, but I’m fairly certain I’m out of luck.
I do appreciate the tips, and I’ll continue working on this. It’s been a learning experience, to say the least.
Andrew:
I must have misread your post, because I just read this one, and see that you are much further along than I had assumed. My
apologies. Unfortunately - in shocking news - you have the exact problem that I alluded to with using KMDF - installation. What?
You mean that ‘Code 10’ (perhaps 13 or 1) didn’t tell you everything you needed to know about the problem? Hard to believe.
Seriously, that you’ve already found ‘setupapi.log’ and figured out that it’s kind of a wasteland (most of the time) is very
commendable for someone who is new to this stuff. That’s the good news; the bad news is that ‘setupapi.log’ is pretty much it, as
far as where to look goes. Unfortunately, I don’t enough about USB to make any intelligent suggestions about what you’re INF should
look like, so all I can recommend is that because ‘setupapi.log’ is hard as hell to make sense out of, just to make sure that you’re
not missing something in there, I would recommend that you rename it, try to reinstall, and then the contents here, along with your
INF. Otherwise, there isn’t a whole that anyone can tell you via e-mail that will help, at least that I know.
In any case, to be honest, I undersold the installation issues as ‘not uncommon.’ They’re very common, the reason that many of us
simply will not ship anything that uses it (along with a variation on the same problem), and in my opinion, unless MSFT fixes it,
stat, it’s going to take a truly great product - KMDF - straight to the bottom, at least as far as what people would like to use if
given a choice goes; by some measures, it already has, but I still hold out hope here, because KMDF kicks ass. Either way, we won’t
have any choice in the matter, of course, and that is what has allowed MSFT to overlook for a good ten years that everything they
have ever done in the way of installation technology has been an absolutely abject failure - I’m not sure anyone on this list would
disagree with that (just that they’ve failed in this area repeatedly) - and each one is worse than the one it replaced, if for no
other reason that it doesn’t really fix much of anything and is just harder to use and in some cases just silly. To be fair, the
ramifications of the hysterical nonsense that these days goes by the name ‘security’ affect MSFT like no one else, and although the
atmosphere surrounding ‘security’ is - in my opinion - predatory nonsense, the right article about about some hint of having the
wrong type of flaw in your software will put your lights out in some cases, so they have to design around that, for better or worse,
to a very significant extent. That being said, that doesn’t mean what they are choosing is working all that well and certainly not
that it’s what developer’s necessarily want (if you spend a little time on this list, eventually the subject of static linking to
kmdf will come up, and you’ll see what I mean), but it is what it is.
Good luck,
mm
xxxxx@gmail.com wrote:
> Did you take one of the KMDF samples and install it? Getting the OSR USB
> board and using it to understand how the drivers are installed is a good thing.
I’ve installed all of the samples that come with the WDF download. The hidusbfx2 sample looked promising initially, but the problem there is it’s really a completely different purpose - you’re taking a non-HID USB device and adding HID functionality to it. In my case I have a HID USB device and I’d like to add what would in the linux world be referred to as a “quirk”.
As for looking at how hidusbfx2 handled driver installation, I couldn’t get that to install out-of-the box either. I tried copying the appropriate coinstaller and other packages to the same directory as the INF and SYS files and adding a device, which seemed to go very poorly. The setupapi.log and setupact.log files didn’t offer any information on the install, as though the process didn’t even reach that point. I would really appreciate some way to debug an INF installation process so I could see at just what point it fails, but I’m fairly certain I’m out of luck.
I do appreciate the tips, and I’ll continue working on this. It’s been a learning experience, to say the least.
Victory! - Well, sort of at least. I’m not sure exactly what I did, but it’s now letting me install the driver from an INF file. I get a BSOD which would seem to indicate that my code is to blame.
From setupapi.log:
[2008/06/29 15:49:30 3620.2012]
#-198 Command line processed: “C:\WINDOWS\system32\mmc.exe” “C:\WINDOWS\system32\devmgmt.msc”
#I060 Set selected driver.
#-019 Searching for hardware ID(s): usb\vid_054c&pid_0268&rev_0100,usb\vid_054c&pid_0268
#-018 Searching for compatible ID(s): usb\class_03&subclass_00&prot_00,usb\class_03&subclass_00,usb\class_03
#I022 Found “USB\VID_054C&PID_0268” in C:\WINDOWS\inf\oem43.inf; Device: “Sony Playstation3 Controller”; Driver: “Sony Playstation3 Controller”; Provider: “SIXaxis Control Driver”; Mfg: “SIXaxis Control Driver”; Section name: “Sixaxis_Inst”.
#I087 Driver node not trusted, rank changed from 0x00000001 to 0x00008001.
#I023 Actual install section: [Sixaxis_Inst.NTx86]. Rank: 0x00008001. Effective driver date: 06/19/2008.
#I022 Found “USB\Class_03” in C:\WINDOWS\inf\input.inf; Device: “USB Human Interface Device”; Driver: “USB Human Interface Device”; Provider: “Microsoft”; Mfg: “(Standard system devices)”; Section name: “HID_Inst”.
#I023 Actual install section: [HID_Inst.NT]. Rank: 0x00003202. Effective driver date: 07/01/2001.
#-019 Searching for hardware ID(s): usb\vid_054c&pid_0268&rev_0100,usb\vid_054c&pid_0268
#-018 Searching for compatible ID(s): usb\class_03&subclass_00&prot_00,usb\class_03&subclass_00,usb\class_03
#-124 Doing copy-only install of “USB\VID_054C&PID_0268\5&1CACC503&0&5”.
#W334 Failed to verify catalog when scanning file queue. Error 1168: Element not found.
#E366 An unsigned or incorrectly signed file “c:\windows\inf\oem43.inf” for driver “Sony Playstation3 Controller” will be installed (Policy=Warn, user said ok). Error 1168: Element not found.
#W187 Install failed, attempting to restore original files.
#E362 An unsigned or incorrectly signed file “c:\windows\inf\oem43.inf” for driver “Sony Playstation3 Controller” will be installed (Policy=Warn). Error 1168: Element not found.
#-024 Copying file “C:\DEV\sixaxis\SIXCD_driver\src\objchk_wxp_x86\i386\SIXCD.sys” to “C:\WINDOWS\system32\DRIVERS\SIXCD.sys”.
#E362 An unsigned or incorrectly signed file “C:\DEV\sixaxis\SIXCD_driver\src\objchk_wxp_x86\i386\SIXCD.sys” for driver “Sony Playstation3 Controller” will be installed (Policy=Warn). Error 1168: Element not found.
#-166 Device install function: DIF_REGISTER_COINSTALLERS.
#I056 Coinstallers registered.
#-166 Device install function: DIF_INSTALLINTERFACES.
#-011 Installing section [Sixaxis_Inst.NTx86.Interfaces] from “c:\windows\inf\oem43.inf”.
#I054 Interfaces installed.
#-166 Device install function: DIF_INSTALLDEVICE.
#I123 Doing full install of “USB\VID_054C&PID_0268\5&1CACC503&0&5”.
The contents of oem43.inf:
; C:\dev\sixaxis\C\src\objfre_wxp_x86\i386\SIXCD.inf
;
; Created by GenINF.
;
;
[Version]
Signature = “$Windows NT$”
Class=USB
ClassGUID={36fc9e60-c465-11cf-8056-444553540000}
Provider=%SIXCD%
CatalogFile=SIXCD.sys.cat
DriverVer= 6/19/2008
[DestinationDirs]
Sixaxis.Files.x86_12 = 12
[SourceDisksNames.x86]
0=%Desc_x860%
[SourceDisksNames.ia64]
[SourceDisksFiles.x86]
SIXCD.sys=0,\dev\sixaxis\C\src\objfre_wxp_x86\i386,
[SourceDisksFiles.ia64]
[Manufacturer]
%SIXCD%=SIXCD
[SIXCD]
%SixaxisDesc%=Sixaxis_Inst,USB\VID_054C&PID_0268
[Sixaxis_Inst.ntx86]
CopyFiles = Sixaxis.Files.x86_12
[Sixaxis_Inst.ntx86.Services]
AddService = SIXCD,0x00000002,Sixaxis_Service_Instx86, Sixaxis_EventLog_Inst
[Sixaxis_Service_Instx86]
ServiceType = %SERVICE_KERNEL_DRIVER%
StartType = %SERVICE_DEMAND_START%
ErrorControl = %SERVICE_ERROR_NORMAL%
ServiceBinary = %12%\SIXCD.sys
[Sixaxis.Files.x86_12]
SIXCD.sys
[Sixaxis_EventLog_Inst]
AddReg = Sixaxis_EventLog_Inst.AddReg
[Sixaxis_EventLog_Inst.AddReg]
HKR,EventMessageFile,%REG_EXPAND_SZ%,“%%SystemRoot%%\System32\IoLogMsg.dll”
HKR,TypesSupported,%REG_DWORD%,7
[Strings]
; *******Localizable Strings*******
SIXCD= “SIXaxis Control Driver”
Desc_x860= “SIXaxis Control Driver USBdrivers”
SixaxisDesc= “Sony Playstation3 Controller”
; *******Non Localizable Strings*******
SERVICE_BOOT_START = 0x0
SERVICE_SYSTEM_START = 0x1
SERVICE_AUTO_START = 0x2
SERVICE_DEMAND_START = 0x3
SERVICE_DISABLED = 0x4
SERVICE_KERNEL_DRIVER = 0x1
SERVICE_ERROR_IGNORE = 0x0
SERVICE_ERROR_NORMAL = 0x1
SERVICE_ERROR_SEVERE = 0x2
SERVICE_ERROR_CRITICAL = 0x3
REG_EXPAND_SZ = 0x00020000
REG_DWORD = 0x00010001
>between building a driver and doing anything in windbg - namely, how do I get
the
OS to load the driver?
By installing the driver.
How do I view the IFR log for my driver?
What is IFR?
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> By installing the driver.
While this statement is absolutely true, I was looking for a slightly more articulated answer. Is the only way to install the driver via an INF file? If so, what tools are available (beyond GenINF, which I’ve already tried) to build a properly formed INF for a KMDF driver? What will my INF need to do in this case, since I’m replacing some functionality of the default hidusb.sys driver? Upper or Lower filter?
What is IFR?
Some documentation refers to it as the In-Flight Recorder, but I think the more common term is WPP. In WinDbg you can access it using !wdflogdump - although all this terminology is pretty overwhelming for somebody new to the field. Basically, I want a way to see how far my driver gets before BSOD. I believe I can actually use the mini-dump to check this out as shown in http://blogs.msdn.com/doronh/archive/2006/08/02/687010.aspx but I’d rather not have to BSOD every time I want to see what it’s doing… For a standard application I would write to a logfile at key points. Is it possible for a driver to do the same thing?
xxxxx@gmail.com wrote:
> By installing the driver.
>
While this statement is absolutely true, I was looking for a slightly more articulated answer. Is the only way to install the driver via an INF file? If so, what tools are available (beyond GenINF, which I’ve already tried) to build a properly formed INF for a KMDF driver? What will my INF need to do in this case, since I’m replacing some functionality of the default hidusb.sys driver? Upper or Lower filter?
If you are installing a PnP function driver (a normal driver), then an
INF is the only practical way. Most people build INFs by starting from
one of the DDK samples and tweaking it. After you’ve done a few, it
becomes clear which sections are important and which are not so important.
If you are writing a filter driver, then you CAN use an INF, but you can
also do it manually, by creating a service and modifying the registry.
> What is IFR?
>
Some documentation refers to it as the In-Flight Recorder, but I think the more common term is WPP. In WinDbg you can access it using !wdflogdump - although all this terminology is pretty overwhelming for somebody new to the field. Basically, I want a way to see how far my driver gets before BSOD. I believe I can actually use the mini-dump to check this out as shown in http://blogs.msdn.com/doronh/archive/2006/08/02/687010.aspx but I’d rather not have to BSOD every time I want to see what it’s doing… For a standard application I would write to a logfile at key points. Is it possible for a driver to do the same thing?
This is actually one of the more practical uses for the “local kernel
debug” feature of WinDbg. You can use the !wdflogdump command to dump
the IFR data on the fly. Alternatively, you can use KdPrint/DbgPrint
and monitor the messages using a tool like dbgview.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> INF is the only practical way. Most people build INFs by starting from
one of the DDK samples and tweaking it.
…or by starting from one MS-provided INF from %SystemRoot%\INF and tweaking
it.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
OK - I think I have things nearly there. When I try to update the device driver it fails to install the services (Code 10). Looking into the setupapi.log file, I find the following:
[SetupAPI Log]
OS Version = 5.1.2600 Service Pack 2
Platform ID = 2 (NT)
Service Pack = 2.0
Suite = 0x0100
Product Type = 1
Architecture = x86
[2008/07/02 08:17:23 1224.3027]
#-198 Command line processed: “C:\WINDOWS\system32\mmc.exe” “C:\WINDOWS\system32\devmgmt.msc”
#I060 Set selected driver.
#-019 Searching for hardware ID(s): hid\vid_054c&pid_0268&rev_0100,hid\vid_054c&pid_0268,hid_device_system_game,hid_device_up:0001_u:0004,hid_device
#I022 Found “HID\VID_054C&PID_0268&REV_0100” in C:\WINDOWS\inf\oem52.inf; Device: “Sony PlayStation 3 Controller”; Driver: “Sony PlayStation 3 Controller”; Provider: “Mythgarr”; Mfg: “Mythgarr”; Section name: “USB_Install”.
#I087 Driver node not trusted, rank changed from 0x00000000 to 0x00008000.
#I023 Actual install section: [USB_Install]. Rank: 0x00008000. Effective driver date: 07/01/2008.
#I393 Modified INF cache “C:\WINDOWS\inf\INFCACHE.1”.
#I022 Found “HID\VID_054C&PID_0268&REV_0100” in C:\WINDOWS\inf\oem51.inf; Device: “Sony PlayStation 3 Controller”; Driver: “Sony PlayStation 3 Controller”; Provider: “Mythgarr”; Mfg: “Mythgarr”; Section name: “USB_Install”.
#I087 Driver node not trusted, rank changed from 0x00000000 to 0x00008000.
#I023 Actual install section: [USB_Install]. Rank: 0x00008000. Effective driver date: 07/01/2008.
#I022 Found “HID_DEVICE_SYSTEM_GAME” in C:\WINDOWS\inf\input.inf; Device: “HID-compliant game controller”; Driver: “HID-compliant game controller”; Provider: “Microsoft”; Mfg: “(Standard system devices)”; Section name: “HID_Raw_Inst”.
#I023 Actual install section: [HID_Raw_Inst.NT]. Rank: 0x00001002. Effective driver date: 07/01/2001.
#I022 Found “HID_DEVICE” in C:\WINDOWS\inf\input.inf; Device: “HID-compliant device”; Driver: “HID-compliant device”; Provider: “Microsoft”; Mfg: “(Standard system devices)”; Section name: “HID_Raw_Inst”.
#I023 Actual install section: [HID_Raw_Inst.NT]. Rank: 0x00001004. Effective driver date: 07/01/2001.
#-019 Searching for hardware ID(s): hid\vid_054c&pid_0268&rev_0100,hid\vid_054c&pid_0268,hid_device_system_game,hid_device_up:0001_u:0004,hid_device
#-019 Searching for hardware ID(s): hid\vid_054c&pid_0268&rev_0100,hid\vid_054c&pid_0268,hid_device_system_game,hid_device_up:0001_u:0004,hid_device
#-019 Searching for hardware ID(s): hid\vid_054c&pid_0268&rev_0100,hid\vid_054c&pid_0268,hid_device_system_game,hid_device_up:0001_u:0004,hid_device
#I022 Found “HID\VID_054C&PID_0268&REV_0100” in c:\dev\usb\sixcd\objfre_wxp_x86\i386\sixcd.inf; Device: “Sony PlayStation 3 Controller”; Driver: “Sony PlayStation 3 Controller”; Provider: “Mythgarr”; Mfg: “Mythgarr”; Section name: “USB_Install”.
#I087 Driver node not trusted, rank changed from 0x00000000 to 0x00008000.
#I023 Actual install section: [USB_Install]. Rank: 0x00008000. Effective driver date: 07/01/2008.
#-124 Doing copy-only install of “HID\VID_054C&PID_0268\6&13B76E30&0&0000”.
#E366 An unsigned or incorrectly signed file “c:\dev\usb\sixcd\objfre_wxp_x86\i386\sixcd.inf” for driver “Sony PlayStation 3 Controller” will be installed (Policy=Warn, user said ok). Error 0xe000022f: The third-party INF does not contain digital signature information.
#W187 Install failed, attempting to restore original files.
#E362 An unsigned or incorrectly signed file “c:\dev\usb\sixcd\objfre_wxp_x86\i386\sixcd.inf” for driver “Sony PlayStation 3 Controller” will be installed (Policy=Warn). Error 0xe000022f: The third-party INF does not contain digital signature information.
#-024 Copying file “c:\dev\usb\sixcd\objfre_wxp_x86\i386\hidkmdf.sys” to “C:\WINDOWS\system32\DRIVERS\hidkmdf.sys”.
#E362 An unsigned or incorrectly signed file “c:\dev\usb\sixcd\objfre_wxp_x86\i386\hidkmdf.sys” for driver “Sony PlayStation 3 Controller” will be installed (Policy=Warn). Error 0xe000022f: The third-party INF does not contain digital signature information.
#-336 Copying file “c:\dev\usb\sixcd\objfre_wxp_x86\i386\sixcd.sys” to “C:\WINDOWS\system32\DRIVERS\sixcd.sys” via temporary file “C:\WINDOWS\system32\DRIVERS\SET51.tmp”.
#E362 An unsigned or incorrectly signed file “c:\dev\usb\sixcd\objfre_wxp_x86\i386\sixcd.sys” for driver “Sony PlayStation 3 Controller” will be installed (Policy=Warn). Error 0xe000022f: The third-party INF does not contain digital signature information.
#-166 Device install function: DIF_REGISTER_COINSTALLERS.
#I056 Coinstallers registered.
#-166 Device install function: DIF_INSTALLINTERFACES.
#-011 Installing section [USB_Install.Interfaces] from “c:\dev\usb\sixcd\objfre_wxp_x86\i386\sixcd.inf”.
#I054 Interfaces installed.
#-166 Device install function: DIF_INSTALLDEVICE.
#I123 Doing full install of “HID\VID_054C&PID_0268\6&13B76E30&0&0000”.
#E362 An unsigned or incorrectly signed file “c:\dev\usb\sixcd\objfre_wxp_x86\i386\sixcd.inf” for driver “Sony PlayStation 3 Controller” will be installed (Policy=Warn). Error 0xe000022f: The third-party INF does not contain digital signature information.
#-035 Processing service Add/Delete section [USB_Install.Services].
#E280 Add Service: Failed to get configuration of service “sixcd”. Error 2: The system cannot find the file specified.
#E033 Error 2: The system cannot find the file specified.
#E275 Error while installing services. Error 2: The system cannot find the file specified.
#E122 Device install failed. Error 2: The system cannot find the file specified.
#E157 Default installer failed. Error 2: The system cannot find the file specified.
#W422 Coinstaller 1 (Post Processing) modified status. No Error.
It looks to me like it’s failing to install the service, because it’s trying to get a current configuration for the non-existing service. Below is the INF file I’m using - any suggestions for fixing this?
[Version]
Signature = “$Windows NT$”
Class = HIDClass
ClassGuid = {745a17a0-74d3-11d0-b6fe-00a0c90f57da}
Provider = %ProviderName%
DriverVer = 07/01/2008,1.0.0.0
CatalogFile = sixcd.cat
[Manufacturer]
%ProviderName% = MyDevice_HIDFilter,NTx86,NTamd64
[MyDevice_HIDFilter.NTx86]
%USB\MyDevice.DeviceDesc% =USB_Install, HID\VID_054C&PID_0268&REV_0100,USB\VID_054C&PID_0268,HID_DEVICE_SYSTEM_GAME
[MyDevice_HIDFilter.NTamd64]
%USB\MyDevice.DeviceDesc% =USB_Install, HID\VID_054C&PID_0268&REV_0100,USB\VID_054C&PID_0268,HID_DEVICE_SYSTEM_GAME
; ============================ Installation ============================
; [1]
[USB_Install]
CopyFiles = hidkmdf_CopyFiles, Filter_CopyFiles
[hidkmdf_CopyFiles]
hidkmdf.sys,0x00002000
[Filter_CopyFiles]
sixcd.sys,0x00002000
; [2]
[USB_Install.Services]
AddService = hidkmdf,0x00000002,hidkmdf_ServiceInstall
AddService = sixcd,0x00000002,Filter_ServiceInstall
; [3]
[hidkmdf_ServiceInstall]
DisplayName = %hidkmdf_SvcDesc%
ServiceType = 1 ;SERVICE_KERNEL_DRIVER
StartType = 3 ;SERVICE_DEMAND_START
ErrorControl = 1 ;SERVICE_ERROR_NORMAL
ServiceBinary = %12%\hidkmdf.sys
[Filter_ServiceInstall]
DisplayName = %Filter_SvcDesc%
ServiceType = 1 ;SERVICE_KERNEL_DRIVER
StartType = 3 ;SERVICE_DEMAND_START
ErrorControl = 0 ;SERVICE_ERROR_IGNORE
ServiceBinary = %12%\sixcd.sys
LoadOrderGroup = PNP Filter
; [4]
[USB_Install.Wdf]
KmdfService = sixcd,Filter_Install
[Filter_Install]
KmdfLibraryVersion = 1.7
; [5]
[USB_Install.HW]
AddReg = Fitler_AddReg
[Filter_AddReg]
HKR,“UpperFilter”,0x00010000,sixcd
; [6]
[USB_Install.CoInstallers]
AddReg = CoInstallers_AddReg
CopyFiles = CoInstallers_CopyFiles
[CoInstallers_AddReg]
HKR,CoInstallers32,0x00010000, “WdfCoInstaller01007.dll,WdfCoInstaller”
[CoInstallers_CopyFiles]
WdfCoInstaller01007.dll,0x00000010 ;COPYFLG_NO_OVERWRITE (for win2k)
[DestinationDirs]
DefaultDestDir = 12
CoInstallers_CopyFiles = 11
; ======================== Source Media Section ========================
; [7]
[SourceDiskNames]
1 = %DISK_NAME%,\i386
2 = %DISK_NAME%,\amd64
[SourceDiskFiles.x86]
hidkmdf.sys = 1
sixcd.sys = 1
WdfCoInstaller01007.dll=1 ; make sure the number matches with SourceDisksNames
[SourceDiskFiles.NTamd64]
hidkmdf.sys = 2
sixcd.sys = 2
WdfCoInstaller01007.dll=2 ; make sure the number matches with SourceDisksNames
; =============================== Strings ================================
[Strings]
ProviderName = “Mythgarr”
USB\MyDevice.DeviceDesc = “Sony PlayStation 3 Controller”
hidkmdf_SvcDesc = “HID KMDF Driver”
Filter_SvcDesc = “SIXCD PS3 Controller Filter”
DISK_NAME = “sixcd Install Disk”
Nevermind - I found the problem. The SIXCD service was still installed from a previous attempt, but the configuration registry entries were gone. Removing that service now allows the install to finish perfectly and the driver to start. It’s outputting text using DbgPrint() which is showing correctly in DebugView, so now it’s down to troubleshooting things I’m familiar with.
Thanks for all the help, guys! Couldn’t have done it without you.