WiX installer - how to know when drivers are installed

In my WiX installer for my Xen drivers, I install my bus driver and all
the drivers for the children of the bus driver. I install the child
drivers first and then the bus driver so that the child drivers are
already there when the bus driver enumerates PDO’s for them and the user
doesn’t get the driver selection screen.

Unfortunately, after the bus driver is installed, the installer assumes
that it’s all good and continues with the installation. The problem with
this is that the PDO’s may not have the driver attached to them yet
which is disasterous if the user hits reboot before this happens - the
bus driver tells Xen to remove the emulated PCI disk and network drivers
when it becomes active leaving the system with no boot device.

Additionally, I have a small exe that is supposed to run on first
install to optionally (chosen by the user at install time) copy the
network configuration (IP Addresses etc) from the emulated PCI network
devices to my new PV device - if you’ve ever booted up a DC with no IP
address you’ll know why this is a good idea :slight_smile:

I’m not really a wizard with WiX, and I’ve been tinkering trying at the
very least to present the user with a screen to allow them to proceed
after first making sure all the installation has happened correctly (eg
they check Device Manager manually). Unfortunately I don’t think WiX
works this way and interrupting the actual install once it has started
isn’t something that is good to do.

My next idea is to create a little app (or even vbscript…) that runs
in a loop and every few seconds examines the system to firstly make sure
that the bus driver has enumerated some PDO’s, and secondly check that
FDO’s are installed for all of them. It will only exit (allowing
installation to continue) once this has happened. I’ll include a timeout
too just so it doesn’t hang there forever. Does that sound reasonable?
Is perusing the registry to make sure that everything enumerated by my
bus driver has a device attached a good approach or is there a better
way?

Thanks

James

Have you looked at CMP_WaitNoPendingInstallEvents?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Wednesday, December 30, 2009 10:56 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WiX installer - how to know when drivers are installed

In my WiX installer for my Xen drivers, I install my bus driver and all
the drivers for the children of the bus driver. I install the child
drivers first and then the bus driver so that the child drivers are
already there when the bus driver enumerates PDO’s for them and the user
doesn’t get the driver selection screen.

Unfortunately, after the bus driver is installed, the installer assumes
that it’s all good and continues with the installation. The problem with
this is that the PDO’s may not have the driver attached to them yet
which is disasterous if the user hits reboot before this happens - the
bus driver tells Xen to remove the emulated PCI disk and network drivers
when it becomes active leaving the system with no boot device.

Additionally, I have a small exe that is supposed to run on first
install to optionally (chosen by the user at install time) copy the
network configuration (IP Addresses etc) from the emulated PCI network
devices to my new PV device - if you’ve ever booted up a DC with no IP
address you’ll know why this is a good idea :slight_smile:

I’m not really a wizard with WiX, and I’ve been tinkering trying at the
very least to present the user with a screen to allow them to proceed
after first making sure all the installation has happened correctly (eg
they check Device Manager manually). Unfortunately I don’t think WiX
works this way and interrupting the actual install once it has started
isn’t something that is good to do.

My next idea is to create a little app (or even vbscript…) that runs
in a loop and every few seconds examines the system to firstly make sure
that the bus driver has enumerated some PDO’s, and secondly check that
FDO’s are installed for all of them. It will only exit (allowing
installation to continue) once this has happened. I’ll include a timeout
too just so it doesn’t hang there forever. Does that sound reasonable?
Is perusing the registry to make sure that everything enumerated by my
bus driver has a device attached a good approach or is there a better
way?

Thanks

James


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

> Is perusing the registry to make sure that everything enumerated by my

bus driver has a device attached a good approach or is there a better
way?

Personally, I’d suggest querying the WMI PnP data to verify the devices
started correctly. This is REALLY easy from VBScript. Another possibility is
to expose WMI interfaces in YOUR devices and ask them if they are
functioning correctly.

Jan

I believe it’s WMI class Win32_PnPEntity you want.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-394460-
xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Wednesday, December 30, 2009 11:05 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WiX installer - how to know when drivers are
installed

> Is perusing the registry to make sure that everything enumerated by
my
> bus driver has a device attached a good approach or is there a better
> way?

Personally, I’d suggest querying the WMI PnP data to verify the devices
started correctly. This is REALLY easy from VBScript. Another
possibility is
to expose WMI interfaces in YOUR devices and ask them if they are
functioning correctly.

