28 replies to this topic

[Sha0]

There's not a heck of a lot to "universal" images with XP/2003, but you do need some critical knowledge:

• The right HAL
• The right kernel
• One or more boot-time drivers needed to support the storage underlying the boot volume
  
• An HKLM\SYSTEM\ControlSet00X\Control\CriticalDeviceDatabase\ entry to associate needed boot-time device(s) with service(s). This is an alternative to the usual Device Manager or Add New Hardware wizard, which both require the system to be booted, thus performed before the image is captured
• An HKLM\SYSTEM\ControlSet00X\Services\ entry with Start set to 0 to inform NTLDR to load the driver at boot-time
• Any needed .SYS and .DLL files that the above-mentioned service(s) require, so NTLDR can load them all.

In fact, it is my understanding that this is mostly what SysPrep's MassStorageDevices section is for... It injects the above sub-points into the Registry before shut-down. If you already have the hardware installed, then you don't need to include device ID-to-driver association in SysPrep.

The above-mentioned information can be performed on a captured image ("offline") in order to allow the image to boot on the target platform. You can use RegEdit's File -> Load Hive... to load the \Windows\System32\Config\SYSTEM hive and gain access to such things as the CriticalDeviceDatabase. File -> Unload Hive, possibly copy the SYSTEM Registry hive back into the image, and that part is done.

Any non-boot-critical devices can be installed either via Mini-Setup (which people call "SysPrep" far too often, by the way) or via a batched or automated process. If you have networking available or some other available file repository for drivers, you needn't include non-boot-critical devices in your image.

To identify files needed by a driver, you can look in Device Manager, to the device's Properties..., on the Driver tab, in the Driver Files... Additionally, you often need to know which .INF file is used to install the device. You can find this by looking in the Registry, finding the device under HKLM\SYSTEM\CurrentControlSet\Enum\, checking its Driver value, then looking under the corresponding key under HKLM\SYSTEM\CurrentControlSet\Control\Class\. You will often find an OEMXX.INF file staring back at you, for hardware not supported out-of-the-box by Windows' installation media. You can also determine the .INF file and other driver files by using DEVCON.EXE, I believe with its driverfiles option.

If your different hardware platforms require different HAL & kernel combinations, you could:

• Include all combinations in BOOT.INI and have all files available in \Windows\System32\ and you will need to manually select the correct choice
• Have a post re-imaging step which can access the freshly re-imaged filesystem and replace the HAL and kernel (NTFS users will need some kind of access, which is part of what makes a PE environment so popular for system deployment)

Populating an image with storage controller drivers and CriticalDeviceDatabase entries using somebody's online "latest, greatest" set of known hardware can be nice, but it will have to keep up with new hardware, and you will have to keep up with keeping your "universal" image up-to-date. Additionally, you also wind up with a lot of boot-start drivers and files in the \Windows\System32\Drivers\ directory, though some of them will not be used.

If the trojan-accused package in this thread's tutorial takes care of a lot of this business, I ask: Would the package's author be kind enough to provide their device ID-to-driver association database? For people who don't wish to risk getting a trojan, this might be handier for them. Obviously this is just asking out loud, since the package's author might not be a Boot-Land reader. Even a batch file to download needed files from online sources as well as populate the CriticalDeviceDatabase and needed Services might be nice.

How does SPAT know about future hardware that hasn't been developed yet? Is that hardware included in "image working on all computers?"

[MedEvil]

• An HKLM\SYSTEM\ControlSet00X\Control\CriticalDeviceDatabase\ entry to associate needed boot-time device(s) with service(s). This is an alternative to the usual Device Manager or Add New Hardware wizard, which both require the system to be booted, thus performed before the image is captured
• An HKLM\SYSTEM\ControlSet00X\Services\ entry with Start set to 0 to inform NTLDR to load the driver at boot-time

You wouldn't happen to know, under which circumstances, which one is to use?
Seems strange to me, that the same drivers would need to be told in two places, to load at boot time.

[Wonko the Sane]

You wouldn't happen to know, under which circumstances, which one is to use?
Seems strange to me, that the same drivers would need to be told in two places, to load at boot time.

