Wrinting an Installer

I wrote earlier in the week about some issues I had getting my INF file to work. I managed to get the drivers installed and they work with XP and Win 7 in both Admin and non-admin mode. (Thanks for all the help!)

Customers are going to have to install this update themselves, so I have been looking for a way to install the drivers in some way other than going through the Add Hardware Wizard (the hardware is non PnP, one card dats back to 1988) which has many steps and most users of recent versions of Windows have probably never used it.

I started looking at devcon.exe, but I could not get it to work. The error messages in setupapi.log indicated that some file was missing, but the driver was getting copied OK and the INF was being found.

I did find the source code for devcon in the DDK and wrote a quick and dirty MFC dialog program that encapsulates just the install functions from devcon with a simple GUI interface. In devcon, cmdInstall() calls cmdUpdate() at the end, so I ported both of those functions to my app.

All functions in the install chain are working OK except the last call in cmdUpdate(). There is a call to GetProcAddress, which retrieves a pointer to UpdateDriverForPlugAndPlayDevices() in newdev.dll. That succeeds, but then the call to the function fails. The information I found about the function says that if UpdateDriverForPlugAndPlayDevices() fails, it will return FALSE and the error can be retrieved with GetLastError(), which I did. I don’t know if the extra step of calling the function from a pointer messed up GetLastError(), but it is returning 0xe0000203 (-536870397 decimal).

Specific code is at the bottom of this message. The only thing I changed in this code from devon’s implementation is to change the first argument of UpdateFn from Null to m_hWnd because the description of UpdateDriverForPlugAndPlayDevices() said the first argument was the top level handle in a GUI program. It didn’t make any difference.

I also changed the call arguments of the functions to the INF file name and the HWID string (“ROOT\IODEVICE”), but the other calls in the two functions work, so I don’t think there is anything amiss with the arguments. I stripped out a few command line checks that aren’t relevant, but those are the only changes I made to these functions.

I’m not sure UpdateDriverForPlugAndPlayDevices() is the right thing to call here as it is a self described Plug and Play function and the hardware is not PnP.

Definitions:
typedef BOOL (WINAPI *UpdateDriverForPlugAndPlayDevicesProto)(__in HWND hwndParent,__in LPCTSTR HardwareId,
__in LPCTSTR FullInfPath,__in DWORD InstallFlags,
__out_opt PBOOL bRebootRequired);
#ifdef _UNICODE
#define UPDATEDRIVERFORPLUGANDPLAYDEVICES “UpdateDriverForPlugAndPlayDevicesW”
#else
#define UPDATEDRIVERFORPLUGANDPLAYDEVICES “UpdateDriverForPlugAndPlayDevicesA”
#endif

UpdateDriverForPlugAndPlayDevicesProto UpdateFn;
HMODULE newdevMod = LoadLibrary(TEXT(“newdev.dll”));

From cmdUpdate()
UpdateFn = (UpdateDriverForPlugAndPlayDevicesProto)GetProcAddress(newdevMod,UPDATEDRIVERFORPLUGANDPLAYDEVICES);
if(!UpdateFn)
{
err=GetLastError();
str.Format(“cmdUpdate: GetProcAddress failed error=%d”,err);
AfxMessageBox(str,MB_OK|MB_ICONEXCLAMATION,0);
goto final;
}

FormatToStream(stdout,inf ? MSG_UPDATE_INF : MSG_UPDATE,hwid,inf);

if(!UpdateFn(m_hWnd,hwid,inf,flags,&reboot))
{
err=GetLastError();
str.Format(“cmdUpdate: UpdateDriverForPlugAndPlayDevices failed error=%d”,err);
AfxMessageBox(str,MB_OK|MB_ICONEXCLAMATION,0);
goto final;
}

Some more information. The messages in setupini.log are essentially the same for both devcon and my app. Here is the block for the latest install attempt with my app:

[2010/11/19 02:35:53 172.165]
#-198 Command line processed: “e:\c_proj\robson\mtutility\debug\MTUtility.exe”
#I060 Set selected driver.
#-019 Searching for hardware ID(s): root\iodevice
#-166 Device install function: DIF_SELECTBESTCOMPATDRV.
#W059 Selecting best compatible driver failed. Error 0xe0000228: There are no compatible drivers for this device.
#W157 Default installer failed. Error 0xe0000228: There are no compatible drivers for this device.
#-166 Device install function: DIF_INSTALLDEVICEFILES.
#I125 Installing NULL driver for “ROOT\IODEVICE\0003”.
#E122 Device install failed. Error 0xe0000203: There is no driver selected for the device information set or element.
#E157 Default installer failed. Error 0xe0000203: There is no driver selected for the device information set or element.
#I060 Set selected driver.
#I125 Installing NULL driver for “ROOT\IODEVICE\0003”.
#I121 Device install of “ROOT\IODEVICE\0003” finished successfully.