Jan


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

>

Have you looked at CMP_WaitNoPendingInstallEvents?

Hmmm… my concern is that there may be an opportunity for things to
race between the bus driver installing successfully, and the child
devices being enumerated. Between those two things occurring there will
be a time when there are no outstanding PnP activities.

James

>

>
> Have you looked at CMP_WaitNoPendingInstallEvents?
>

Hmmm… my concern is that there may be an opportunity for things to
race between the bus driver installing successfully, and the child
devices being enumerated. Between those two things occurring there
will
be a time when there are no outstanding PnP activities.

But then again… once I have determined that at least one PDO has been
enumerated (simple registry query to check for keys under
HKLM\SYSTEM\CCS\Enum\xen or WMI as suggested by Jan which I haven’t
investigated yet), I can use CMP_WaitNoPendingInstallEvents and not have
to poll things over and over.

Thanks!

James

I would think that waiting for the enum reg keys is the least reliable and most subject to breaking when the os is updated. You have a public api or wmi object with a public contract, why not use the public apis instead of relying on undocumented and internal implementation.

d

-----Original Message-----
From: James Harper
Sent: Thursday, December 31, 2009 12:01 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WiX installer - how to know when drivers are installed

>
> >
> > Have you looked at CMP_WaitNoPendingInstallEvents?
> >
>
> Hmmm… my concern is that there may be an opportunity for things to
> race between the bus driver installing successfully, and the child
> devices being enumerated. Between those two things occurring there
will
> be a time when there are no outstanding PnP activities.
>

But then again… once I have determined that at least one PDO has been
enumerated (simple registry query to check for keys under
HKLM\SYSTEM\CCS\Enum\xen or WMI as suggested by Jan which I haven’t
investigated yet), I can use CMP_WaitNoPendingInstallEvents and not have
to poll things over and over.

Thanks!

James


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

>

I would think that waiting for the enum reg keys is the least reliable
and
most subject to breaking when the os is updated. You have a public api
or wmi
object with a public contract, why not use the public apis instead of
relying
on undocumented and internal implementation.

Point taken.

I’m off to investigate now, but can WMI tell me if a bus has enumerated
at least 1 device? I assume it can and I just need to research it a
bit…

Thanks

James

I don’t believe WMI can tell if a PDO was enumerated by a bus, as the
Win32_PnPEntity instances correspond more to a devnode, which isn’t created
until the PnP subsystem does some processing of the bus enumeration.

It seems like my understanding of the problem you’re trying to solve is to
prevent the WIX installer from finishing/rebooting until the new boot disk
device is started? If so, you could do a WMI query for a Win32_PnPEntity
instance with a wildcard match in the instance name that would match your
virtual devices.

A little VBScript that’s useful when exploring this stuff looks like:

strComputer = “.”
Set objWMIService = GetObject(“winmgmts:\” & strComputer & “\root\cimv2”)

Set colMonitoredEvents = objWMIService.ExecNotificationQuery _
("SELECT * FROM __InstanceOperationEvent WITHIN 5 WHERE " _
& “Targetinstance ISA ‘Win32_PnPEntity’”)

Do While TRUE
Set objEventObject = colMonitoredEvents.NextEvent()

WScript.Echo objEventObject.getObjectText_

Loop

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-394469-
xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Thursday, December 31, 2009 12:31 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WiX installer - how to know when drivers are
installed

>
> I would think that waiting for the enum reg keys is the least
reliable
and
> most subject to breaking when the os is updated. You have a public
api
or wmi
> object with a public contract, why not use the public apis instead of
relying
> on undocumented and internal implementation.
>

Point taken.

I’m off to investigate now, but can WMI tell me if a bus has enumerated
at least 1 device? I assume it can and I just need to research it a
bit…

Thanks

James


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

>this is that the PDO’s may not have the driver attached to them yet

which is disasterous if the user hits reboot before this happens - the
bus driver tells Xen to remove the emulated PCI disk and network drivers
when it becomes active leaving the system with no boot device.

So, the problem occurs only if the machine reboots with all your drivers in place, but the devnodes not being set up yet?

And why is this the problem? because the user-mode PnP service which can set the devnodes up runs only very late, and, on early boot stages, the devnodes are not set up and the OS has no boot device? is my guess correct?