Have you tried actually checking the mentioned keys?:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet00x\Control\CriticalDeviceDatabase
are basically in the form:
keyname=hardware device value(1)=related ClassGUID value(2)=related service
and the keys in:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet00x\Services
are basically in the form:
keyname=service
value(1 to n)= parameters for the service (including Loading Group and Start type, besides path to actual .sys)

To get 4 you usually use to sum 2+2 or 3+1 rather than 4+0


Wonko

[MedEvil]

Have you tried actually checking the mentioned keys?:

Yes i do. I set the driver Start to 0 and Group to BootBusExtender, then include the name of the driver in the CriticalDevicesCatabase too.
But i don't do it, because it needs to be this way, or because i know what i do. It's the sledgehammer methode. Take a big enough hammer and you're bound to hit the right nail!

[Wonko the Sane]

Take a big enough hammer and you're bound to hit the right nail!

Wrong paragon.

Think of using the large hammer to hit a chisel to carve something onto a stone.
If you take the chisel out of the equation you either:

• hit your hand
• hit the stone directly

As a general rule, always ask yourself:

• WHICH
• WHEN
• WHAT
• WHERE
• CUI PRODEST:

http://en.wikipedia....atin_phrases:_C
the answer to the latter is easy (either Bill Gates or Steve Jobs )

Would it be too much an effort to assume that for once in their life the good MS guys named something appropriately?

Let's see:
CriticalDeviceDatabase
could mean Database for Devices that are Critical for booting...
Now, since a Database can be seen as an address book, it seems like it's use could be obvious:
NTDETECT.COM or whatever detects a Device, then looks in the CriticalDeviceDatabase to find WHICH service is associated to the device, then looks in the Services to find the associated service, and depending on the settings in there decides WHEN to load the service, WHAT type of Start it should have, and WHERE to actually find the .sys.

Too simple?


Wonko

[MedEvil]

What you write sound more like guessing then knowing. So i answer with my guesses.

If a device is critical for boot and i add it to CriticalDevicesDatabase, then why should i set Start too for boot time?
Eighter the driver is critical and needs to be loaded no matter what. Or I can set the Start parameter of the driver to load whenever i like.

It just makes no sense to tell windows: "Load driver at boot time. - Yes, i really mean it!" .

Maybe you can answer some questions for me.
What would happen if:
- i write an entry in CriticalDeviceDatabase, but Start is set to disabled?
- i write no entry in CriticalDeviceDatabase, but set Start to Boot Time?

I've run a few test with this stuff, but not all driver behave identical. For some works that way, for another the other.
Doing the triple check is so far the only way i know, to avoid testing each driver seperately.
If someone knows, how this works exactly, some optimisations might be possible.

[MedEvil]

btw. If, like in a PE, there is also a txtsetup.sif to be used, things tend to get funny.

If i load a driver by txtsetup.sif and veryfy that it is loaded and working. Then an extra entry to CriticalDevicesDatabase shouldn't make any difference. Right?
But for some reason it does.

[Sha0]

MedEvil: The CriticalDeviceDatabase is a registry-only alternative to using the Add Hardware Wizard in userland and parsing .INF files. .INF files have device IDs associated with a driver/service. The Add Hardware functionality must read .INFs from a filesystem, parse them for device IDs, copy files, install services, invoke co-installers, etc. The CriticalDeviceDatabase is an alternative means to associate device IDs with a service/driver. The advantages here are that:

• you do not need access to any filesystem (the database is in the Registry, loaded by NTLDR) when the kernel is invoked
• each entry is an exact mapping between device ID and service/driver, so less extensive parsing

The down-side is that using the CriticalDeviceDatabase does not install a service/driver. It merely says "hey, if you see this device ID, ask this service/driver to drive it." The service/driver must already be installed under HKLM\SYSTEM\ControlSet00X\Services\. For most "critical" devices, the services/drivers are most often simply .SYS files with possibly other .SYS or core .DLL files as dependencies; not typically any libraries dependent on the Win32 subsystem, unlike a lot of userland services.

