DPInst: ERROR: Unable to start service 'xxxxxdriver' because of error 0x2

Hi Everyone,

I have a simple kmdf, non-PnP, software only device driver that installs and runs properly on Win7 and Vista 64-bit systems. It does use WdfCoInstaller01009.dll, which exists in C:\WINDOWS\SYSTEM32. We are getting ready for testing on WinXP Pro SP3, 32-bit so I copied the x86 version of DPInst and our Authenticode signed driver package to the WinXP computer and installed it. The installation looked good, but when I try to start the service/driver, I get a “Error 2: The system cannot find the file specified.” error. Further, the DPInst log, which follows, reports a similar error. I have no idea what file it is referring to since our driver and the coinstaller are in the proper places. I would really appreciate any ideas and suggestions!

Thank you for your time!

Mike


C:\PROJECTS\XXXXXDriver>C:\PROJECTS\XXXXXDriver\DEPLOYMENT\DPInst\x86\DPInst.exe
/PATH C:\PROJECTS\XXXXXDriver\DEPLOYMENT\Drivers\x86 /C /F
INFO: Option set: dumping log info to console.
INFO: Current working directory: 'C:\PROJECTS\XXXXXDriver\DEPLOYMENT\DPInst\x86

INFO: Running on path ‘C:\PROJECTS\XXXXXDriver\DEPLOYMENT\Drivers\x86’
INFO: No valid ‘dpinst.xml’ file provided.
INFO: Install option set: Force install if driver is not better.
INFO: Found driver package: ‘C:\PROJECTS\XXXXXDriver\DEPLOYMENT\Drivers\x86\abo
hdriver.inf’.
INFO: Preinstalling ‘c:\projects\xxxxxdriver\deployment\drivers\x86\xxxxxdriver.
inf’ …
INFO: ENTER: DriverPackagePreinstallW
ERROR: Preinstall is not a supported operation for driver type 1
INFO: RETURN: DriverPackagePreinstallW (0x1)
INFO: ENTER: DriverPackageGetPathW
INFO: No driver store entry for c:\projects\xxxxxdriver\deployment\drivers\x86\
xxxxxdriver.inf found. (Error code 0xE0000302.)
INFO: RETURN: DriverPackageGetPathW (0xE0000302)
INFO: ENTER: DriverPackageInstallW
INFO: xxxxxdriver.inf: checking signature with catalog ‘c:\projects\xxxxxdriver\
deployment\drivers\x86\xxxxxdriver.cat’ …
INFO: Driver package ‘xxxxxdriver.inf’ is Authenticode signed.
INFO: Copied ‘xxxxxdriver.inf’ to driver store…
INFO: Copied ‘xxxxxdriver.cat’ to driver store…
INFO: Commiting queue…
INFO: Copied file: ‘c:\projects\xxxxxdriver\deployment\drivers\x86\xxxxxdriver.s
ys’ -> ‘C:\WINDOWS\system32\DRVSTORE\xxxxxdriver_163DEA58C87E3DE7E04B5F5A5BFCFD58
3A1D8239\xxxxxdriver.sys’.
INFO: Installing INF file “C:\WINDOWS\system32\DRVSTORE\xxxxxdriver_163DEA58C87
E3DE7E04B5F5A5BFCFD583A1D8239\xxxxxdriver.inf” of Type 1.
INFO: Installing legacy driver ‘C:\WINDOWS\system32\DRVSTORE\xxxxxdriver_163DEA
58C87E3DE7E04B5F5A5BFCFD583A1D8239\xxxxxdriver.inf’
ERROR: Unable to start service ‘xxxxxdriver’ because of error 0x2
SUCCESS:Installation completed with code 0x0.
INFO: RETURN: DriverPackageInstallW (0x0)
INFO: ENTER: DriverPackageGetPathW
SUCCESS:Found driver store entry.
INFO: RETURN: DriverPackageGetPathW (0x0)
INFO: Successfull installation of ‘c:\projects\xxxxxdriver\deployment\drivers\x
86\xxxxxdriver.inf’.
INFO: Created entry in Add or Remove Programs for ‘C:\WINDOWS\system32\DRVSTOR
E\xxxxxdriver_163DEA58C87E3DE7E04B5F5A5BFCFD583A1D8239\xxxxxdriver.inf’.
INFO: Machine will have to be rebooted to complete installation.

Hi,