If yes, then CriticialDeviceDatabase can be a solution. It is a simple registry override for the user-mode PnP and INF file stuff, which can allow the machine to boot OK even with boot disk devnode being not set up yet - the kernel will set it up automatically in a simplified way early in boot process, based on CriticialDeviceDatabase without the INF files.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>

>this is that the PDO’s may not have the driver attached to them yet
>which is disasterous if the user hits reboot before this happens -
the
>bus driver tells Xen to remove the emulated PCI disk and network
drivers
>when it becomes active leaving the system with no boot device.

So, the problem occurs only if the machine reboots with all your
drivers in
place, but the devnodes not being set up yet?

Yes

And why is this the problem? because the user-mode PnP service which
can set
the devnodes up runs only very late, and, on early boot stages, the
devnodes
are not set up and the OS has no boot device? is my guess correct?

If yes, then CriticialDeviceDatabase can be a solution. It is a simple
registry override for the user-mode PnP and INF file stuff, which can
allow
the machine to boot OK even with boot disk devnode being not set up
yet - the
kernel will set it up automatically in a simplified way early in boot
process,
based on CriticialDeviceDatabase without the INF files.

Hmmm… I’d vaguely wondered about that earlier. So I guess until
Windows sets up the devnodes and figures out that it’s a boot device, it
doesn’t get in CriticalDeviceDatabase automatically? Do you have an
example or is it as simple as using addreg (or whatever it is) to add a
# key (eg xen#vbd based on what regedit is telling me) to
HKLM\SYSTEM\CCS\Control\CriticalDeviceDatabase and then the appropriate
ClassGUID and Service values under that? Time to do some testing!

Is that an ‘approved’ way of doing things or just something that happens
to work?

Thanks!

(about 45 minutes until the New Year here on the east coast of Australia
- Happy New Year everyone!)

James

>

If yes, then CriticialDeviceDatabase can be a solution. It is a simple
registry override for the user-mode PnP and INF file stuff, which can
allow
the machine to boot OK even with boot disk devnode being not set up
yet - the
kernel will set it up automatically in a simplified way early in boot
process,
based on CriticialDeviceDatabase without the INF files.

That solves the unbootable system problem, which is the important one,
but I’d still like to be able to tell when all my network adapters are
up and running too so I can copy the network config across to them.

During install when the xen drivers detect that they aren’t ‘in control’
of the system, the scsiport adapter is still created but doesn’t
enumerate any devices, and the ndis adapter is created but tells windows
that its cable is disconnected, so it’s the only time to copy the
network config over. After that, the emulated pci network adapter is
hidden from the system altogether on boot.

But even if I can’t get that working, having less chance of an impatient
user making their system unbootable is a big step in the right
direction!

Thanks again.

James

>Hmmm… I’d vaguely wondered about that earlier. So I guess until

Windows sets up the devnodes and figures out that it’s a boot device, it
doesn’t get in CriticalDeviceDatabase automatically?

It does.

CriticalDeviceDatabase is a primitive map of HwID -> DriverServiceName, which is the INF files replacement for the early boot stages.

If the devnode’s HwID figures in the database - then I have a strong suspect that Windows will do minimal setup of this devnode early in the boot stage, before the INF-processing service is up.

Time to do some testing!

Yes.

  • Happy New Year everyone!)

To you too :slight_smile:


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

> A little VBScript that’s useful when exploring this stuff looks like:

strComputer = “.”
Set objWMIService = GetObject(“winmgmts:\” & strComputer &
“\root\cimv2”)

Set colMonitoredEvents = objWMIService.ExecNotificationQuery _
("SELECT * FROM __InstanceOperationEvent WITHIN 5 WHERE " _
& “Targetinstance ISA ‘Win32_PnPEntity’”)

Do While TRUE
Set objEventObject = colMonitoredEvents.NextEvent()

WScript.Echo objEventObject.getObjectText_

Loop

According to
http://msdn.microsoft.com/en-us/library/aa394353(VS.85).aspx the
objEventObject for a Win32_PnpEntity should contain a CompatibleID and
HardwareID member, and because my driver creates these and they always
start with "XEN" I think it would be valid for me to search on that
basis. I don’t get any CompatibleID or HardwareID dumped out though…
any suggestions?

Thanks

James

>