Setting Start to 0 merely indicates that NTLDR should load the file from the boot filesystem via NTBOOTDD.SYS or, perhaps more commonly for home platforms, simply BIOS INT 13h. If Start is not 0, NTLDR won't load the driver file(s) into RAM before invoking the kernel... In which case even a CriticalDeviceDatabase entry will not help.

The other way around is that you have the driver set to boot-start, but no CriticalDeviceDatabase association for a device ID. If you're very lucky, the driver intelligently hunts down any device IDs that it supports and takes responsibility for them. That would mean the driver itself has a database of supported device IDs. More likely, the driver is never used by any devices (they're not associated with it) and so is eventually unloaded.

I hope this makes sense. In summary: You need the boot-start service for NTLDR's sake. You need the CriticalDeviceDatabase to say "use this loaded driver for this device ID."

Wonko the Sane: The key point of your response in my opinion is that you establish the one-to-many relationship. One driver/service can handle many devices. A driver only appears once under Services but appears many times under CDDB; once for each device ID that it should handle.

The process goes something like: Anybody can register device IDs with the system. Some of these might be populated by NTLDR or NTDETECT.COM. Then drivers like PCI.SYS are associated with some of these devices. The PCI system will then register the devices it finds. Then Windows will check to see which driver to use for those device IDs. If the drivers are already loaded by NTLDR, that's great, otherwise the devices won't be able to start until the system volume is available. Then these drivers register yet more device IDs, which are looked up and so on. The check goes something like:

• Do we already have the exact device installed under Enum?
  
  • Yes? Is the driver loaded?
    
    • Yes? Tell the driver to start it.
    • No? Try to load the driver, then try to start the device.
  • No? ...
• Do we have a CDDB association for the device ID?
  
  • Yes? Is the driver loaded?
    
    • Yes? Tell the driver to start it.
    • No? Try to load the driver, then try to start the device.
  • No? The Add Hardware Wizard will deal with the device later, then.

- Shao Miller

[MedEvil]

You need the boot-start service for NTLDR's sake. You need the CriticalDeviceDatabase to say "use this loaded driver for this device ID."

Thanks for the extensive explaination, Shao!

But one thing is still not clear to me. I used to associate devices with drivers under ENUM. What's the difference between using ENUM and CDDB?

[Sha0]

MedEvil: Enum\ is where installed devices go. CriticalDeviceDatabase\ is like an .INF file which maps device IDs to services, and is only used if the device is not already installed under Enum\. You will also notice that the CDDB\ might use any of a device's compatible IDs. The IDs you find under Enum\ are the IDs that the device's parent/bus reports to Windows. That is, if "foo" is an HDD controller and "bar" is a disk, "foo" reports the ID for "bar". If this ID can be matched to a CDDB\ entry, Windows knows which disk driver to ask to drive the disk.

You might also note that for every device under Enum\, under the device ID is a sub-key which includes the parent device's ParentIdPrefix. This specifies for "bar" which "foo" is its parent. Since CDDB\ is just a mapping of device IDs to drivers, it knows nothing about which particular parent device on your particular system provides the child device.

Particular device nodes in their parent-specifying sub-key of their device ID key should have a Driver value which maps to a particular instance of a device class found under HKLM\SYSTEM\ControlSet00X\Control\Class\, if and only if the device has been installed.

Using CDDB\ means, "I don't know the exact device ID, nor the parent device that will provide it, but should you see an ID like this, use such-and-such driver." By manually hacking a device into Enum\, you are manually installing the device (be careful). By hacking an ID into CDDB\, you are suggesting a driver to be used by a device with a matching device ID.

HKLM\SYSTEM\ControlSet00X\

• Control\
  
• Class\
  
• ClassGUID\
  
• Instance\

[*]CriticalDeviceDatabase\

• DeviceIDforMatchingToDriver\

[/list][*]Enum\

• BusType\
  
• ExactIDasReportedByParent\
  
• NodeIDwithParent\

[/list][/list]
In summary: CDDB\ maps device IDs to drivers, Enum\ maps an exact device ID with an exact parent (and to a driver).

- Shao Miller

