1

(41 replies, posted in Universal Imaging)

eethball wrote:

Now I’m asking out of desperation since I can’t seem to get my universal XP image working and I hoping that you (or someone in this forum) had a second to look at what I’m doing and see where I’m going wrong. Basically I have the vmware machine that I’d like to image. Since I have a very large amount of different hardware I’d like to use this image on I’ve been creating the DriverPack-MassStorage folder using the CreateMassStorageData.exe and I’ve replaced the ntldr with that of the XP x64 system to avoid the ntfs.sys error. Now I’ve tried different versions of sysprep, and my last test was with sysprep.exe version 5.2.3790.1830 with no pre-configured sysprep.inf added to the sysprep folder on my BartPE disk. When running OFP I selected do nothing from the HAL options (just to rule that out as causing the problem), and the only thing that I selected from the advanced options is say “Install all DriverPacks non-IDE Mass Storage Device(s)”. When sysprep opens I selected “Don’t reset grace period for activation” (since I’m using VLK OS), Use Mini-Setup, and set the shutdown mode to quit. Then I clicked reseal, and when sysprep closes I shutdown the machine from BartPE. Then I try to boot machine I always seem to get the error message saying An error has been encountered that prevents Setup from continuing. Windows is unable to start because the registry could not be updated… I’ve seen other people in the forums mentioning they’ve received this error, but almost everyone says it has something to do with their sysprep.inf, but since I deleted mine for testing and still receive the error message I seem to be stuck. Any help would be appreciated.

Here's the official KB:
http://support.microsoft.com/kb/818171

Just a stab in the dark, but try not checking "Don't reset grace period..." I use VLK as well and have had no issues.

If that doesn't work, try reverting back to the default ntldr (just to see if that's the problem) and/or running fixboot on the partition.

2

(41 replies, posted in Universal Imaging)

StylusPilot wrote:

OfflineSysprep Issue

"An Error Occurred while trying to update the registry"

I have read this issue is either caused by having a read only sysprep.inf, or having the build mass storage in sysprep.inf

neither of which I have.

what else causes this? how can I diagnose?

I am so close to a universal image lol

This may not be your problem, but this happened to me a couple of times:

OfflineSysprep will copy the sysprep.inf (all the sysprep files, actually) from the OSP folder and overwrite whatever is on the target drive/image. So if you're making changes to the sysprep.inf in your image, make sure you copy it to the appropriate OSP folder (either UnderWindows\sysprep or BartPE\sysprep) before running OfflineSysprep.

3

(5 replies, posted in Universal Imaging)

If you are using ACPI PC for your base HAL, then it should boot at least once on everything. If your image is not booting even once (i.e., before Sysprep mini-setup), then the mass storage drivers are most likely your problem. Specifically, the [SysprepMassStrorage] section in the sysprep.inf, in my experience, does not work. At all. Just delete it from the file.

The quick way to work around this issue is to boot into the BIOS configuration and change the SATA mode to "Legacy" or "IDE Compatibility" (or something like that). The image should boot up fine and work like normal, but you won't get some of the fancy SATA features like hot-plugging or NCQ.

The better way, as others have suggested, is to use OfflineSysprep inject the MassStorage drivers. It takes a few extra steps (you have to create a BartPE plug-in from the driverpack), but it works very well.

Well, since ACPI has been out since 1996, I personally have no use for the Standard HAL (nor hardware to test it on). However, given the concept used to detect APIC, it should be trivial to add code to detect ACPI as well. It appears that the ACPI feature flag is the 22nd bit in the EDX register. So the code to check it would look like this:

$ini = IniRead($tempvariable & "\temp.txt", "CrystalCPUID", "Number (Total)", "not_found")
If $ini > 1 Then $cpu_count = "multi_processor"
$ini = IniRead($tempvariable & "\temp.txt", "CrystalCPUID", "Physical Core", "not_found")
If $ini > 1 Then $cpu_count = "multi_processor"
$ini = IniRead($tempvariable & "\temp.txt", "CrystalCPUID", "Hyper-Threading", "not_found")
If $ini > 1 Then $cpu_count = "multi_processor"
$ini = IniRead($tempvariable & "\temp.txt", "CrystalCPUID", "00000001", "not_found")
$acpi_hex = Dec(StringMid($ini, 30, 1))
$acpi_flag = Mod(BitShift($acpi_hex, 2), 2)
$apic_hex = Dec(StringMid($ini, 33, 1))
$apic_flag = Mod(BitShift($apic_hex, 1), 2)
If $cpu_count = "uni_processor" Then
	If $acpi_flag = 0 Then
		$Hal = "STANDARD"
	ElseIf $apic_flag = 0 Then
		$Hal = "ACPIPIC"
	Else
		$Hal = "ACPIAPIC_UP"
	EndIf
ElseIf $cpu_count = "multi_processor" Then
	$Hal = "ACPIAPIC_MP"
EndIf

Also, you may notice that I changed my logic a little bit (for reading the bit values). I'm new to AutoIt, so I didn't think to look for a BitShift function until just now. tongue It should work the same, just be simpler and easier to understand. I edited my former post also to reflect this.

Again, I don't have the hardware to test the standard HAL detection, but I'm pretty confident that it would work, assuming that the CPUID flag is accurate.