wrote in message news:xxxxx@ntdev…

> HWID string (“ROOT\IODEVICE”),


This driver is PnP root-enumerated. Devcon should install it with no problem
(if the driver itself is correct, of course).

The incantation to install a root enumerated device is:
devcon install your.INF ROOT\IODEVICE

So perhaps the best course is getting it to install with devcon smoothly,
and fix any found issue.
Only then proceed with your setup app (and follow the exact code path used
by devcon).

Regards,
– pa

On 11/19/2010 12:29 PM, xxxxx@toc-cs.com wrote:

Customers are going to have to install this update themselves, so I have been looking for a way to install the drivers in some way other than going through the Add Hardware Wizard (the hardware is non PnP, one card dats back to 1988) which has many steps and most users of recent versions of Windows have probably never used it.

Try to look for “DPinst” at MSDN.

DPinst can do a “pre-install” and avoids the “Add Hardware” wizard.

http://msdn.microsoft.com/en-us/library/ff544842(VS.85).aspx

On 11/19/10 4:31 AM, Pavel A. wrote:

wrote in message news:xxxxx@ntdev…
> …
>> HWID string (“ROOT\IODEVICE”),
> …
>
> This driver is PnP root-enumerated. Devcon should install it with no
> problem
> (if the driver itself is correct, of course).

The driver (and hardware) is not PnP, it’s legacy. When I install with
the Add Hardware Wizard, it sets the hwid to ROOT\IODEVICE. That’s why
I used this for devcon.

> The incantation to install a root enumerated device is:
> devcon install your.INF ROOT\IODEVICE

That’s how I tried to install with devcon. From what I read, devcon is
essentially a command line version of the Add Hardware Wizard.
Apparently not because the driver installs fine with the Add Hardware
Wizard, but fails with undocumented errors with devcon.

> So perhaps the best course is getting it to install with devcon
> smoothly, and fix any found issue.
> Only then proceed with your setup app (and follow the exact code path
> used by devcon).

It’s tough to proceed when the error codes I get are undocumented and I
am using essentially the same code path as devcon with very minor
changes (like eliminating command line checking which is not necessary).
By writing my own app I was able to learn what function in devcon was
causing the problems I was seeing.

Windows makes life difficult for legacy drivers. I understand the push
for PnP and it makes sense for new hardware, but sometimes your stuck
with old hardware.

Bill

> Regards,
> – pa
>
>
>
> —
> 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
>

Didn’t know about DPinst. Though the documentation is the usual
Microsoft aggravation. It tells you that the driver must have a DIFx
section in the INF file to work with DPinst, yet when you navigate
there, the hyperlinks initially lead you back to where you started
without telling you what needs to go into a DIFx section. I think I
finally found the DIFx description.

I’ll see if I can get this thing to work…

Bill

On 11/19/10 4:56 AM, Hagen Patzke wrote:

On 11/19/2010 12:29 PM, xxxxx@toc-cs.com wrote:
> Customers are going to have to install this update themselves, so I have been looking for a way to install the drivers in some way other than going through the Add Hardware Wizard (the hardware is non PnP, one card dats back to 1988) which has many steps and most users of recent versions of Windows have probably never used it.

Try to look for “DPinst” at MSDN.

DPinst can do a “pre-install” and avoids the “Add Hardware” wizard.

http://msdn.microsoft.com/en-us/library/ff544842(VS.85).aspx


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

Bill Olson wrote:

Didn’t know about DPinst. Though the documentation is the usual
Microsoft aggravation. It tells you that the driver must have a DIFx
section in the INF file to work with DPinst, yet when you navigate
there, the hyperlinks initially lead you back to where you started
without telling you what needs to go into a DIFx section. I think I
finally found the DIFx description.

DPinst does not require any modifications to the INF. May I ask where
you read about the DIFx thing?

You just put DPinst.exe in the same directory as your CAT and/or INF
file, optionally with a DPinst.xml file for configuration options, then
you run DPinst. That’s all there is to it.


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

Did you look in setupapi.h for the error code values you are getting? Note the straight up hex values are probably not there, the error code values are constants with shifting and ORing which make it hard to hero for.

d

dent from a phpne with no keynoard

-----Original Message-----
From: Bill Olson
Sent: November 19, 2010 5:03 PM
To: Windows System Software Devs Interest List
Cc: Hagen Patzke
Subject: Re: [ntdev] Wrinting an Installer

Didn’t know about DPinst. Though the documentation is the usual
Microsoft aggravation. It tells you that the driver must have a DIFx
section in the INF file to work with DPinst, yet when you navigate
there, the hyperlinks initially lead you back to where you started
without telling you what needs to go into a DIFx section. I think I
finally found the DIFx description.