[MedEvil]

So to use CDDB instead of ENUM would provide a more universal setup, yes?

[Sha0]

MedEvil: I'd say so... Enum\ would have to be gigantic in order to have every possible hardware combination... Think of a USB stick plugged into every single USB port on a computer; each one being a new Enum\ entry.

Shirin: Sorry for spamming your thread with information. I am passionate about universal images for XP/2003, too.

[MedEvil]

Shirin: Sorry for spamming your thread with information. I am passionate about universal images for XP/2003, too.

Don't worry, i will split our discussion off, as soon as i found out, how. This is too important information, to be lost in some other thread.

You wouldn't be interested in fiddeling with PE by any chance?
God knows, our PE Registries could use a little help.

[Wonko the Sane]

@Sha0
Yep, that's exactly the idea of a Database, a searchable list of items with a correspondence to something else.

@Medevil
Don't be fooled by the way I sometimes describe things, even if they appear as random guesses, they are usually at least an educated kind of guesses .

Your guesses are based on a wrong assumption:

It just makes no sense to tell windows: "Load driver at boot time. - Yes, i really mean it!" .

The point is that you don't tell windows to load the driver twice, you do it just once wit the Load Order Group, then you tell it how to start (with the Start type setting) but you have first to know the other needed details, ANY of the four points below:

• which is the right driver for a given device
• when to load it
• what type of Start
• where to find the driver file(s)

is normally meaningless without the other three, though, as Sha0 ponted out some drivers may be "smart enough" to be able to fill just the one initial gap.

As said, and it is pretty much logical, what happens in the initial fases of booting the system is:
I have found this device.
Which service could I load for this? Hmm, let me have a look in the Critical Device Database under the device name.
Eureka! I have found a link to a service in Services section.
Them let me look at the Services Section to find when I have to load this service, what type of start it has, and where is the actual driver file.


Wonko

[Shirin Zaban]

MedEvil: I'd say so... Enum\

Shirin: Sorry for spamming your thread with information. I am passionate about universal images for XP/2003, too.

Hi Sha0

I am very very happy that you are talking very useful topics and i try to
learn too.

shirin zaban

[MedEvil]

Sha0, is there a way to use CDDB to connect more than one driver to an deviceID?
In a sort of: "Here have 3, pick the one you like."

[karyonix]

CDDB is used not only at boot time but also after boot.
When a "new device" (not exist in Enum) is discovered, kernel use CDDB to select a driver that will drive the new device temporarily before installation.
CDDB can specify only one driver (or set of one functional driver and zero or more Lowerfilters and Upperfilters) for each ID. There is no user interaction at this time.
If there is CDDB entry matching new device, the new device can work immediately even before Found New Hardware Wizard appears.
Otherwise, the new device just does not work until a driver is installed for it.

Found New Hardware Wizard does not use CDDB. CDDB does not affect Found New Hardware Wizard.
Driver installation uses INF files to find the driver that match hardware ID or compatible ID and install a driver for the device.
If it can find a driver that best match hardware ID or compatible ID and the driver package is signed and trusted, installation proceed without user interaction.
If the driver that match is not trusted or there is no driver that match, Found New Hardware Wizard appears.

After a driver (from INF file) is chosen, the temporary driver (specified in CDDB) stop and the new driver start.
If the temporary driver cannot be stopped, Windows notify user that system need to be restarted.

[MedEvil]

Maybe i'm going about this the wrong way and someone has a better idea.

In NaughtyPE (PE1) most drivers are installed by txtsetup.sif and those drivers are all a bit like ghosts. They are there and drive devices, yet Windows is telling you, they're not there. This makes it sometimes eighter impossible to install drivers that builds up upon one of those drivers or the install still works fine, but the new driver is not doing anything.
The only drivers which work flawless are the ones that get installed by HwPnP.

So i came up with the idea to move as much as possible of the txtsetup driver installation to the registry.
First i used ENUM and now CDDB for that.

Initial tests have looked good, but i only used something simple like cdrom and disk.