Dont know if this helps, but have you checked the setupapi logs in the same location of dpinst.log, it may have some additional information. Also have you checked you registry settings for the service, that it is pointing to the right place?

Steve

Are you using the install source and executable of the nonPnP example to register and replace the XP SP3 co-installer with 01009 from the latest WDK?

Gary G. Little

----- Original Message -----
From: xxxxx@a-bit-of-help.com
To: “Windows System Software Devs Interest List”
Sent: Tuesday, March 29, 2011 2:34:55 AM
Subject: [ntdev] DPInst: ERROR: Unable to start service ‘xxxxxdriver’ because of error 0x2

Hi Everyone,

I have a simple kmdf, non-PnP, software only device driver that installs and runs properly on Win7 and Vista 64-bit systems. It does use WdfCoInstaller01009.dll, which exists in C:\WINDOWS\SYSTEM32. We are getting ready for testing on WinXP Pro SP3, 32-bit so I copied the x86 version of DPInst and our Authenticode signed driver package to the WinXP computer and installed it. The installation looked good, but when I try to start the service/driver, I get a “Error 2: The system cannot find the file specified.” error. Further, the DPInst log, which follows, reports a similar error. I have no idea what file it is referring to since our driver and the coinstaller are in the proper places. I would really appreciate any ideas and suggestions!

Thank you for your time!

Mike

------------------------------------
C:\PROJECTS\XXXXXDriver>C:\PROJECTS\XXXXXDriver\DEPLOYMENT\DPInst\x86\DPInst.exe
/PATH C:\PROJECTS\XXXXXDriver\DEPLOYMENT\Drivers\x86 /C /F
INFO: Option set: dumping log info to console.
INFO: Current working directory: ‘C:\PROJECTS\XXXXXDriver\DEPLOYMENT\DPInst\x86

INFO: Running on path ‘C:\PROJECTS\XXXXXDriver\DEPLOYMENT\Drivers\x86’
INFO: No valid ‘dpinst.xml’ file provided.
INFO: Install option set: Force install if driver is not better.
INFO: Found driver package: ‘C:\PROJECTS\XXXXXDriver\DEPLOYMENT\Drivers\x86\abo
hdriver.inf’.
INFO: Preinstalling ‘c:\projects\xxxxxdriver\deployment\drivers\x86\xxxxxdriver.
inf’ …
INFO: ENTER: DriverPackagePreinstallW
ERROR: Preinstall is not a supported operation for driver type 1
INFO: RETURN: DriverPackagePreinstallW (0x1)
INFO: ENTER: DriverPackageGetPathW
INFO: No driver store entry for c:\projects\xxxxxdriver\deployment\drivers\x86\
xxxxxdriver.inf found. (Error code 0xE0000302.)
INFO: RETURN: DriverPackageGetPathW (0xE0000302)
INFO: ENTER: DriverPackageInstallW
INFO: xxxxxdriver.inf: checking signature with catalog ‘c:\projects\xxxxxdriver\
deployment\drivers\x86\xxxxxdriver.cat’ …
INFO: Driver package ‘xxxxxdriver.inf’ is Authenticode signed.
INFO: Copied ‘xxxxxdriver.inf’ to driver store…
INFO: Copied ‘xxxxxdriver.cat’ to driver store…
INFO: Commiting queue…
INFO: Copied file: ‘c:\projects\xxxxxdriver\deployment\drivers\x86\xxxxxdriver.s
ys’ -> ‘C:\WINDOWS\system32\DRVSTORE\xxxxxdriver_163DEA58C87E3DE7E04B5F5A5BFCFD58
3A1D8239\xxxxxdriver.sys’.
INFO: Installing INF file “C:\WINDOWS\system32\DRVSTORE\xxxxxdriver_163DEA58C87
E3DE7E04B5F5A5BFCFD583A1D8239\xxxxxdriver.inf” of Type 1.
INFO: Installing legacy driver ‘C:\WINDOWS\system32\DRVSTORE\xxxxxdriver_163DEA
58C87E3DE7E04B5F5A5BFCFD583A1D8239\xxxxxdriver.inf’
ERROR: Unable to start service ‘xxxxxdriver’ because of error 0x2
SUCCESS:Installation completed with code 0x0.
INFO: RETURN: DriverPackageInstallW (0x0)
INFO: ENTER: DriverPackageGetPathW
SUCCESS:Found driver store entry.
INFO: RETURN: DriverPackageGetPathW (0x0)
INFO: Successfull installation of ‘c:\projects\xxxxxdriver\deployment\drivers\x
86\xxxxxdriver.inf’.
INFO: Created entry in Add or Remove Programs for ‘C:\WINDOWS\system32\DRVSTOR
E\xxxxxdriver_163DEA58C87E3DE7E04B5F5A5BFCFD583A1D8239\xxxxxdriver.inf’.
INFO: Machine will have to be rebooted to complete installation.


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

