Slightly different motherboards confuse plug&play

  • Thread starter Thread starter Rob
  • Start date Start date
R

Rob

Hello all,

I'm updating from NTe to XPe (SP2), and am running into a confusing
issue with the plug&play. In the field, I have a few thousand embedded
PC's,
all supposedly having the same motherboard. But now it turns out that
on that motherboard the PnpID of some devices, like the VGA or the
Ethernet controller, has a slightly different (higher) subsystem ID.

Now when I generate my XPe image, FBA it and reseal it on the 1st type
of motherboard but then install it on the slightly more modern
motherboard,
the PnP 'sees' new hardware appear. The consequence is that I lose my
VGA settings and end up with 640x480 16 colours, and also my network
settings
are copied to another location in the registry. Also, the name of the
connection
is changed from "Machine Internal Network" to "Local Area Connection".
The latter is normally not a problem but for my application (which sets
DHCP registry
keys during boot) it is a real problem because XP doesn't see my DHCP
registry keys
at the "Machine Internal Network" location, as it isn't using that part
of the registry anymore.

Is there any way for PnP to deal with very small changes in hardware
versions,
or perhaps there are configuration options for PnP? I tried to prevent
PnP, but this
only makes that the Found New Hardware Wizard works, apparently under
water
PnP still functions. A complete disable of PnP makes that some applets
in the
Control Panel no longer work, so is no real option.

Any clues???

Rob
 
Rob,

Unlikely you will be able to get rid of PnP on XP/XPe without affecting the OS stability. The PnP Manager (not PnP user mode) has
known to be a core component there.

I don't know if there is PnP related settings that could allow you to eliminate the subsystem ID match.
But you can always postfix the cloned images with some patch scripts or etc.
E.g. you have a FBA command executed at late FBA phase (after the cloning) that will launch an application. The app will have to
re-setup video adapter settings (ChangeDisplaySettingsEx API), network ip/interface/adapter settings (netsh) or whatever you need to
fix.

Other then that you can try and tweak the corresponding INF files to broaden the supported compatible subsystems but then you have
to be sure all the subsystems are supported by the driver.

Another approach, that I have never tried though, could be in creating and setting up the master image and then, just before the
resealing (or in the captured image) you go and delete all INF files related to the broken devices (e.g., all network card INFs).
Also if you remove Add hardware Wizard component from your image configuration the end user will not notice any new hardware
installation UI.

=========
Regards,
KM
 
If it was me, I'd do a TAP.(exe)"dance" on both versions of the
computer
and edit the pmq files that result by taking the NIC and VGA data from
the newer version and ADDING it to the pmq file for the older CPU and
then import the entire CPU definition as a MACRO component. You'll
also be able to look directly at the PNPID that comes up on the new CPU
board. This also gives you the opprotunity to prune away the "default"
components you might not need like Terminal Server, Mini-port and other
devices similarly affliated or afflicted with "virtual" drivers.

After re-reading the above paragraph, I realize that you need to be
familiar with the XML format of the PMQ file to pull this off. If you
feel confortable editing raw XML, this process is a piece of cake. I
wouldn't suggest doing it this way though if you aren't familiar with
XML. The reason I do it this way is that in the long run it saves
considerable time during the device dependency resolution steps by not
forcing you to re-delete unwanted components or the dependency error
messages generated by the devices embedded in the macro.

(XMLSpy.com has a free Home version that works quite well validating
PMQ files.)

Let me warn you though that some of the updated XPE drivers might
actually come up with much larger footprints compared to the NTE
versions. That will depend on how close one NIC is to the newer NIC or
likewise the two VGA chips.

windowsjunkie
 
The TAP approach should work just fine. But I wonder if you'd want to go that route if you happen to have a bunch of (sometimes
unknown) # of system in the fields with slightly different hardware (I mean all the systems are slightly different one from
another).

=========
Regards,
KM
 
Hi,

I checked that the PnpID's of my two 'identical' devices are:
PCI\VEN_8086&DEV_2449&SUBSYS_00021331&REV_01\3
PCI\VEN_8086&DEV_2449&SUBSYS_00021331&REV_03\3

So, only the value following 'REV' is one digit different. On NT,
the "Matching Device ID" ends with the SUBSYS field, so this
explains why two slightly different motherboards could run
the same image without plug-and-play interfering.

The current contents (part of, that is) of the PMQ file is:

<DEVICE ConfigFlags="0">
<DEVICEDESC>Ethernet Controller</DEVICEDESC>
<HARDWAREIDS>
<DEVICEID
Order="1">PCI\VEN_8086&amp;DEV_2449&amp;SUBSYS_00021331&amp;REV_03</DEVICEID>
<DEVICEID
Order="2">PCI\VEN_8086&amp;DEV_2449&amp;SUBSYS_00021331</DEVICEID>

etc. etc...

Are you suggesting that I could add a line for the REV_01, i.e. as
Order="2" ?
and shift the other lines down?
Or could I just remove the entry for the REV_03, so that all revisions
are catched
by the Order="2" line which doesn't care for revisions (in the PnPID,
apparently)?

I'm lacking knowledge on how exactly the PnP subsystem uses these line
to do
hardware matching, is there anywhere some readable documentation about
this?

Rob
 
Back
Top