If i wanna move ide controller, i have to find a way to tell the 3 default drivers that they are suppose to be used for that.
Problem with this is the class. It seems to have to be set up for one specific driver.

Of course the question that arises, with your latest post karyonix is, will such a thorough installation of the drivers prevent their rebootless replacement with better suited drivers by HwPnP?

[karyonix]

Entries in CDDB and Enum keys do not prevent installation of new driver.
Some devices are always in used and cannot be stopped while Windows is running.
You cannot replace driver for disk that contain running Windows and swap file and all its parent devices (HAL, PCI, disk controller) without restart.

[MedEvil]

So the idea to boot up PE with default drivers and then replace them by better ones by the use of HwPnP, isn't always working.
I guess that this goes for all boot devices?

Then the solution would be to load the 'best' drivers right from the start. ?

btw. If disk controller can't be switched, then i assume the same goes for chipset drivers?

[Sha0]

karyonix: Nice post. I enjoy your emphasis that CDDB and Found New Hardware Wizard accomplish much of the same thing, only one happens entirely in kernel-land and the other uses .INF files and user-land components.

In NaughtyPE (PE1) most drivers are installed by txtsetup.sif and those drivers are all a bit like ghosts. They are there and drive devices, yet Windows is telling you, they're not there.

What kind of "ghosts"? Do you mean that devices do not appear in Device Manager or with devcon.exe? I would expect to see any running devices in both. TXTSETUP.SIF tells SETUPLDR to load the drivers before the kernel is invoked. CDDB entries can then use those drivers right away. Drivers not loaded by TXTSETUP.SIF will have to be loaded from the system volume (after it's available).

If i wanna move ide controller, i have to find a way to tell the 3 default drivers that they are suppose to be used for that.

If you want to move an IDE controller, its PCI VENdor and DEVice IDs should stay the same; only the parent device to which it is attached will change. I don't remember ever seeing any parent IDs in a CDDB entry, so moving an IDE controller should not be an issue. In contrast, a manual hack to include a device under Enum\ would require you to specify a parent ID... Doing that is ugly, but sometimes good[1] for pre-installing a non-attached exact device for a target hardware configuration.

Problem with this is the class. It seems to have to be set up for one specific driver.

You specify a class and a driver (service) in a CDDB entry.

So the idea to boot up PE with default drivers and then replace them by better ones by the use of HwPnP, isn't always working.

What's HwPnP?

I guess that this goes for all boot devices?

Then the solution would be to load the 'best' drivers right from the start. ?

btw. If disk controller can't be switched, then i assume the same goes for chipset drivers?

As karyonix said, it's all about in-use devices and/or drivers which cannot be stopped. For a device you wish to install a better driver for, make sure:

• The device is not in use (no open files, no page files, not opened with TinyHexer or BeeblebroxNT, etc.)
• In Device Manager, show devices by connection, find your device, look at any sub-devices (a PCI bridge might have an HDD controller somewhere under it). For each sub-device, make sure those devices match these two points

This will usually do the trick. Some drivers just plain need a reboot, unless they were started from the beginning. Are you basically just hoping to start with generic Windows drivers and replace them with vendor-provided, performance-enhanced drivers?

[1] http://www.etherboot...t_winnt_sanboot

[MedEvil]

What kind of "ghosts"? Do you mean that devices do not appear in Device Manager or with devcon.exe? I would expect to see any running devices in both.

Then you expect wrong. Devices strictly loaded by txtsetup.sif without some tinkering with the registry, will not show up in device manager and this causes problems in some cases.

If you want to move an IDE controller, its PCI VENdor and DEVice IDs should stay the same; only the parent device to which it is attached will change.

I have seen in CDDB so far only pretty generic device id like primary_ide_channel

You specify a class and a driver (service) in a CDDB entry.

Yes, but in the class entry of the primary_ide_channel the controller driver is specified. How do i get around that?

What's HwPnP?

HwPnP.exe a program by paraglider that does on a PE, what Found New Hardware Wizard does on a real XP. Installing drivers by inf.
It's a way easier methode to install drivers, than by txtsetup.sif. Unfortunately it only works for non boot devices.

As karyonix said, it's all about in-use devices and/or drivers which cannot be stopped.

A PE usually does not use a swapfile, still i think disk drivers can't be stopped.
Is there another way than trying, if a driver can be stoped?

Are you basically just hoping to start with generic Windows drivers and replace them with vendor-provided, performance-enhanced drivers?

Yes it would make it very easy to create a general PE by using default drivers in txtsetup.sif, which runs on all hardware. Yet
keeping the high performance option for drivers loaded by HwPnP, whenever possible.

[1] http://www.etherboot...t_winnt_sanboot

Useful if you wanna build a Windows which runs on a specific computer or set of computers.
PE however have to run on all computers, which means mostly machines with hardware configurations, you don't know about beforehand and it has to install all drivers without a restart!

[Sha0]

Then you expect wrong. Devices strictly loaded by txtsetup.sif without some tinkering with the registry, will not show up in device manager and this causes problems in some cases.

That sounds suspicious to me. Are you sure you mean "devices strictly loaded by txtsetup.sif" or do you mean "drivers strictly loaded by txtsetup.sif"? "Devices" implies that TXTSETUP.SIF has CDDB-like entries, tying device IDs to a driver. If you are simply loading drivers (foo.sys), that would explain why devices are not showing in Device Manager. Maybe you need to Show hidden devices due to the limited PE environment?

I have seen in CDDB so far only pretty generic device id like primary_ide_channel
Yes, but in the class entry of the primary_ide_channel the controller driver is specified. How do i get around that?

Here is a sample .REG file for a CDDB entry to support a particular HDD controller, needed for SATA-mode (as chosen in "BIOS" setup) operation on an HP EliteBook 8440w:

Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\8440w_system_hive\ControlSet001\Control\CriticalDeviceDatabase\pci#ven_8086&dev_3b2f&cc_0106]

"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"

"Service"="iaStor"

The PCI bus that the HDD controller is attached to will report a device with the IDs you see in the key name. This CDDB entry will tell Windows it's an HDD controller and to use the iaStor service (driver) to handle it. For any devices you wish to make CDDB entries for, this is how you can do it.

HwPnP.exe a program by paraglider that does on a PE, what Found New Hardware Wizard does on a real XP. Installing drivers by inf.
It's a way easier methode to install drivers, than by txtsetup.sif. Unfortunately it only works for non boot devices.

Ok, thanks. Nice to know.

A PE usually does not use a swapfile, still i think disk drivers can't be stopped.
Is there another way than trying, if a driver can be stoped?

I have uninstalled disks and HDD controllers many times and only ever had issues when the devices were in use. I've even pulled out SCSI drives, used Dell utilities to reconfigure RAID, then had the new RAID logical disks installed, all on a live system without rebooting. It's quite handy. You can try Microsoft's SysInternals' HANDLE.EXE to check for open handles to a volume, and close those handles, too.

Yes it would make it very easy to create a general PE by using default drivers in txtsetup.sif, which runs on all hardware. Yet
keeping the high performance option for drivers loaded by HwPnP, whenever possible.

That seems like a sensible idea.

Useful if you wanna build a Windows which runs on a specific computer or set of computers.
PE however have to run on all computers, which means mostly machines with hardware configurations, you don't know about beforehand and it has to install all drivers without a restart!

Yes. It was not meant as a suggestion for your scenario at all.

[MedEvil]

That sounds suspicious to me. Are you sure you mean "devices strictly loaded by txtsetup.sif" or do you mean "drivers strictly loaded by txtsetup.sif"? "Devices" implies that TXTSETUP.SIF has CDDB-like entries, tying device IDs to a driver.

Yes txtsetup.sif has a CDDB like Database tying Device ID to drivers.

Maybe you need to Show hidden devices due to the limited PE environment?

Already enabled by default.

Here is a sample .REG file for a CDDB entry to support a particular HDD controller, needed for SATA-mode (as chosen in "BIOS" setup) operation on an HP EliteBook 8440w:
The PCI bus that the HDD controller is attached to will report a device with the IDs you see in the key name. This CDDB entry will tell Windows it's an HDD controller and to use the iaStor service (driver) to handle it. For any devices you wish to make CDDB entries for, this is how you can do it.

I mean exactly this problem:

Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\WB-Setup\ControlSet001\Control\CriticalDeviceDatabase\primary_ide_channel]