xxxxx@a-bit-of-help.com wrote:

Hi Everyone,

I have a simple kmdf, non-PnP, software only device driver that installs and runs properly on Win7 and Vista 64-bit systems. It does use WdfCoInstaller01009.dll, which exists in C:\WINDOWS\SYSTEM32. We are getting ready for testing on WinXP Pro SP3, 32-bit so I copied the x86 version of DPInst and our Authenticode signed driver package to the WinXP computer and installed it. The installation looked good, but when I try to start the service/driver, I get a “Error 2: The system cannot find the file specified.” error. Further, the DPInst log, which follows, reports a similar error. I have no idea what file it is referring to since our driver and the coinstaller are in the proper places. I would really appreciate any ideas and suggestions!

We just went over this not two weeks ago. DPInst cannot be used to
install a non-PnP driver. DPInst is all about pre-installation, and
pre-installation is a mechanism that only applies to PnP drivers.

Installing a non-PnP driver is just a matter of copying the files into
place and adding the service. You can do that with an INF using a
[DefaultInstall] section, or you can use a simple application, or even a
batch file. See the src\general\ioctl\kmdf sample in the DDK for an
example of installing a non-PnP KMDF driver.

(The batch file won’t work if you also need to run the co-installer.)


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

Hello Everyone,

Based on your comments, I’ve focused my investigation on the Wdf Coinstaller file since our driver has been properly loaded into the drivers directory by DPInst. When I looked at our .inx file, I noticed a few errors, so I’ve corrected them. Since the CoInstaller was already installed on our Win7, 64-bit system, this issue did not arise. But, now that we are trying to install on a WinXP SP3, 32-bit system, which doesn’t have the CoInstaller on it, we’ve bumped into this problem.

Anyway, I’ve made changes to our .inx file, but the CoInstaller is not installing on the WinXP computer. I’ve looked in the setupact.log file, but there were no entries after installing our driver. According to MSDN, the CoInstaller only adds entries on Vista and newer OSs, so it doesn’t appear to help.

Anyway, could you please take a peek at our .inx file as a sanity check for the CoInstaller installation? I’ve reviewed it about 20x today and think that I am too close to it. I am going to have some lunch and look again… Our driver is a non-PnP, kmdf, software only service.

Thank you for your ongoing help with this issue!

Mike

====================== OUR .INX FILE =======================
;/*++
;
;Copyright (c) 2010-2011 A Bit of Help, Inc., All rights reserved.
;
;Module Name:
;
; abohdriver.inf
;
;Abstract:
; INF file for installing our kernel service.
;
;–*/

[Version]
Signature=“$WINDOWS NT$”
Class=System
ClassGuid={4d36e97d-e325-11ce-bfc1-08002be10318}
Provider=%ABOH%
; You may need to change this version in abohdriver.rc.
DriverVersion=%DRIVER_TIMESTAMP%,%DRIVER_VERSION%
DriverPackageType=KernelService
CatalogFile=abohdriver.cat

;*****************************************
; abohdriver Device Installation Section
;*****************************************
[SourceDisksNames]
1 = %DiskId1%,“”

[SourceDisksFiles]
abohdriver.sys = 1,

[DestinationDirs]
DefaultDestDir = 12

[Manufacturer]
%AbohMfg%=AbohMgf,NT$ARCH$

[AbohDriver_Device.NT]
CopyFiles=AbohDriver_Device_CopyFiles.NT

[AbohDriver.NT.Services]
AddService = abohdriver, %SPSVCINST_ASSOCSERVICE%, abohdriver_Service_Inst

[DefaultInstall.NT]
; Using .NT platform extension so this section will not be executed on Win9x/ME.
CopyFiles=AbohDriver_Device_CopyFiles.NT

[DefaultInstall.NT.Services]
AddService = abohdriver, %SPSVCINST_ASSOCSERVICE%, abohdriver_Service_Inst

[AbohDriver_Device_CopyFiles.NT]
abohdriver.sys

