Video Screencast Help

Offline Updating of Mass-Storage Controllers in XP

Created: 16 Sep 2010 • Updated: 05 Nov 2010 | 7 comments
ianatkin's picture
+4 4 Votes
Login to vote

Mass-storage controllers and Windows Imaging. As a combination, they're kinda like Uranium and critical-mass. Once the two come together, you really wish you were somewhere else.

Today I'll show you how to avoid meltdown and emerge radiation free from those not-so-rare confrontations with next-generation mass-storage controller hardware. With this download, you'll be able update the mass-storage support in your images within seconds, giving legacy images a new lease of life. With luck, this will free up the valuable time needed for your NS7 and Windows7 upgrades ;-)

Feel free to ammend, update and post revisions of this script back to Connect!


A few months ago, new PC and laptop hardware started to arrive at the office. As I stepped through the hardware evaluation process, the problem I dreaded most surfaced -the models were blue screening in mini-setup with the STOP 7B error message. This is never good. Sysprep images can tolerate Plug'n'Play device variations in the mini-setup process, but foreign mass-storage controllers are quite simply a killer. If setup cannot see the disks, it just can't proceed with install.

Altiris have tried to address this problem natively with DeployAnywhere, but this technology is now only being matured on the DS7 branch so will remain a little stunted in our DS6.9 environment. It also of course relies on WinPE automation for the driver injection process, and our primary automation environment is (of course) Linux.

So, for me it was a return to the Microsoft text-book process for extending mass-storage support in my sysprep images,

  1. Downloaded and unpacked the XP Mass-storage Drivers
  2. Collected the device IDs for the new model
  3. Added the device IDs to sysprep.inf to build driver support into the image
  4. Rebuilt image, sysprep'd and uploaded to server
  5. Tested image

And this has to be done for each image. I should add here that I'd previously completed a round of mass-storage updates for Linux automation in both the and kernel flavours. This meant that automation could see the disks just fine, so this allowed me to focus purely on adding similar support into our Windows XP sysprep process.

Within a couple of days I'd finished re-creating and syspreping the images, so it was time to hand off them off for further testing. This is actually the real resource hog -to be sure I hadn't broken anything, the images had to be tested against every model in our test lab. After a few days I got the all-clear, so the job was a good'un and I could once again get back to the day job.

Imagine my joy then when two weeks later I was informed our main desktop model was about to go end-of-life. The replacement was also not  going to be one of the model's I'd just ratified. The new PC arrived the next week and while testing, lo and behold, the blue screens were back. This PC had a different flavour of the Intel5 series controller, one whose support I had not added into the image. I cursed myself at length for not adding all the device IDs from the latest Intel Matrix controller into the sysprep.inf file, and then promptly went off to the pub -I simply couldn't face rebuilding the images again.

Whilst reflecting over a pint of Guinness, I realised my expectation of our hardware procurement cycle bearing any resemblance to our image-rebuild cycle was just naive. It was time to get a bit smarter on this one. So, instead of spending the next few days re-building images, I spent the time instead looking at how I could script the injection of updated mass-storage controller drivers into our images.

The result was the attached little script which in about 5 seconds does the following,

  1. Mounts the XP image file
  2. Injects the mass-storage device support into the Windows registry
  3. Injects  the updated mass-storage driver
  4. Unmounts the image 

I've tried to make this script robust, but there are as always improvements to be made -so feel free to tweak. For example, in its current form this script only copes with updated mass-storage controllers -not entirely new ones. This isn't a huge problem for us (where every Dell and HP model we have seems to use an Intel controller) but it's worth flagging. I'm working on a proper INF parser to automate driver injection, but I don't exepect this to be ready for some weeks.

Let's crack on then and see how this script can be used.

Using The Mass-Storage Injection Script

Attached to this article you'll find the batch file UpdateImage_Lite_v1.1.bat. The top section of the batch file is the user-editable section, and looks as follows,

::      --------------  Start of user-editable Section --------------   
SET Img_Path=S:\Images\Windows\test
SET Img_File=XPSP3.img
SET Volume_Name=

SET Image_Explorer="C:\Program Files\Altiris\Express\Deployment Server\ImgExpl.exe"

SET Driver=C:\MassStorage\ICH\iaStor.sys
SET Vendor=8086
SET Device=2929
SET Service=iaStor
:     --------------  End of user-editable Section --------------     

This script header contains all the variables the batch script requires to update your image, and i've pre-populated it with example entries for you. Broadly speaking, there are three sections,
  1. Image Location Data
  2. Image Explorer Location
  3. Driver Data

Let's take a look at how to configure these now.

Image Location Data

In this section, we have the following variables,

  • Img_Path
    This variable holds the absolute path to image file, and excludes the filename. In this case, my image is on the S:\ mapped network drive. UNC paths cannot be used.
  • Img_File
    This variable stores the filename for the image
  • Volume_Name
    Normally this is blank (at least it is in all of my images). However if you specifically configure a volume name in your images, you'll need to declare it here. You can use ImageExplorer to check if a volume name has been set. 

Image Explorer Location

This section has just the one variable,
  • Image_Explorer
    This is the absolute path to Image Explorer. I generally expect admins to execute this from the Deployment Server,  so I've here configured the location Image Explorer to be on the express share (assumed on the C:\ Drive). This must again be an absolute path -UNC paths are not acceptable.