"Service"="atapi"

"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"



[HKEY_LOCAL_MACHINE\WB-Setup\ControlSet001\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}]

"Class"="hdc"

@="IDE ATA/ATAPI-Controller"

"Icon"="-9"

"Installer32"="SysSetup.Dll,HdcClassInstaller"

"TroubleShooter-0"="hcp://help/tshoot/tsdrive.htm"



------------------ problem start---------------------



[HKEY_LOCAL_MACHINE\WB-Setup\ControlSet001\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0000]

"MasterOnMask"=dword:00000080

"MasterOnConfigOffset"=dword:00000041

"SlaveOnMask"=dword:00000080

"SlaveOnConfigOffset"=dword:00000043

"InfPath"="mshdc.inf"

"InfSection"="intelide_Inst"

"ProviderName"="Microsoft"

"DriverDateData"=hex:00,80,62,c5,c0,01,c1,01

"DriverDate"="7-1-2001"

"DriverVersion"="5.1.2600.0"

"MatchingDeviceId"="pci\\ven_8086&dev_7111"

"DriverDesc"="Intel(r) 82371AB/EB PCI-Bus-Master-IDE-Controller"



------------------ problem end---------------------



[HKEY_LOCAL_MACHINE\WB-Setup\ControlSet001\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0001]

