Devcon or DPInst

NTDEV
1

I have been developing my software-only driver and installing it with Devcon, but I’ve run into a problem with Vista 64. When I run the 64-bit version of devcon on the 64-bit version of my driver with the OS booted in “ignore device signing” mode, I get the prompt confirming that I want to install the unsigned driver, and there it hangs. I have to Ctl-C out of the batch file that is running, and the driver is not installed. So I tried DPInst. This time everything ran to completion, but a message on the console log (/C option) said the installation was not complete as there was no matching device connected, and that it would complete when the device was connected and recognized. But as a software-only driver, that’s not going to happen. So I have a couple of questions:

  1. For software-only drivers that have to run on everything XP and later, which is preferred, Devcon or DPInst?

2a. If Devcon, what should I be looking for that would be causing the hang?

2b. If DPInst, what should I look for that would tell it this is a software-only driver and nothing would ever be connected?

2

xxxxx@novint.com wrote:

I have been developing my software-only driver and installing it with Devcon, but I’ve run into a problem with Vista 64. When I run the 64-bit version of devcon on the 64-bit version of my driver with the OS booted in “ignore device signing” mode, I get the prompt confirming that I want to install the unsigned driver, and there it hangs. I have to Ctl-C out of the batch file that is running, and the driver is not installed.

Are you sure you’re using the 64-bit Devcon? The 32-bit Devcon is about
2/3 functional in a 64-bit system, which can cause great confusion.

So I tried DPInst. This time everything ran to completion, but a message on the console log (/C option) said the installation was not complete as there was no matching device connected, and that it would complete when the device was connected and recognized. But as a software-only driver, that’s not going to happen.

Is this a root-enumerated driver? What does the PnP ID look like?
Someone has to enumerate your device ID in order to get your driver loaded.

Have you signed the driver for KMCS?

So I have a couple of questions:

  1. For software-only drivers that have to run on everything XP and later, which is preferred, Devcon or DPInst?

If you intend to ship this to others, I think DPInst is the answer.

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

3

As always, thanks for the help.

As to the 64-bit-ness of Devcon, I’ve double-checked and assured that I’ve copied Devcon out of the amd64 folder in tools/devcon. Same for DPInst.

If I understand correctly, this IS a root-enumerated driver. Here are the (I think) relevant excerpts from the .inf file:

%VHidMini% = VHidMini.Inst, {E4BBB798-47FB-4746-A3D2-5AB5CDCBE8BC}\HID_DEVICE

I can supply the whole .inf file if it would help.

I tried setting StartType = %SERVICE_SYSTEM_START% (= 1), and that had no effect.

I haven’t signed the driver for anything yet; my understanding was that the F8 option to boot without enforcing signing would allow me to get everything working before going through the signing process. I do that boot option everytime I boot Vista 64.

4

> I haven’t signed the driver for anything yet

A shot in the dark, but are you running dpinst with the /LM parameter? It’s
required if you’re installing an unsigned package.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
> As always, thanks for the help.
>
> As to the 64-bit-ness of Devcon, I’ve double-checked and assured that I’ve
> copied Devcon out of the amd64 folder in tools/devcon. Same for DPInst.
>
> If I understand correctly, this IS a root-enumerated driver. Here are the
> (I think) relevant excerpts from the .inf file:
>
> %VHidMini% = VHidMini.Inst,
> {E4BBB798-47FB-4746-A3D2-5AB5CDCBE8BC}\HID_DEVICE
>
> I can supply the whole .inf file if it would help.
>
> I tried setting StartType = %SERVICE_SYSTEM_START% (= 1), and that had no
> effect.
>
> I haven’t signed the driver for anything yet; my understanding was that
> the F8 option to boot without enforcing signing would allow me to get
> everything working before going through the signing process. I do that
> boot option everytime I boot Vista 64.
>

5

Yes, I am using /LM. (I’m taking a lot of shots in the dark myself, because I feel like that’s where I live.)

Let’s go back to first steps–which build environment should I be using? I do my development on an XP, Service Pack 3. I have installed WinDDK 7600.16385.0. Part of the installation process was to run “build -cZ” in the Windows X86-x86 Free build environment. To build the .sys file for the XP target, I used the XP/x86 Free build environment. For the amd64 build I use the Windows Vista and Server 2008/x64 Free environment. This combination gives me objfre_wxp_x86/i386 and objfree_wlh_amd64/amd64 folders in my project folder. Is that the right thing? If so, I guess eventually I’ll also need to use the Windows Vista and Server 2008/x86 environments to cover the Vista 32 world.

6

>For the amd64 build I use the Windows Vista and Server 2008/x64 Free

environment.