Driver Data

This is where it get's tricky.
  • Driver
    Full path to the updated driver which needs to be injected into the image. Here i've used the classic example of a revised iaStor.sys
  • Vendor
    This is the vendor ID. Most of us will indeed only be using Intel (8086) but a few out there might indeed be using ATI/AMD chipsets (1002)
  • Device
    This is the device ID for the controller in question. This can be scavenged from a new PC by opening up Device Manager, and viewing devices by connection. This allows you to navigate down the PCI bus, to the mass-storage controller and finally to your disk is hanging off it,

    To get the device ID for the controller, all you need to do now is take a look at the controller's properties,

    The Details tab reveals all as above.  In the above example of the Intel ICH9M SATA AHCI controller, the device ID is 2929 as highlighted. This Device ID should of course match up with an entry in the driver INF file you've downloaded for the injection process. In this case, the iaAHCI.inf file has the following matching entry,

    %PCI\VEN_8086&DEV_2929&CC_0106.DeviceDesc% = iaStor_mobl_Inst, PCI\VEN_8086&DEV_2929&CC_0106

    Which you can find by scanning the inf file for the Device ID string "2929". This agreement between Device ID string revealed by Device Manager and your driver INF file provides the confidence that the driver you've downloaded for the mass-storage controller will work nicely once injected into the image. 


Running the Driver Injection Script

Now you've configured the script, let's run it. First, change the .txt extension to .bat. Next, ensure you have local admin rights on the machine your are running on (this is necessary to allow the script to mount a system hive), and you'll need full rights to the image file location.
On execution, you should see a window similar to that below,
Here you can see that the script found and successfully updated the image with the configured mass-storage driver entry. Should you now deploy this image,  you should find to your amazement that those STOP 7B error messages have vanished!

Auditing the Injection

In order the keep track of the changes made to your images, the injector script creates a folder called Mass_Storage_Injection which lives with the amended image file. In this folder you'll find a date-stamp folder, and within that a log of the process with the original (and modified) system hive.
This not only enables you to keep track of exactly what was done to the image, but it also gives you the chance to restore the registry should you need to.

What Does the Injection Script Do?

If you've gotten this far, its because you want to know a bit more about how the script works. Here's the basic steps,
  1. Check Variable Sanity
    In order for the script to have a chance at executing successfully, the user-defined section of the script must be sane. This means for example, that image file must be present, and ImageExplorer available.
  2. Create Log Folder Structure
    As the script is going to be making registry changes in your image, we need to find a place to log all the changes we're going to make and store the unmodified registry hive. Using mkdir magic with time stamps variables, this stage ensures we create a suitable folder structure.
  3. Extract System Hive
    Did you know that ImageExplorer can be executed in batch mode? Well it can! This stage extracts from the image the system hive (C:\Windows\System32\Config\system) in silent mode and saves as backup copy as system.original
  4. Load the System Hive
    Using the windows reg load command, the system hive from the image is then loaded under HKLM\TempHive
  5. Add Critical Device Database Entry
    If a deviceID and VendorID have been entered, we can populate the critical device database section in the Windows registry (HKLM\TempHive\ControlSet001\Control\CriticalDeviceDatabase).
  6. Unmount the System Hive
    Using the Windows reg unload command, the system hive is unloaded from the windows registry
  7. Inject the modified System Hive back into the Image
    Using Image Explorer in batch mode once again, the modfied system hive is added back into the image
  8. Inject the Updated Mass-Storage Controller Driver
    If a driver is specified, this in injected using Image Explorer in batch mode.


And that's it. Future versions may be a bit more intelligent... am working on it!

Kind Regards,

Comments 7 CommentsJump to latest comment

duricam's picture

hi Ian,

I would like to port windows XP (SP3) installation to a notebook that has landed on my desk.

the thing is, that the original PC is an IDE based machine and the notebook is a SATA AMD based stuff. the notebook is HP Pavilion dv5 model 1240ec (with AMD Turion X2)

I found AMD SATA driver that should be used for the SATA device (pls see attached).

I found that ..86 version of the driver should be used (not the 64bit one).

it is in sp39719.exe and can be downloaded from:

I also found some scripts on this site that can inject SATA driver to an existing XP installation, however, those deal just with Intel drivers.

could you please help?



Login to vote
ianatkin's picture

Hi Milan,

Yeah -this script is only for upgrading. I simply haven't had time to getting a full driver injection script sorted with an INF parser. Its a project for one of those moments when I get time........

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads

Login to vote
APMC's picture

Hi Ian,

I just wanted to thank you for the countless hours your off-line update script has saved me. Excellent job!



Login to vote
ianatkin's picture

No problem Martin -glad its helped!

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads

Login to vote
b3tts32's picture

Wow I can't believe I've never seen this article. I'd been in the same boat as well when it came to updating one by one each time a new model came in. I'm really excited about this as I am about to start another HII project with a new company. 

Login to vote
ianatkin's picture

Good luck with the HII project -this script is great at saving those many hours of image donkey work. Remember though it only works for upgrading mass storage support ok?

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads

Login to vote
tloenhorst's picture

Outstanding effort. Will save many hours of work for us all!

Login to vote