"EnumPropPages32"="storprop.dll,IdePropPageProvider"

"InfPath"="mshdc.inf"

"InfSection"="atapi_Inst_primary"

"ProviderName"="Microsoft"

"DriverDateData"=hex:00,80,62,c5,c0,01,c1,01

"DriverDate"="7-1-2001"

"DriverVersion"="5.1.2600.0"

"MatchingDeviceId"="primary_ide_channel"

"DriverDesc"="Primärer IDE-Kanal"

"MasterDeviceType"=dword:00000001

"SlaveDeviceType"=dword:00000000

"SlaveDeviceDetectionTimeout"=dword:00000001

"MasterDeviceTimingMode"=dword:00000410

"MasterDeviceTimingModeAllowed"=dword:ffffffff

"MasterIdDataCheckSum"=dword:000173d3

"SlaveDeviceTimingMode"=dword:00000000

I can't have a hardcoded driver for intel IDE Controller married to the general atapi driver.
Not counting SATA drivers, XP has a team of 3 drivers, to work on all IDE controllers.

Ok, thanks. Nice to know.

You're welcome!

I have uninstalled disks and HDD controllers many times and only ever had issues when the devices were in use. I've even pulled out SCSI drives, used Dell utilities to reconfigure RAID, then had the new RAID logical disks installed, all on a live system without rebooting. It's quite handy. You can try Microsoft's SysInternals' HANDLE.EXE to check for open handles to a volume, and close those handles, too.

Thanks for the hint. Will have to do some tests with this, once the basics work, the way i want it.

Yes. It was not meant as a suggestion for your scenario at all.

Ok.

[Sha0]

I mean exactly this problem...

Here's a solution: Remove all HKLM\WB-Setup\ControlSet001\Control\Class\{GUID}\????\ subkeys. They are for particular device instances, once installed. You'll notice that I386\SETUPREG.HIV only includes one device instance in this area: The network adapter used for RIS. You will find that even though you start out empty, when devices are installed they will begin to populate the class with subkeys.

I can't have a hardcoded driver for intel IDE Controller married to the general atapi driver.

Use CDDB or { Enum and Class } to support a particular device in your PE, but not both. An easy way to think of it is:

• CDDB is for device installation
• Enum and Control\Class\{GUID}\Subkeys are for installed devices

So if you hack Enum and Class, you are manually installing a particular device; there's no need for CDDB. But CDDB is more generic, so there's no need to know the exact details of an exact device, such as its parent "bus" device's "prefix" ID.

Maybe you'd enjoy this Microsoft web page instead of me going on and on.