XP SP2 image issue (mup.sys)

[Guest]

I am having an issue where I am building an XP SP2 image for my company
(which was built on a multi-processor machine) and it is failing on a
uniprocessor machine. I changed the HAL to Advanced Configuration and Power
Interface (ACPI) PC, rebooted a couple of times, and then recompiled my
image. I then loaded that image on a uniprocessor machine and the Windows
logo shows up for a brief second, and the machine then reboots. After reboot,
I have the option to boot into Safe Mode, at which point, mup.sys is the last
file that is displayed as being loaded. If I follow the exact same process
that I went through to create the XP SP2 image, using the XP SP1 source, this
problem doesn't exist. I've also tried slipstreaming the SP2 patch into my
SP1 source, and then recreated my image, but that also did not work. I've
tried to load my image, boot using BartPE, and then manually replace the HAL
with a different HAL, but that doesn't work either. I can make an SP1 image,
install SP2 over the top of it, and compile, but I want to do the XP install
with SP2 as part of it as it's a little cleaner. This has got to be an issue
with the HAL, but I can't quite figure it out. Any help would be much
appreciated.

Mike

 

[Guest]

Have met a lot of these disk-cloning issues as it's what I mostly do for
living, reasons are various, so here goes:

Firstly, mup.sys gets the flak for virtually every non-starting problem with
Windows. It's seldom to blame, rather it's just the last in the list of
devices loaded before the console part of the boot-process ends. So it always
looks like it's the one responsible when the machine locks-up a while later.
Usually it ain't.

Next, if an image built on one mobo won't boot on another, don't assume that
the second mobo has the same chipset - even if it has the same partnumber it
may not have the same components! Manufacturers get up to all sorts of
shenanigans in this respect, selling a whole series of electrically-different
machines under one badge.

Check the boot.ini partition-number is correct. If in doubt make two or
three entries and try each in turn. Note that a peculiarity of the
partition-table means that even on a disk with only one partition, that need
not necessarily be partition number one. This situation often arises if the
disk originally had a 'recovery partition' put there as part#1 by the
manufacturer. Then, Windows may be part#2. Or 3.

It is also worth booting to the Recovery-console and running fixboot and
fixmbr. Somtimes this resolves the issue.

Disk signatures are a major pain with regard to boot problems. This usually
arises if the disk has been used previously for NT/2K/XP. Formatting doesn't
remove the old signature, and what then happens is that Windows tries to
(wrongly) reassign the partition drive-letters on the basis of the signature.
This kind of lockup happens late-on into the boot, round-about when the GUI
would appear.. The cure is to edit the MBR with a hex editor, to remove the
sig. (Note, don't do this is the disk has RAID or merged partitions on it, in
that case you will lose the contents.)

If all the above fail, then you need to do a repair install. Boot from the
Windows CD, and select Install from the options. When the partition to
install-to has been selected, you will be given the choice to do a Clean
install, or a Repair install. Select the latter. This will repair the
installation but leave your other software and settings intact. When doing
this make sure you are using the correct type of Windows CD (Home, Corporate,
etc.) and have your serial ready.

Hope this helps.

 

[Adam Leinss]

=?Utf-8?B?TWlrZSBBbmRlcnNvbg==?=

I am having an issue where I am building an XP SP2 image for my
company (which was built on a multi-processor machine) and it is
failing on a uniprocessor machine. I changed the HAL to Advanced
Configuration and Power Interface (ACPI) PC, rebooted a couple of
times, and then recompiled my image.

How are you changing the HAL? Are you issuing
"UpdateUPHAL=ACPIPIC_UP,C:\Windows\Inf\Hal.inf" in sysprep.inf? If you
change the HAL to ACPI and then sysprep the machine, it will reset it
to whatever HAL you had before you sysprepped the image.

Yes, MUP.SYS issues are 99% HAL related.

Adam

 

[Adam Leinss]

Disk signatures are a major pain with regard to boot problems.
This usually arises if the disk has been used previously for
NT/2K/XP. Formatting doesn't remove the old signature, and what
then happens is that Windows tries to (wrongly) reassign the
partition drive-letters on the basis of the signature. This kind
of lockup happens late-on into the boot, round-about when the GUI
would appear..

Are you talking about GUID partitioning with x64? Disk signatures
shouldn't be a problem in the x86 architecture.

Adam

 

[Guest]

This is all happening before mini-setup even starts, so editing Sysprep.inf
will not help me at all.

 

[Guest]

Thanks for the detailed response, however, it does not correct my issue. I
know that mup.sys is not the issue for the reasons that you stated in your
response.

I don't believe that editing the boot.ini is going to resolve this as I
stated in my initial post that all works fine when I use the XP SP1 source, I
only have the issue when I'm using the XP source with SP2 slipstreamed in.
This seems to be more specific to the files that are included with SP2.

Performing a recovery from the Windows CD is not a viable solution as I need
to make 1 image that can be pushed to any machine in our environment (we have
5000 machines with about 10 different hardware platforms). Running a recovery
may fix it for that one machine, but it does not fix my issue of needing an
image to deploy to the whole environment.

I really believe that this is an issue with the HAL. I've opened a Premier
Support case with Microsoft and they stated that they do not support one
image for MP's and UP's and that the recommendation was to make 2 separate
images. This will not work for me either.

I think I'm going to take our existing XP SP1 image, put SP2 over the top of
it, and recompile and call it good as I know for sure this works.

Thanks for your help.