If you’re targeting XP x64, you need the Windows Server 2003 x64 build
environment. Not entirely intuitive, but XP x64 is the same code base as
Server 2003 x64.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
> Yes, I am using /LM. (I’m taking a lot of shots in the dark myself,
> because I feel like that’s where I live.)
>
> Let’s go back to first steps–which build environment should I be using?
> I do my development on an XP, Service Pack 3. I have installed WinDDK
> 7600.16385.0. Part of the installation process was to run “build -cZ” in
> the Windows X86-x86 Free build environment. To build the .sys file for
> the XP target, I used the XP/x86 Free build environment. For the amd64
> build I use the Windows Vista and Server 2008/x64 Free environment. This
> combination gives me objfre_wxp_x86/i386 and objfree_wlh_amd64/amd64
> folders in my project folder. Is that the right thing? If so, I guess
> eventually I’ll also need to use the Windows Vista and Server 2008/x86
> environments to cover the Vista 32 world.
>

7

Thanks. I’ll remember that when I get a demand for XP x64 support. It sounds like I have the basic build environment notion right.

Is any of my code being called during this step in the process? That is, is it time to break out a debugger? I had the impression that all that was happening here was file copying.

8

xxxxx@novint.com wrote:

As always, thanks for the help.

As to the 64-bit-ness of Devcon, I’ve double-checked and assured that I’ve copied Devcon out of the amd64 folder in tools/devcon. Same for DPInst.

If I understand correctly, this IS a root-enumerated driver. Here are the (I think) relevant excerpts from the .inf file:

%VHidMini% = VHidMini.Inst, {E4BBB798-47FB-4746-A3D2-5AB5CDCBE8BC}\HID_DEVICE

This is a root-enumerated device, but SOMEONE has to create the devnode
in order for it to be enumerated. When you use devcon, it calls
SetupDiCallClassInstaller, which does this function. When you use
dpinst, no one does that. Your driver is pre-installed, ready and
willing, but since there is no {E4BBB798-47FB-4746-A3D2-5AB5CDCBE8BC}
device, so your device will never be loaded.

So, to use dpinst, you will need some kind of installer to create the
devnode, heavily borrowing code from devcon.

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

9

It sounds like devcon might be a better choice. (?) Why does all this not fail in a similar way on XP?

10

… and too bad this does not exist as a feature of DIFx :frowning:

At one point in the early DIFx days I thought there was talk of supporting
the install of “Root Enumerated” singleton devices.

My, my, how handy that would have been.

Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, November 10, 2009 12:24 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Devcon or DPInst

xxxxx@novint.com wrote:

As always, thanks for the help.

As to the 64-bit-ness of Devcon, I’ve double-checked and assured that I’ve
copied Devcon out of the amd64 folder in tools/devcon. Same for DPInst.

If I understand correctly, this IS a root-enumerated driver. Here are the
(I think) relevant excerpts from the .inf file:

%VHidMini% = VHidMini.Inst,
{E4BBB798-47FB-4746-A3D2-5AB5CDCBE8BC}\HID_DEVICE

This is a root-enumerated device, but SOMEONE has to create the devnode
in order for it to be enumerated. When you use devcon, it calls
SetupDiCallClassInstaller, which does this function. When you use
dpinst, no one does that. Your driver is pre-installed, ready and
willing, but since there is no {E4BBB798-47FB-4746-A3D2-5AB5CDCBE8BC}
device, so your device will never be loaded.

So, to use dpinst, you will need some kind of installer to create the
devnode, heavily borrowing code from devcon.

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

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

11

> I haven’t signed the driver for anything yet; my understanding was
that

the F8 option to boot without enforcing signing would allow me to get
everything working before going through the signing process. I do
that
boot option everytime I boot Vista 64.

I think you have to still have to sign the driver, you can just use any
cert.

I am assuming that using F8 to change the signing stuff is the same as
using the TESTSIGNING Boot Configuration Option via BCDEdit.

http://msdn.microsoft.com/en-us/library/dd419910.aspx:

When the BCDEdit option for test-signing is enabled, Windows
does the following:

* …
* The operating system loader and the kernel load
drivers that are signed by any certificate. The certificate validation
is not required to chain up to a trusted root certification authority.
However, each driver image file must have a digital signature.

12

No it is not the same, using the F8 option allows one to install a totally
unsigned driver for that boot instance.

–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Dan Newton” wrote in message news:xxxxx@ntdev…
> I haven’t signed the driver for anything yet; my understanding was
that
> the F8 option to boot without enforcing signing would allow me to get
> everything working before going through the signing process. I do
that
> boot option everytime I boot Vista 64.

I think you have to still have to sign the driver, you can just use any
cert.

I am assuming that using F8 to change the signing stuff is the same as
using the TESTSIGNING Boot Configuration Option via BCDEdit.

http://msdn.microsoft.com/en-us/library/dd419910.aspx:

When the BCDEdit option for test-signing is enabled, Windows
does the following:

* …
* The operating system loader and the kernel load
drivers that are signed by any certificate. The certificate validation
is not required to chain up to a trusted root certification authority.
However, each driver image file must have a digital signature.

Information from ESET NOD32 Antivirus, version of virus signature
database 4593 (20091110)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Information from ESET NOD32 Antivirus, version of virus signature database 4593 (20091110)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

13

> No it is not the same, using the F8 option allows one to install a

totally
unsigned driver for that boot instance.

Ok, cheers for that clarification