I think I may have figured it out. Here it is for anyone who is interested:

The primary CPUID feature flag that determines ACPI Uniprocessor HAL support (as opposed to the ACPI PC HAL) is the APIC flag. It is the 9th bit in the EDX register after calling the CPUID instruction with 0000_0001h in EAX (see: http://www.sandpile.org/ia32/cpuid.htm).

I added code to OfflineSysprep to check that bit and then determine the HAL based on its value. The original code looks like this:

$ini = IniRead($tempvariable & "\temp.txt", "CrystalCPUID", "Number (Total)", "not_found")
If $ini > 1 Then $cpu_count = "multi_processor"
$ini = IniRead($tempvariable & "\temp.txt", "CrystalCPUID", "Physical Core", "not_found")
If $ini > 1 Then $cpu_count = "multi_processor"
$ini = IniRead($tempvariable & "\temp.txt", "CrystalCPUID", "Hyper-Threading", "not_found")
If $ini > 1 Then $cpu_count = "multi_processor"
If $cpu_count = "uni_processor" Then
	$Hal = "ACPIAPIC_UP"
ElseIf $cpu_count = "multi_processor" Then
	$Hal = "ACPIAPIC_MP"
EndIf

And the code which detects lack of APIC support (for the ACPI PC HAL) looks like this:

$ini = IniRead($tempvariable & "\temp.txt", "CrystalCPUID", "Number (Total)", "not_found")
If $ini > 1 Then $cpu_count = "multi_processor"
$ini = IniRead($tempvariable & "\temp.txt", "CrystalCPUID", "Physical Core", "not_found")
If $ini > 1 Then $cpu_count = "multi_processor"
$ini = IniRead($tempvariable & "\temp.txt", "CrystalCPUID", "Hyper-Threading", "not_found")
If $ini > 1 Then $cpu_count = "multi_processor"
$ini = IniRead($tempvariable & "\temp.txt", "CrystalCPUID", "00000001", "not_found")
$apic_hex = Dec(StringMid($ini, 33, 1))
$apic_flag = Mod(BitShift($apic_hex, 1), 2)
If $cpu_count = "uni_processor" Then
	If $apic_flag = 0 Then
		$Hal = "ACPIPIC"
	Else
		$Hal = "ACPIAPIC_UP"
	EndIf
ElseIf $cpu_count = "multi_processor" Then
	$Hal = "ACPIAPIC_MP"
EndIf

I've done some initial testing, and the results are positive. I was able to get three different HALs on three different computers (each hardware type had its appropriate HAL) using a single image with no overlays. If anyone wants to try this, let me know how it works for you.

I was wondering if there has been any progress made on how to detect and automatically choose between the three main types of HALs--ACPI PC, Uniprocessor, and Multiprocessor--instead of just the latter two. This is for Windows XP SP3.

My current method for working around this issue is to use an image which allows Sysprep to choose Uniprocessor/Multiprocessor, and if the computer needs the older ACPI PC HAL, just manually overlay a "corrected" sysprep.inf on top of that image (which tells Sysprep to leave the default ACPI PC HAL unchanged). This works well, but I would prefer an automated solution.

I was hoping that OfflineSysprep would be the answer, but unfortunately it doesn't seem to be. The last information I can find from Galapo is this:

Galapo wrote:

OfflineSysPrep auto HAL detection on first boot only works with acpi uniprocessor and acpi multiprocessor machines. . . . I wish I had hardware to test and then I could improve it. I would like to know of a way to detect whether a system supports acpi but not acpi uniprocessor. Probably this would then solve most of your issues. Then I would like a way to detect whether a system supports acpi and if not default to standard.

So, in other words, it does the same thing the Sysprep is already doing for me.

I was hoping to perhaps modify OfflineSysprep's process myself to make it work for all three HALs. As of yet, I can't find a reliable way to do it. Currently, OSP just grabs the number of cores and/or hyperthreading capability from the CrystalCPUID dump. Is there a CPUID feature flag that could delineate support for ACPI Uniprocessor vs. ACPI PC (the older one)?

I'll keep poking around myself, but I thought I might ask the much smarter people on this forum to see if any progress has been made here. Thanks. smile

7

(12 replies, posted in News)

New design looks fantastic! Keep up the good work.

Have you tried using Group Policy?

Computer Configuration -> Administrative Templates -> Windows Components -> Windows Media Player -> Prevent Desktop Shortcut Creation

I wouldn't try to script it, but if you can set it in your image before sysprepping, it may work.

I recall seeing something online stating that this fix doesn't work on Windows XP SP3 (I am using SP2). That might be the problem.

I use this registry setting to block the creation of a WMP11 shortcut after Sysprep:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{6BF52A52-394A-11d3-B153-00C04F79FAA6}]
"StubPath"=-
"HideStubPath"="rundll32.exe advpack.dll,LaunchINFSection C:\WINDOWS\INF\wmp11.inf,PerUserStub"

I have a Windows XP Sysprep image with DriverPacks that will not boot on a Lenovo A61e small form factor. I don't think it's missing mass-storage drivers because the Windows XP startup sequence churns for about 15 seconds, then the computer reboots, and this cycle is repeated endlessly until powered down. The chipset is the AMD 690V. The image works on all other computers. Any ideas?