;-------------- Service installation
[abohdriver_Service_Inst]
DisplayName = %abohdriver.SvcDesc%
ServiceType = %SERVICE_KERNEL_DRIVER%
StartType = %SERVICE_DEMAND_START%
ErrorControl = %SERVICE_ERROR_NORMAL%
ServiceBinary = %12%\abohdriver.sys
LoadOrderGroup = Extended Base

;*****************************************
; WDF CoInstaller Installation Section
;*****************************************
[DestinationDirs]
CoInstaller_CopyFiles = 11

; Normal installation

[Wdf_CoInstaller.NT.CoInstallers]
AddReg=CoInstaller_AddReg
CopyFiles=CoInstaller_CopyFiles

[Wdf_CoInstaller.NT.Wdf]
KmdfService = AbohDriver, Wdf_CoInstaller_wdfsect

[Wdf_CoInstaller_wdfsect]
KmdfLibraryVersion = $KMDFVERSION$

; Default installation

[DefaultInstall.NT.CoInstallers]
AddReg=CoInstaller_AddReg
CopyFiles=CoInstaller_CopyFiles

[DefaultInstall.NT.Wdf]
KmdfService = AbohDriver, Wdf_CoInstaller_wdfsect

; Common

[CoInstaller_AddReg]
HKR,CoInstallers32,0x00010000,“WdfCoinstaller$KMDFCOINSTALLERVERSION$.dll,WdfCoInstaller”

[CoInstaller_CopyFiles]
WdfCoinstaller$KMDFCOINSTALLERVERSION$.dll,2

[SourceDiskFiles]
WdfCoInstaller$KMDFCOINSTALLERVERSION$.dll=1

[Strings]
ABOH = “A Bit of Help”
AbohMfg = “A Bit of Help, Inc.”
DiskId1 = “A Bit of Help’s Kernel Services Installation Disk #1
abohdriverDevice.DeviceDesc = “Kernel Services for ABOH”
abohdriver.SvcDesc = “A Bit of Help’s kernel services”
DRIVER_TIMESTAMP = “03/03/2011”
DRIVER_VERSION = “1.0.0.0”

; Useful Constants
SERVICE_KERNEL_DRIVER = 1
SERVICE_DEMAND_START = 3
SERVICE_BOOT_START = 0 ; Requires a reboot!
SERVICE_ERROR_NORMAL = 1
SPSVCINST_ASSOCSERVICE = 0x00000002

Oh, by the way… As you will see in the .inx file, we are supporting default installation and standard installation methods.

Tim pointed out that DPInst cannot install non-PnP drivers, but it seems to work well on our Win7, 64-bit development computer and our Vista, 64-bit test computer. We use it all day long to install the latest version as we do development… I am not getting any errors using DPInst on the WinXP system, but it may be too soon to tell on it since I am having coinstaller installation issues. I wonder whether DPInst will install non-PnP on the newer OSs, but not on WinXP. I’d be curious to learn more…

… If we have just been lucky in using DPInst and really should not use it, ee can do as Tim recommended and copy our driver into the drivers folder. As far as installing the CoInstaller, in another posting, Doron mentioned creating our own app to install it. Is that what you did, Tim? I assume that if I create this installer application, then I can remove the CoInstaller sections from our .inx file. I will take a look at the example that Doron mentioned at
src\general\ioctl\kmdf\exe\install.c.

I have used dpinst to install class filter drivers which are installed as
non-pnp drivers. I don’t remember the exact parameter but you need to
specify legacyMode. As far as I recall, the only advantage to dpinst for
non-pnp drivers is that it adds an entry in Add/remove programs.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@a-bit-of-help.com
Sent: Tuesday, March 29, 2011 6:16 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DPInst: ERROR: Unable to start service ‘xxxxxdriver’
because of error 0x2

Oh, by the way… As you will see in the .inx file, we are supporting
default installation and standard installation methods.

Tim pointed out that DPInst cannot install non-PnP drivers, but it seems to
work well on our Win7, 64-bit development computer and our Vista, 64-bit
test computer. We use it all day long to install the latest version as we
do development… I am not getting any errors using DPInst on the WinXP
system, but it may be too soon to tell on it since I am having coinstaller
installation issues. I wonder whether DPInst will install non-PnP on the
newer OSs, but not on WinXP. I’d be curious to learn more…


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

No guarantees, but how about posting the INF file as well?

