Foolproof Windows XP Image 0x7B Fix

If you’re like me and been deploying Windows 7/Windows 8 with MDT or SCCM…you really don’t want to go around touching XP images ever again. However unfortunately sometimes we have customers who absolutely need to continue to use XP for some reason or another. Often these images have much customization installed directly into the image, with pile upon pile of undocumented setup scripts, and custom .EXEs to complete the setup, and the person who created them has, of course, left the company. In addition these images typically fail on new hardware.

Quite often I’ve come across images where the sloppy IT pro has failed to add

[Sysprep]
BuildMassStorageSection=yes

[SysprepMassStorage]

to the SysPrep.inf as per http://support.microsoft.com/kb/303786

Which greatly increased the chance of seeing STOP: 0x0000007B a.k.a inaccessible boot device on booting:

image

If after deploying an image it just seems to keep restarting, and you can’t see any BSOD then hit F8 for startup options and select Disable Automatic Restart on Failure

In essence this is caused because necessary drivers are not installed.

I’ve found many “suggested” methods for fixing this that work in some scenarios but don’t in others.

To use my method first you need a working XP image…take option 1 or 2. (If 1 has been tried & failed, try 2)

1) Take a Windows XP install, SysPrep following guidelines here http://support.microsoft.com/kb/303786

2) Install vanilla Windows XP onto the model that you are trying to fix

Now you have your XP install, we need to boot into Windows PE  with command line access on the XP machine. If you don’t have a Windows PE disc handy, a Windows Vista/Windows 7 installation disc will be fine –> instead of running through setup hit Shift+F10 to get a command prompt.

On this XP machine, in Windows PE,  we now run the following commands (Assumes Windows XP image is on C partition):

  1. reg mount HKLM\_HKLM C:\windows\system32\config\system
  2. reg export HKLM\_HKLM\ControlSet001 ControlSet.reg
  3. xcopy C:\windows\system32\drivers\*.* <some storage location>\*.* /s

Now all we need to do:

1. Either mount our image if it’s a WIM or similar *or* in Windows PE deploy the image to the machine

2. Mount the system hive as we did previously

3. Reverse the export process i.e.

reg import ControlSet.reg

xcopy <some storage location>\*.* <path of C:\windows\system32\drivers in image> /s

We now have boot success!

image

This is an ugly fix, I’m not proud of it. But it does mean almost zero effort to get any XP image up and running… (assuming there is not HAL mismatch, but that’s a whole other issue…)

About chentiangemalc

specializes in end-user computing technologies. disclaimer 1) use at your own risk. test any solution in your environment. if you do not understand the impact/consequences of what you're doing please stop, and ask advice from somebody who does. 2) views are my own at the time of posting and do not necessarily represent my current view or the view of my employer and family members/relatives. 3) over the years Microsoft/Citrix/VMWare have given me a few free shirts, pens, paper notebooks/etc. despite these gifts i will try to remain unbiased.
This entry was posted in Deployment, Windows XP and tagged . Bookmark the permalink.

3 Responses to Foolproof Windows XP Image 0x7B Fix

  1. xpclient says:

    You could use Universal Imaging Utility (UIU) to deploy same XP image to multiple PCs independent of HAL. It eliminates lots of SCCM headaches too.

  2. Daniel Verberne says:

    Hello Chentiangemalc, very valuable forum and great post. I have had many STOP 7B issues since I’ve taken on a role that sees me having to build various Panasonic Toughbook units with Windows XP using SCCM 2012. Mostly I’ve been able to deal with the mass storage issue by ensuring that my Task Sequence in SCCM runs a WMI query on model, then installs/injects the appropriate SATA Mass Storage Drivers early in the build! (Yes, I’ve run into the HAL issue as well, so as a very messy solution i’ve had to resort to having an entirely separate WIM just for that particular model, ouch)

    • In the case of this customer they were using an old build process build on an ancient Novell installation, with Linux boot image deploying the image – there was no SCCM to be seen :( .. driver injection was via applying a custom ZenWorks image and an in-house built driver installation utility ..

Leave a comment