According to
http://msdn.microsoft.com/en-us/library/aa394353(VS.85).aspx the
objEventObject for a Win32_PnpEntity should contain a CompatibleID and
HardwareID member, and because my driver creates these and they always
start with "XEN" I think it would be valid for me to search on that
basis. I don’t get any CompatibleID or HardwareID dumped out though…
any suggestions?

And on reading closer… those members are not supported under XP. My
bad.

Thanks

James

James,

Regarding pre-provisioning of the network devices:

It does not seem like you need to provision them prior to reboot, it seems
like you need to ensure they are provisioned before starting ‘next’,
correct? That start could be during the current session or after a reboot.

What about placing the configuration information in a registry key and using
a device co-installer associated with your (virtual) network device to
detect at install time and prior to ‘starting’ the device that the
pre-installed provisioning information is present and needs to be applied.

Once applied, the registry key could be deleted, so that if a virtual
network adapter is deleted and re-enumerated, no pre-provisioning
information would be present and the system defaults would be applied.

Happy New Year! (I think you are already there, yes?)

Cheers,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Thursday, December 31, 2009 7:37 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WiX installer - how to know when drivers are installed

If yes, then CriticialDeviceDatabase can be a solution. It is a simple
registry override for the user-mode PnP and INF file stuff, which can
allow
the machine to boot OK even with boot disk devnode being not set up
yet - the
kernel will set it up automatically in a simplified way early in boot
process,
based on CriticialDeviceDatabase without the INF files.

That solves the unbootable system problem, which is the important one,
but I’d still like to be able to tell when all my network adapters are
up and running too so I can copy the network config across to them.

During install when the xen drivers detect that they aren’t ‘in control’
of the system, the scsiport adapter is still created but doesn’t
enumerate any devices, and the ndis adapter is created but tells windows
that its cable is disconnected, so it’s the only time to copy the
network config over. After that, the emulated pci network adapter is
hidden from the system altogether on boot.

But even if I can’t get that working, having less chance of an impatient
user making their system unbootable is a big step in the right
direction!

Thanks again.

James


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

>

I believe it’s WMI class Win32_PnPEntity you want.

For a device that is up and running:

instance of Win32_PnPEntity
{
Caption = “Xen Block Device Driver”;
ClassGuid = “{4D36E97B-E325-11CE-BFC1-08002BE10318}”;
ConfigManagerErrorCode = 0;
ConfigManagerUserConfig = FALSE;
CreationClassName = “Win32_PnPEntity”;
Description = “Xen Block Device Driver”;
DeviceID = “XEN\VBD\4&32FE5319&0&5632”;
Manufacturer = “Xen GPL PV Driver Developers”;
Name = “Xen Block Device Driver”;
PNPDeviceID = “XEN\VBD\4&32FE5319&0&5632”;
Service = “XenVbd”;
Status = “OK”;
SystemCreationClassName = “Win32_ComputerSystem”;
SystemName = “WXPTEST”;
};

For a device that is not yet installed (User is being prompted with “The
software you are installing … has not passwed Windows Logo testing
…” dialog):

instance of Win32_PnPEntity
{
Caption = “Xen vbd device #8448”;
ClassGuid = “{4D36E97B-E325-11CE-BFC1-08002BE10318}”;
ConfigManagerErrorCode = 0;
ConfigManagerUserConfig = FALSE;
CreationClassName = “Win32_PnPEntity”;
Description = “Xen vbd device #8448”;
DeviceID = “XEN\VBD\4&32FE5319&0&8448”;
Name = “Xen vbd device #8448”;
PNPDeviceID = “XEN\VBD\4&32FE5319&0&8448”;
Service = “XenVbd”;
Status = “OK”;
SystemCreationClassName = “Win32_ComputerSystem”;
SystemName = “WXPTEST”;
};

The differences I can see are:
. Caption and Name are from the PDO
. No Manufacturer String

I can’t rely on the Caption and Name values to make a decision (or at
least, I’d rather not), and I’m not sure I can rely on the absence of
the Manufacturer String.

It’s curious that Status is “OK” and ConfigManagerErrorCode = 0 even
though the device isn’t started. Maybe the “has not passwed Windows Logo
testing” state is not one that is properly defined? I get the feeling
that this WMI stuff isn’t all it’s cracked up to be :frowning:

Thanks