How are you installing the CoInstaller?

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@a-bit-of-help.com
Sent: Tuesday, March 29, 2011 5:09 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DPInst: ERROR: Unable to start service ‘xxxxxdriver’
because of error 0x2

Hello Everyone,

Based on your comments, I’ve focused my investigation on the Wdf Coinstaller
file since our driver has been properly loaded into the drivers directory by
DPInst. When I looked at our .inx file, I noticed a few errors, so I’ve
corrected them. Since the CoInstaller was already installed on our Win7,
64-bit system, this issue did not arise. But, now that we are trying to
install on a WinXP SP3, 32-bit system, which doesn’t have the CoInstaller on
it, we’ve bumped into this problem.

Anyway, I’ve made changes to our .inx file, but the CoInstaller is not
installing on the WinXP computer. I’ve looked in the setupact.log file, but
there were no entries after installing our driver. According to MSDN, the
CoInstaller only adds entries on Vista and newer OSs, so it doesn’t appear
to help.

Anyway, could you please take a peek at our .inx file as a sanity check for
the CoInstaller installation? I’ve reviewed it about 20x today and think
that I am too close to it. I am going to have some lunch and look again…
Our driver is a non-PnP, kmdf, software only service.

Thank you for your ongoing help with this issue!

Mike

====================== OUR .INX FILE ======================= ;/*++ ;
;Copyright (c) 2010-2011 A Bit of Help, Inc., All rights reserved.
;
;Module Name:
;
; abohdriver.inf
;
;Abstract:
; INF file for installing our kernel service.
;
;–*/

[Version]
Signature=“$WINDOWS NT$”
Class=System
ClassGuid={4d36e97d-e325-11ce-bfc1-08002be10318}
Provider=%ABOH%
; You may need to change this version in abohdriver.rc.
DriverVersion=%DRIVER_TIMESTAMP%,%DRIVER_VERSION%
DriverPackageType=KernelService
CatalogFile=abohdriver.cat

;*****************************************
; abohdriver Device Installation Section
;*****************************************
[SourceDisksNames]
1 = %DiskId1%,“”

[SourceDisksFiles]
abohdriver.sys = 1,

[DestinationDirs]
DefaultDestDir = 12

[Manufacturer]
%AbohMfg%=AbohMgf,NT$ARCH$

[AbohDriver_Device.NT]
CopyFiles=AbohDriver_Device_CopyFiles.NT

[AbohDriver.NT.Services]
AddService = abohdriver, %SPSVCINST_ASSOCSERVICE%, abohdriver_Service_Inst

[DefaultInstall.NT]
; Using .NT platform extension so this section will not be executed on
Win9x/ME.
CopyFiles=AbohDriver_Device_CopyFiles.NT

[DefaultInstall.NT.Services]
AddService = abohdriver, %SPSVCINST_ASSOCSERVICE%, abohdriver_Service_Inst

[AbohDriver_Device_CopyFiles.NT]
abohdriver.sys

;-------------- Service installation
[abohdriver_Service_Inst]
DisplayName = %abohdriver.SvcDesc%
ServiceType = %SERVICE_KERNEL_DRIVER%
StartType = %SERVICE_DEMAND_START%
ErrorControl = %SERVICE_ERROR_NORMAL%
ServiceBinary = %12%\abohdriver.sys
LoadOrderGroup = Extended Base

;*****************************************
; WDF CoInstaller Installation Section
;*****************************************
[DestinationDirs]
CoInstaller_CopyFiles = 11

; Normal installation

[Wdf_CoInstaller.NT.CoInstallers]
AddReg=CoInstaller_AddReg
CopyFiles=CoInstaller_CopyFiles

[Wdf_CoInstaller.NT.Wdf]
KmdfService = AbohDriver, Wdf_CoInstaller_wdfsect

[Wdf_CoInstaller_wdfsect]
KmdfLibraryVersion = $KMDFVERSION$

; Default installation

[DefaultInstall.NT.CoInstallers]
AddReg=CoInstaller_AddReg
CopyFiles=CoInstaller_CopyFiles

[DefaultInstall.NT.Wdf]
KmdfService = AbohDriver, Wdf_CoInstaller_wdfsect

; Common

[CoInstaller_AddReg]
HKR,CoInstallers32,0x00010000,“WdfCoinstaller$KMDFCOINSTALLERVERSION$.dll,W
dfCoInstaller”

[CoInstaller_CopyFiles]
WdfCoinstaller$KMDFCOINSTALLERVERSION$.dll,2

