For those that still have to maintain XP images, today's article shows my trick for testing the validity of new mass-storage drivers. This enables me to confirm mass-storage support in sysprep in minutes rather than hours.

Introduction

The standard process for introducing  additional mass-storage support into your images is to use Microsoft's Sysprep. The general best-practice method for this process is as follows,

1. Open up VM containing 'golden' image
2. Add to sysprep.inf the device line for your new controller
3. Add to c:\sysprep\massstorage you new driver
4. Run Sysprep
5. Upload image
6. Deploy image on target hardware
7. Hope you don't go in a STOP 7B loop

One of the problems with this process is that sysprep does not flag if it fails to add a mass-storage driver referenced in sysprep.inf. Further, as most of us know, the above process takes at least 4 hours to see through end-to-end.  So to find on deployment that the mass-storage driver has not taken and you're in a STOP 7B reboot loop can be frustrating.

Having suffered this pain many times over my years with XP I developed tools and working practices to streamline the process. For example, to upgrade mass storage support I now just update my images offline and then backfill the support into the sysprep file. Driver identification is also pretty simple when using my driver profiler.  

When it comes to adding new mass-storage support however, there are no good shortcuts.  The process can be made smarter however. I add a step between 4 & 5 above to confirm that the mass-storage driver has taken. This enables me to determine that the driver is valid before proceeding to the image upload stages. This additional step saves hours (if not days); I only upload and test images which I am already confident that the mass-storage support has been successfully loaded into.

This is what I do.

Step 1 - Prepare VM with Golden Image

I have in my VMs various golden images which have been snapshotted before sysprep has been executed. So, I fire up the golden VM, and revert this back to the known clean state. If you do things this way, starting the process is painless and much less likely to make you groan when new hardware arrives...

Step 2 - Prepare C:\Sysprep Folder

For this phase, I copy my sysprep folder to the system drive. This contains the sysprep files, the mass-storage driver folders and a streamlined sysprep.inf file which contains only two mass-storage support entries. The first entry corresponds to the new driver I want to test, and the second is a known working driver.

Below is an example from some recent testing with a troublesome AMD driver,

[SysprepMassStorage]

; Test Driver -AMD AHCI Compatible RAID Controller
PCI\VEN_1002&DEV_4391&CC_0106=C:\sysprep\massStorage\AMD\ahcix86.inf 


; Known working driver for Dell Optiplex 990 and Latitude E6420/E6320
PCI\VEN_8086&DEV_1C02&CC_0106=C:\sysprep\MassStorage\ICH\iaahci.inf

Note that this is the entire SysprepMassStorage section from my sysprep.inf -everything else has been removed to allow rapid testing

Step 3 -Delete CriticalDeviceDatabase registry key

This phase makes the detection of sysprep added mass-storage drivers a little easier. Open up regedit, and navigate to the key HKLM\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase. This key contains the mass-storage driver data which is used by Windows on boot. Right-click it and delete it with all it's  subkeys.

This delete gives us a clean slate and makes it easy to see when support is added.

Step 4 -Run Sysprep

Now execute sysprep with the command,

sysprep.exe -reseal -mini -noreboot

This should be now very quick to run -typically less than a minute. On completion, hit refresh in regedit (no need to reboot) and you should see that the CriticalDeviceDatabase key has been recreated. It should now contain two entries which directly relate to the two mass-storage entries in your sysprep.inf,

If it turns out that you've only a single entry here for your known good driver, then you've got a problem. Double check that you've got all your driver files in the correct locations as referenced in sysprep.inf. If that all looks OK, then it's time to seek another driver, dump this in your referenced mass-storage folder, delete the CriticalDeviceDatabase key and try sysprep again. No need to reboot. 

If however it turns out that the CriticalDeviceDatabase key is not present once you've hit refresh, then you've hit one of those odd situations where sysprep just hasn't executed properly. Normally, if we sysprep with the standard several hundred line mass-storage sysprep file, the process can take about 20 minutes. However with such a trimmed down sysprep, it exits pretty quickly. It's therefore that's hard to judge if we've hit that premature exit scenario. This is why we have that known 'good' line in the sysprep.inf; it is so we can confirm that sysprep has indeed run and rebuilt the critical device database.

Step 5 - Do It For Real

Assuming you've managed to find a driver which loads into the critical device database, you can now update your production sysprep.inf with the driver entry. Simply revert your snapshot and go through the full sysprep process.

Conclusion

Today's tip takes some of the uncertainty and pain away when adding mass-storage support into your sysprep.inf files. I find that although this adds an extra 10 minutes to my process, it adds confidence to my sysprep image uploads, and potentially saves many hours when encountering troublesome drivers.

The difficulty is now simply in finding the right driver in the first place. For that you can help yourself a little by checking that you've got a driver which has properly decorated with OS versions. For example below is an extract from an inf file which I'd consider to be good,

[Manufacturer] 
%ATI%=ATI,NTx86.5.1,NTx86.5.2


[ATI.NTx86.5.2]
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4392&CC_0104
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4393&CC_0104
%NapaDesc%=Napa_Inst,PCI\VEN_1022&DEV_7802&CC_0104
%NapaDesc%=Napa_Inst,PCI\VEN_1022&DEV_7803&CC_0104


[ATI.NTx86.5.1]
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4391&CC_0106
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4392&CC_0104
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4393&CC_0104
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4394&CC_0106

[Manufacturer] 
%ATI%=ATI

[ATI]
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4392
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4391
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4393