James

> James,

Regarding pre-provisioning of the network devices:

It does not seem like you need to provision them prior to reboot, it
seems
like you need to ensure they are provisioned before starting ‘next’,
correct? That start could be during the current session or after a
reboot.

What about placing the configuration information in a registry key and
using
a device co-installer associated with your (virtual) network device to
detect at install time and prior to ‘starting’ the device that the
pre-installed provisioning information is present and needs to be
applied.

Once applied, the registry key could be deleted, so that if a virtual
network adapter is deleted and re-enumerated, no pre-provisioning
information would be present and the system defaults would be applied.

I’d thought about trawling the registry for details of existing adapters
but decided that it wouldn’t work as I wouldn’t reliably know which
adapter was ‘live’ etc. Your idea might just work though, depending on
how late I can stuff the information into the registry and not upset
NDIS…

Thanks

James

I assumed that you attempting to migrate VNETx configuration from ‘before’
the update to VNETx configuration ‘after’ the update and that for some
reason (perhaps we should explore this!) the VNETx device gets ‘deleted’
across the upgrade.

You must have some way of collecting the information based on Device
Instance Id and then some way of re-applying it based on Device Instance Id.

Are you deleting the child device data (or is your install/upgrade process
doing so)? AFAIK, if the devnodes are allowed to survive and your
enumeration (bus) IDs don’t change for the children, you should be able to
‘upgrade’ the network driver without impacting the network configuration.
Upgrading your virtual network device driver should be no different than
upgrading a driver for a physical network device and that does not
invalidate the network configuration.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Thursday, December 31, 2009 9:16 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WiX installer - how to know when drivers are installed

James,

Regarding pre-provisioning of the network devices:

It does not seem like you need to provision them prior to reboot, it
seems
like you need to ensure they are provisioned before starting ‘next’,
correct? That start could be during the current session or after a
reboot.

What about placing the configuration information in a registry key and
using
a device co-installer associated with your (virtual) network device to
detect at install time and prior to ‘starting’ the device that the
pre-installed provisioning information is present and needs to be
applied.

Once applied, the registry key could be deleted, so that if a virtual
network adapter is deleted and re-enumerated, no pre-provisioning
information would be present and the system defaults would be applied.

I’d thought about trawling the registry for details of existing adapters
but decided that it wouldn’t work as I wouldn’t reliably know which
adapter was ‘live’ etc. Your idea might just work though, depending on
how late I can stuff the information into the registry and not upset
NDIS…

Thanks

James


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

The cddb works in weird ways and is not the same as a full install. The system will add entries to the cddb upon install of boot critical devices.

d

-----Original Message-----
From: James Harper
Sent: Thursday, December 31, 2009 4:18 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WiX installer - how to know when drivers are installed

>
> >this is that the PDO’s may not have the driver attached to them yet
> >which is disasterous if the user hits reboot before this happens -
the
> >bus driver tells Xen to remove the emulated PCI disk and network
drivers
> >when it becomes active leaving the system with no boot device.
>
> So, the problem occurs only if the machine reboots with all your
drivers in
> place, but the devnodes not being set up yet?

Yes

> And why is this the problem? because the user-mode PnP service which
can set
> the devnodes up runs only very late, and, on early boot stages, the
devnodes
> are not set up and the OS has no boot device? is my guess correct?
>
> If yes, then CriticialDeviceDatabase can be a solution. It is a simple
> registry override for the user-mode PnP and INF file stuff, which can
allow
> the machine to boot OK even with boot disk devnode being not set up
yet - the
> kernel will set it up automatically in a simplified way early in boot
process,
> based on CriticialDeviceDatabase without the INF files.

Hmmm… I’d vaguely wondered about that earlier. So I guess until
Windows sets up the devnodes and figures out that it’s a boot device, it
doesn’t get in CriticalDeviceDatabase automatically? Do you have an
example or is it as simple as using addreg (or whatever it is) to add a
# key (eg xen#vbd based on what regedit is telling me) to
HKLM\SYSTEM\CCS\Control\CriticalDeviceDatabase and then the appropriate
ClassGUID and Service values under that? Time to do some testing!

Is that an ‘approved’ way of doing things or just something that happens
to work?

Thanks!

(about 45 minutes until the New Year here on the east coast of Australia
- Happy New Year everyone!)

James


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