[SourceDiskFiles]
WdfCoInstaller$KMDFCOINSTALLERVERSION$.dll=1

[Strings]
ABOH = “A Bit of Help”
AbohMfg = “A Bit of Help, Inc.”
DiskId1 = “A Bit of Help’s Kernel Services
Installation Disk #1
abohdriverDevice.DeviceDesc = “Kernel Services for ABOH”
abohdriver.SvcDesc = “A Bit of Help’s kernel services”
DRIVER_TIMESTAMP = “03/03/2011”
DRIVER_VERSION = “1.0.0.0”

; Useful Constants
SERVICE_KERNEL_DRIVER = 1
SERVICE_DEMAND_START = 3
SERVICE_BOOT_START = 0 ; Requires a reboot!
SERVICE_ERROR_NORMAL = 1
SPSVCINST_ASSOCSERVICE = 0x00000002


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

__________ Information from ESET Smart Security, version of virus signature
database 5998 (20110329) __________

The message was checked by ESET Smart Security.

http://www.eset.com

Take a look at the Install program included in the …\src\general\ioctl\exe
directory of the WDK. You have the source file there that demonstrates how
to install your driver with the correct version of the WDF co-installer.
Within 20 minutes you should know if installing the driver and co-installer
on XP SP3 is going to work.

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@a-bit-of-help.com
Sent: Tuesday, March 29, 2011 5:31 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DPInst: ERROR: Unable to start service ‘xxxxxdriver’
because of error 0x2

… If we have just been lucky in using DPInst and really should not use it,
ee can do as Tim recommended and copy our driver into the drivers folder.
As far as installing the CoInstaller, in another posting, Doron mentioned
creating our own app to install it. Is that what you did, Tim? I assume
that if I create this installer application, then I can remove the
CoInstaller sections from our .inx file. I will take a look at the example
that Doron mentioned at src\general\ioctl\kmdf\exe\install.c.


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

__________ Information from ESET Smart Security, version of virus signature
database 5998 (20110329) __________

The message was checked by ESET Smart Security.

http://www.eset.com

Hi Everyone,

I’ve reviewed the installer code that you’ve recommended and it is pretty straight forward, but I haven’t use the setupapi before so I am hoping that you can clarify some things for me…

Basically, the battle plan is to create our own installer based on the example code that you’ve mentioned. Will we have the same kind of benefits as using DPInst? Or, even better since we will be able to install the CoInstaller! :stuck_out_tongue: Anyway, will the setupapi code do version checking and updating? For example, when a customer installs a version of our driver, will the setupapi in our custom installer detect that an older or newer version one is already present? Will the setupapi code that installs the Wdf Coinstaller do the same kind of install/update? If so, then it would be a simple matter to deploy using our own installer application.

We deploy our applications using InstallShield and I have sent them a query as to how other customers, who have non-PnP kernel services using the Wdf Framework, are using their product for deployment. I’ll pass along what I learn from them as well as the results of my experiment with our own installer application.

More to follow…

Thanks for your comments and suggestions!
Mike

I’ve never used DpInst, so I cannot compare the two, but my WFP driver
installed quite well using a modified install app from the WDK sources. That
install app does not use SetupApi either; it loads the WDF co-installer as a
DLL, grabs the pointers to the function it needs, and then calls them to
load and register the version of KMDF you include in the deliverable. It
will also create service entries in the registry, and can start services and
or drivers.

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@a-bit-of-help.com
Sent: Wednesday, March 30, 2011 3:54 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DPInst: ERROR: Unable to start service ‘xxxxxdriver’
because of error 0x2

Hi Everyone,

I’ve reviewed the installer code that you’ve recommended and it is pretty
straight forward, but I haven’t use the setupapi before so I am hoping that
you can clarify some things for me…

Basically, the battle plan is to create our own installer based on the
example code that you’ve mentioned. Will we have the same kind of benefits
as using DPInst? Or, even better since we will be able to install the
CoInstaller! :stuck_out_tongue: Anyway, will the setupapi code do version checking and
updating? For example, when a customer installs a version of our driver,
will the setupapi in our custom installer detect that an older or newer
version one is already present? Will the setupapi code that installs the
Wdf Coinstaller do the same kind of install/update? If so, then it would be
a simple matter to deploy using our own installer application.

We deploy our applications using InstallShield and I he sent them a query as
to how other customers, who have non-PnP kernel services using the Wdf
Framework, are using their product for deployment. I’ll pass along what I
learn from them as well as the results of my experiment with our own
installer application.