I’ll see if I can get this thing to work…

Bill

On 11/19/10 4:56 AM, Hagen Patzke wrote:
> On 11/19/2010 12:29 PM, xxxxx@toc-cs.com wrote:
>> Customers are going to have to install this update themselves, so I have been looking for a way to install the drivers in some way other than going through the Add Hardware Wizard (the hardware is non PnP, one card dats back to 1988) which has many steps and most users of recent versions of Windows have probably never used it.
>
> Try to look for “DPinst” at MSDN.
>
> DPinst can do a “pre-install” and avoids the “Add Hardware” wizard.
>
>
> http://msdn.microsoft.com/en-us/library/ff544842(VS.85).aspx
>
> —
> 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
>


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

Tim:
http://msdn.microsoft.com/en-us/library/ff540184(v=VS.85).aspx first line says that DPInst must comply with DIFx driver package requirements with a link. The page it takes you to has a bunch of links. The first ones take you back to where you’ve already been. Finally the Generic DIFx Requirements link tells you what they were alluding to on the page that brought you here.

I just find it frustrating that MS documentation does this sort of thing. Hyperlinks are great, but MS is not great at laying out their documentation and it ends up in a number of dead ends before you get what you want.

Doron:
I’ll look in setupapi.h.

Thanks,
Bill

The only DIFx specifc item in an INF is the DriverPackageType=

http://msdn.microsoft.com/en-us/library/ff552334(VS.85).aspx

You probably figured that out by now.

The other requirements are spelled out (well, to some extent) here:

http://msdn.microsoft.com/en-us/library/ff544993(v=VS.85).aspx

Again, you probably found that too.

I have re-read your original post and noted the following:



Most of what has been said on this thread has been applicable to PnP
enumerated devices so I am a bit confused as to what exactly the ‘install
procedure’ is that you got to succeed and thus what procedure you are trying
to streamline for your users.

Does your ‘device’ get enumerated on a bus or is the driver a ‘legacy’
driver service that creates device objects directly in DriverEntry?

Do you actually have a PnP INF for this device?

AFAIK a PnP INF is the only thing relevant to
UpdateDriverForPlugAndPlayDevices().

Cheers,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@toc-cs.com
Sent: Friday, November 19, 2010 10:35 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Wrinting an Installer

Tim:
http://msdn.microsoft.com/en-us/library/ff540184(v=VS.85).aspx first
line says that DPInst must comply with DIFx driver package requirements with
a link. The page it takes you to has a bunch of links. The first ones take
you back to where you’ve already been. Finally the Generic DIFx
Requirements link tells you what they were alluding to on the page that
brought you here.

I just find it frustrating that MS documentation does this sort of thing.
Hyperlinks are great, but MS is not great at laying out their documentation
and it ends up in a number of dead ends before you get what you want.

Doron:
I’ll look in setupapi.h.

Thanks,
Bill


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

> which make it hard to hero for.

iPhone predictive text isn’t my friend either.

James

James:
I figured you had some kind of spell check error. My wife hates spell check because she finds it never is correct. She never spells anything wrong though. My spelling isn’t as good as hers so I use it, with sometimes comical results.

David:
I did have issues with getting the INF files to work, but got to a point two days ago where they work with the Add Hardware wizard. In the Add Hardware wizard, I select “Install the hardware that I manually select from a list”, then “Show All Devices”, and finally “Have Disk”.

The drivers create the device objects in DeviceEntry, no bus enumeration.

I just got it working with DPInst. All it took was adding the /lm command line switch to tell it to install as a legacy driver. DPInst is pretty easy to use, I think it will do the job.

Bill

I believe that you can control the operational mode of DPINST by supplying some additional control files in the root folder of the driver package which amounts to saying you can probably set legacy mode ‘on’ for your install without having to tell the user to use /lm.

http://msdn.microsoft.com/en-us/library/ff553560(v=VS.85).aspx

Good Luck,
Dave Cattley

On 11/20/10 10:16 AM, xxxxx@msn.com wrote:

I believe that you can control the operational mode of DPINST by supplying some additional control files in the root folder of the driver package which amounts to saying you can probably set legacy mode ‘on’ for your install without having to tell the user to use /lm.

http://msdn.microsoft.com/en-us/library/ff553560(v=VS.85).aspx

I looked at that and was going to do it, but the drivers are installed
as part of a software package. The program that puts together the
package has the ability to run scripts after copying the files. I just
told it to run “dpinst /lm” there, the user will never see the command
line and it appears very slick and easy from the user’s perspective.

After all the struggle to get there it seems sort of anti-climatic, but
I’m not complaining. It works, which is the important part!

Bill