More to follow…

Thanks for your comments and suggestions!
Mike


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

__________ Information from ESET Smart Security, version of virus signature
database 6001 (20110330) __________

The message was checked by ESET Smart Security.

http://www.eset.com

Hi Gary,

Thank you for responding! I see the DLL exports and library load/unload code… I couldn’t find anything online for these exported Wdf Coinstaller functions, but the code is not very complex. I made a quick change to the example app, but, unfortunately, I received some runtime errors (error 1062 and 1060) and a message saying that our driver didn’t load. The driver package and coinstaller were all in the same directory. So, I am going to have to take a closer look at things after I return from a business trip I am on.

Gary, since we are talking about installing the WdfCoinstaller, I am wondering whether there are risks for collateral damage… Here are some assumptions…

I assume that installing a newer version of the Wdf Coinstaller does not cause any issues with other drivers because it is new and would be used by our driver.

I assume that we never want to uninstall a Wdf Coinstaller because other drivers may be using it.

I assume that multiple versions of the Wdf Coinstaller can be installed on a single computer.

Are these correct assumptions?

Thank you for your help! :slight_smile:
Mike
However, I assume that we never want to uninstall the WdfCoinstaller because others may be using it, over time. Is this

Oops! Please disregard the fragments after my name… Cut-n-paste junk… :slight_smile:

Replacing an existing WDF is going to require a reboot, since the resource may be held by multiple drivers using KMDF. You won’t interfere with the existing KMDF drivers, but you won’t be able to launch your driver until you’ve rebooted, and loaded the new WDF. WDF is supposed be compatible across all WDF drivers so unless you have a badly written KMDF driver there should be virtually no impact by updating WDF versions. If WDF is not currently being used, such as a new XP SP3 installation, you most likely will NOT have to reboot. Only ONE version of WDF may run on a given system, though Doron (as well as Mark, Tim and DON) will kick me in the shins if that statement is incorrect , hence you have to REPLACE any existing version and reboot.

Pay attention to the INF decorations you are using. As I recall I had to “adjust” some of the INF decorations to allow the Installer app to find the proper section in the INF file. You mentioned INX early on, the input to StampINF which “compiles” INX to INF. You want the INF file. Oh, yeah, given that, the INF, SYS, WDF DLL and .exe must all be in the same directory. I created a quick and dirty MSI project to keep all of that consistent.

Gary G. Little

----- Original Message -----
From: xxxxx@a-bit-of-help.com
To: “Windows System Software Devs Interest List”
Sent: Wednesday, March 30, 2011 9:55:56 PM
Subject: RE:[ntdev] DPInst: ERROR: Unable to start service ‘xxxxxdriver’ because of error 0x2

Hi Gary,

Thank you for responding! I see the DLL exports and library load/unload code… I couldn’t find anything online for these exported Wdf Coinstaller functions, but the code is not very complex. I made a quick change to the example app, but, unfortunately, I received some runtime errors (error 1062 and 1060) and a message saying that our driver didn’t load. The driver package and coinstaller were all in the same directory. So, I am going to have to take a closer look at things after I return from a business trip I am on.

Gary, since we are talking about installing the WdfCoinstaller, I am wondering whether there are risks for collateral damage… Here are some assumptions…

I assume that installing a newer version of the Wdf Coinstaller does not cause any issues with other drivers because it is new and would be used by our driver.

I assume that we never want to uninstall a Wdf Coinstaller because other drivers may be using it.

I assume that multiple versions of the Wdf Coinstaller can be installed on a single computer.

Are these correct assumptions?

Thank you for your help! :slight_smile:
Mike
However, I assume that we never want to uninstall the WdfCoinstaller because others may be using it, over time. Is this


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

xxxxx@a-bit-of-help.com wrote:

I assume that installing a newer version of the Wdf Coinstaller does not cause any issues with other drivers because it is new and would be used by our driver.

That is an incorrect assumption. The kernel part of KMDF is called
wdf01000.sys, regardless of the version, and there is exactly one copy
of it. When it needs to be updated, that file has to be replaced. That
can’t be done if there is a driver already using it. So, if you have
KMDF drivers already running and you need to install a newer version, a
reboot will be required. The co-installer will handle that for you.

I assume that we never want to uninstall a Wdf Coinstaller because other drivers may be using it.

I don’t like your wording, although the sentiment is correct. The
co-installer is just a user-mode helper DLL that copies the KMDF runtime
driver (wdf01000.sys) into place. You never uninstall KMDF.

I assume that multiple versions of the Wdf Coinstaller can be installed on a single computer.

No, this is incorrect. There is exactly one copy of KMDF installed at
any given time. The co-installer will check the version number. If the
installed version is greater than or equal to the one you want, it does
nothing. Otherwise, it schedules an update and forces a reboot.


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

Hi Gary & Tim,

I apologize for my tardy response but I had to travel abroad for some work and the Internet in Siberia was not the best in the world!

Thank you very much for clearing up my confusion about the WDF CoInstaller! I’ve followed Doron’s & Gary’s advice and created our own installer based on the example. It is working well, but I have two additional things to adjust to make it ready for production…

  1. Is it possible to determine the version of a service? I looked at the Service Control Manager and its queries don’t return it. I would like our installer to log version information when it replaces an instance of our driver.

  2. What is the bare minimum that an INX file should contain for installing our driver and WDF CoInstaller on 32/64 bit systems? When I tried to strip our INX down to the bare minimums, inf2cat failed. Signing is important especially for x64 systems… The following is what I tried to use in the INX file… Our custom installer is looking for the WDF section “[abohdriver_Service_kmdfInst]”.


[Version]
Signature=“$WINDOWS NT$”
Class=System
ClassGuid={4d36e97d-e325-11ce-bfc1-08002be10318}
Provider=%ABOH%
DriverVer=%DRIVER_TIMESTAMP%,%DRIVER_VERSION%
DriverPackageType=KernelService
CatalogFile=abohdriver.cat

;*****************************************
; WDF CoInstaller Installation Section
;*****************************************
[abohdriver_Service_kmdfInst]
KmdfService = AbohDriver, Wdf_CoInstaller_wdfsect

[Wdf_CoInstaller_wdfsect]
KmdfLibraryVersion = $KMDFVERSION$

; Common

; Strings
[Strings]
ABOH = “A Bit of Help”
AbohMfg = “A Bit of Help, Inc.”
DiskId1 = “A Bit of Help’s Kernel Services Installation Disk #1
abohdriverDevice.DeviceDesc = “Kernel Services for ABOH”
abohdriver.SvcDesc = “A Bit of Help’s kernel services”
DRIVER_TIMESTAMP = “03/03/2011”
DRIVER_VERSION = “1.0.0.0”

; Useful Constants
SERVICE_KERNEL_DRIVER = 1
SERVICE_DEMAND_START = 3
SERVICE_BOOT_START = 0 ; Requires a reboot!
SERVICE_ERROR_NORMAL = 1

Thank you for your help with these final issues!

Mike

P.S. I am still waiting to hear from InstallShield as to whether it can be used instead of our custom installer. It is trivial to copy our driver to system32\drivers and I see in their documentation where we can load a service, but I don’t know whether it can be used to install the WDF CoInstaller, especially since in our custom installer there are pre and post WDF calls to be made before creating our service entry and getting WDF’s entry points when loading the library. In the end, it will probably be easier to just use our custom installer, which returns WIN32 errors to the OS, and call it when our application’s InstallShield installer is run. Anyway, I will post what I learn from IS.

xxxxx@a-bit-of-help.com wrote:

  1. Is it possible to determine the version of a service? I looked at the Service Control Manager and its queries don’t return it. I would like our installer to log version information when it replaces an instance of our driver.

Not through the service manager. You get the version by reading the
driver binary as a data file, using GetFileVersionInfoSize,
GetFileVersionInfo, and VerQueryValue.

  1. What is the bare minimum that an INX file should contain for installing our driver and WDF CoInstaller on 32/64 bit systems? When I tried to strip our INX down to the bare minimums, inf2cat failed. Signing is important especially for x64 systems… The following is what I tried to use in the INX file… Our custom installer is looking for the WDF section “[abohdriver_Service_kmdfInst]”.

For a service (“legacy driver”), just sign the driver binary. You don’t
use a CAT file.


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

Thanks for your help, Tim! I’m working on the installer this afternoon, so I can implement your suggestions. Wow! This thread has been really helpful for the development of our kmdf, nonPnP, legacy driver, and I am sure that it will help others, too!

Thank you again, Tim!

Mike

Hi Tim,

All of your suggestions worked perfectly! WooHoo! :slight_smile: Thank you!

Mike