Install setup problems for large disks/partitions with dual boot

[os2fan2]

setupreg.hiv contains settings for the the drivers and services loaded by the boot process.

Windows XP evidently has a different set of drivers, i should not be tempted to swap this file without serious work on the system.

On the other hand, you can slip some rather interesting things by adding XP files to 2K. See, for example, my HIVEFIX.INF, which runs at the end of text-mode install, just before the install of $OEM$.

[mikesw]

setupreg.hiv contains settings for the the drivers and services loaded by the boot process.

Windows XP evidently has a different set of drivers, i should not be tempted to swap this file without serious work on the system.

On the other hand, you can slip some rather interesting things by adding XP files to 2K. See, for example, my HIVEFIX.INF, which runs at the end of text-mode install, just before the install of $OEM$.

I'll take a look at it.

To fix my OS install disk, what would be the most preferred way to fix the registry for the large disk

after the OS is installed.? RunOnce or cmdlines.txt. The reason I ask is that from what I've read,

runonce only is run upon the first login. I assume it doesn't have to be administrator since I could

use Nlite to preinstall user accounts that I could use for first login. However, if I don't do a first login

for awhile, then while the system is booted and running (particularily when anitvirus software may

be running in the background and scanning the large disk/partition, or I have alot of applications installed

on the partition with the OS that they all exceed the 137 gig limit), the disk could be corrupted for large drives until

I login and the registry is then updated with the large disk fix. Of course the setupreg.hiv file has

been modified now in preparation for reburning the CD/DVD, so this isn't an issue anymore during initial install.

Perhaps I'm misinterpreting things. That is by modifying the setupreg.hiv file via the ControlSet001, that after

completing the OS install, Windows installation then copies the ControlSet001 with the EnableBigLba set to the

real live registry under ControlSet (not 001 or 002). Hence, on first login or even reboot, there are no further

changes needed since the registry that is used after this already has it set. Correct me if I am wrong!

The bottom line is, is enabling large drives just a one step process or is it a two step one due to modifying the

registry in one file vs two different files at different times of the install process.

Edited November 29, 2007 by mikesw

[os2fan2]

The 'currentcontrolset' in Windows points to the current settings of an active windows. This is a marker pointing to either controlset000 or controlset001.

When windows is not active, there is no 'currentcontrolset', and only 000 or 001 is 'current'. For windows that has never saved a registry (eg cmdcons, bartpe, winpe, install), there is only 000.

The best way to fix it is to run it on install. If it is up and running, you can just use regedit to modify the setting in currentcontrolset (rather than 000 or 001). If it lies unbooted but accessable, load %targetroot%\system32\config\system in registry and make the modifications. %targetroot% points to the systemroot of the system to be modified, as seen from the modifying system.

[mikesw]

The best way to fix it is to run it on install. If it is up and running, you can just use regedit to modify the setting in currentcontrolset (rather than 000 or 001). If it lies unbooted but accessable, load %targetroot%\system32\config\system in registry and make the modifications. %targetroot% points to the systemroot of the system to be modified, as seen from the modifying system.

If I read you correctly, then in addition to running the batch file on the I386\setupreg.hiv file, saving it and

reburning a CD/DVD, I must also create a batch file that is part of the runonce or cmdlines.txt which

then modifies the registry too, but perform this on the %targetroot%\system32\config\system

registry file that was copied to the newly formated drive before the OS starts booting up for the first time.

Thus, the T-12 time pertaining to "first login" doesn't mean I bootup, login as a user and then at this point

the registry fix is applied by the install disk, but does mean that it is applied after the files for the OS are copied/installed

to the harddrive at which point the "system" registry file is patched and saved. After this, the OS is told

to bootup to finish the rest of the install such as entering the license, timezone/country for keyboards, currency etc.

followed eventually by the user login prompt screen. At this point it is considered "first login" since in the previous

steps no one every logged in before.

I see from the unattended install manual from msfn the following for the runonceex.cmd of the Summary section

of page 37.

To summarize, RunOnceEx.cmd will be executed during the GUI-mode of Windows XP Setup at the T-12 Minute stage. This however does NOT mean that your programs will install. After reboot and first logon, RunOnceEx will start as shown here, and begin installing your programs.

However, I want to get the registry fix for the big disks into the just installed registry as fast as possible due to

my applications that will be installed exceeding 137 gigs. Thus per the same page I see this if one wants to

have RunonceEx execute immediately after importing things (but before a reboot to first login),

rundll32.exe iernonce.dll,RunOnceExProcess

Thus I take it the EnableBigLba registry fix can be loaded into the registry via RunonceEx immediately

by doing the rundll step. I presume that after all the RunonceEx commands are loaded this is run as the first

step of the runoncex cleanup.cmd routine before deleting the apps in the install directory.

Question: Once the rundll command is run and the registry modified, does this mean that it is

saved to disk like it would be under a registry unload due to a PC reboot to get to first login? If this is the case, this

probably will be the best route to go before all the apps are loaded and filling up the disk.

Or would this be better based on the unattended manual from msfn on page 115 by using a *.reg file for hklm

and using "regedit /s ...." since they say it modifies the registry immediately and during reboot to first login

the registry is ready to go. I assume the regedit isn't fully unloaded with the updated hives til the reboot is

started.

Edited November 30, 2007 by mikesw

[os2fan2]

When you modify registry by loading an uninstalled hive, it takes effect on the next time it is loaded.

The 48bit lba needs to be implemented by the system that loads initially, which is why it is done in setupreg.hiv. Setupreg.hiv is then modified by the processing of HIVESYS.INF, and forms the basis of %systemroot%\system32\config\system.

You don't need to do any further modifications to either hive*.sys, or loading registry settings at T12, or runonce.txt etc. It's done even before T39, because even the cmdcons session has it. Basically, there are four points where registry is modified.

• SETUPREG.HIV, modifies even the text-mode installation. The destination for this hive is "hklm\system"
  
• HIVE*.INF: modifies windows before either Windows or Users directories are created. These can be modified here. $OEM$ is copied at this time.
  
• CMDLINES.TXT: operates when user SYSTEM uses default-user to create ALL-users settings.
  
• RUNONCE and GUIRUNONCE runs in the context of the first logged in user,
  

Note that HIVESYS.INF augments what already exists in setupreg.hiv, the SYSTEM hive is a composite of both of these files. Because the 48bit lba needs to exist at the text-mode setup, you need to modify setupreg.hiv

[mikesw]

When you modify registry by loading an uninstalled hive, it takes effect on the next time it is loaded.

The 48bit lba needs to be implemented by the system that loads initially, which is why it is done in setupreg.hiv. Setupreg.hiv is then modified by the processing of HIVESYS.INF, and forms the basis of %systemroot%\system32\config\system.

Note that HIVESYS.INF augments what already exists in setupreg.hiv, the SYSTEM hive is a composite of both of these files. Because the 48bit lba needs to exist at the text-mode setup, you need to modify setupreg.hiv

Thanks. Your answer explains it very clearly what happens when.

I thought that this is how it worked from a few posts back about how the setupreg.hiv is used and merged with other

stuff to form the registry hive SYSTEM and saved to disk for later bootup but I wasn't sure.

Therefore, I won't put the LBA fixes into the cmdlines.txt and runonce stuff, but play with these files later for other stuff.

I'll rely on the setupreg.hiv corrections for my large disk problems.

Question but a little off topic:

Do you know anything about what causes bad block errors being recorded into the system event log for the hard drive?

Presently, I see these being recorded when Acronis trueimage workstation v9.1 (and their new replacement trialware ECHO) is run, the user display is shown and I immediately exit the program. It creates this error only when starting the program to the point where the user display is shown. It doesn't do this on a Windows XP Pro SP2 system but only on a Win 2K Pro Sp4. The diskcheck and scandisk don't show any errors though. I realize there is a bad cluster table that is recorded on the hard disk so the OS knows not to use these. I think that this table is maintained during formating or check disk/scan disk. Hence, this table is recreated everytime one of these is performed since during formating this table would be erased. It must verify that the space allocated to this table must be good before recording this bad cluster table. Presently, the Win 2K Pro SP4 system has the LBA fix in the registry due to me manually putting it there so this shouldn't be the cause. Moreover, Seagates Discwizard and Maxtors MaxBlast software that you get is a limited version of Acronis software that one uses to copy ones files/OS' over to the new drive from the old one. In my case going from a Seagate 40Gig drive to a Seagate 750 Gig drive with multiple partitions and some being 260 Gigs each, along with OS patches and various software archive backups. The Discwizard and MaxBlast (latest version)also have this problem of causing a bad block error to be written to the system event log.

MSofts site doesn't seem to go into detail as to what conditions have to be met before a "bad block" error message

is recorded to the system event log. So I don't know if it is the MBR, the pagefile.sys, other critical OS files

or some other, OS, application or user file that is causing it.

The actual system event log error message is event ID 7 for source "disk" that writes "The device \Device\Harddisk1\DR1, has a bad block". I've had single partitions that contain the OS, and even dual-boot MSDOS/Win 2K Pro Sp4 partitions where the OS is on the second partition give this error. Thus, with the OS being located on different parts of the disk surface (not at the beginning of the disk) one would think that the bad block error would disappear - it doesn't.

Any clues, or windows tools that will record/trap the cause of this error and give more information to go on?

Edited December 3, 2007 by mikesw

[jaclaz]

Question but a little off topic:

Do you know anything about what causes bad block errors being recorded into the system event log for the hard drive?

In some occasions I saw this kind of errors when an "under-spec" or faulty cable was used, typically using 40 leads IDE cable on ATAPI 66/100/133 drives or using one of those removable HD trays that internally use 40 leads cables instead of the proper 80 leads ones.

Replacing the faulty cable got rid of the error in Event Log.

jaclaz

[mikesw]

Question but a little off topic:

Do you know anything about what causes bad block errors being recorded into the system event log for the hard drive?

In some occasions I saw this kind of errors when an "under-spec" or faulty cable was used, typically using 40 leads IDE cable on ATAPI 66/100/133 drives or using one of those removable HD trays that internally use 40 leads cables instead of the proper 80 leads ones.

Replacing the faulty cable got rid of the error in Event Log.

jaclaz

Jaclaz,

Hmmm, the cable is an 80 lead one and not the old 40 lead one. Also this happens on two different computers

that are from the same manufacturer, an IBM Netvista. If this is the case of a bad cable on one computer

then the possibility of two different computers having a bad cable should be slim. I'll dig around and see

if I have another cable and try that out and see what happens.

Is there a tool that will stress test the computer and hard drive read/write while the Win 2K Pro SP4

OS is still installed so that I can monitor the system event log to rule out perhaps cables and/or the

Acronis software?

os2fan2,

After reburning the Win 2K Pro SP4 software to a CD which contained the modified setupreg.hiv file,

I reinstalled the OS, and it recognized the seagate 750 GIG drive by showing that there was space

beyond the 131/137 GIG limit during partition allocation. Moreover, after installation of the OS,

the SYSTEM registry also contained the EnableBigLba flag as being set too.

Thanks, it works great.

Here's the file LargeDisk_48bitLBA_README.TXT file I put in the root directory of the reburned

Windows 2K Pro SP4 OS install disk for future reference. It contains the instructions on how

to make the cmd/bat file to remake a modified Win 2K Pro SP4 OS install disk for large disks.

Of course this contains information from other peoples posts but contains comments and the

addition of changing the read-only permission on the setupreg.hiv file, modifying it and

then making it read-only again so that after install the hive remains read-only on the HDD.

REM
REM  Batch file name: Large137Gig_LBA_patch.cmd
REM
REM  Instructions to run:
REM	 a). copy the Windows 2K SP4 OS to the hard drive.
REM	 b). copy this LargeDisk_48BitLBA_README.txt file
REM		 to the Batch filename above.
REM		NOTE: The current Windows 2K SP4 install disk
REM			   has already had the setupreg.hiv modified
REM			   for large 48bitLBA disks >137 Gigs. The
REM			   steps are only documented here for reference in
REM			   modifying a Windows 2K SP4 OS that hasn't
REM			   been fixed yet.
REM	 c). modify the winsource pathname to the HDD letter
REM		 and pathname so that the I386 of the OS directory
REM		 is referenced.
REM	 d). run this batch cmd file at a DOS command prompt
REM		 window which will modify the setupreg.hiv file which
REM		 then unloads the hive to the disk to save the new copy
REM		  to the I386 directory followed by removing the LOG file.
REM	 e). delete the cmd filename that was created
REM	 f). reburn the CD/DVD with the modified Windows 2K SP4 OS.
REM	 g). Install the Windows 2K SP4 OS with the 48bit LBA
REM		 large disk support patch and test it.
REM 
REM  This cmd batch file will modify the setup registry hive
REM   \I386\setupreg.hiv to allow large disk support > 137 gigs.
REM  It is used during Windows 2K SP4 OS install, by the Recovery Console,
REM  and it is used to make the SYSTEM hive file used during
REM  normal OS operation which is created before reboot to first login.
REM  If the setupreg.hiv is not modified, the Recovery Console will generate
REM  a Stop 0x7B, with the error message INACCESSIBLE_BOOT_DEVICE; and during
REM  normal operation of the Windows 2K SP4 OS, disk partitions greater than
REM  137 gigs may become corrupted.
REM
REM   Modify the winsource path of the I386 directory after
REM   copying it to the hard disk. Then modify the OS disk before
REM   reburning it to the CD/DVD.
REM
REM   The reg.exe v2.0 command is part of the WIN 2K OS support tools
REM   which is needed to modify the registry from the DOS command line
REM   prompt so that the setupreg.hiv can be modified. The support tools
REM   for Windows XP contains a reg.exe file that is v3.0 which will work
REM   with the Windows 2K SP4 OS.
REM
REM   For the setuppreg.hiv on initial OS install, the ControlSet001 is
REM   used since it imitates as if a previous configuration was created
REM   from a first login that wasn't performed yet. During normal operation,
REM   and after first login, the ControlSet is used with 001 and 002 used as
REM   backup config copies.
REM

setlocal
set winsource=H:\ZRMPOE~1\I386
attrib -A -R %winsource%\SETUPREG.HIV
reg load HKLM\Setup %winsource%\SETUPREG.HIV
set regkey=ControlSet001\Services\atapi\Parameters
reg add HKLM\Setup\%regkey% /v "EnableBigLba" /t "REG_DWORD" /d "00000001" /f
reg unload HKLM\Setup
attrib +A +R %winsource%\SETUPREG.HIV
del %winsource%\*.LOG
set winsource=
set regkey=
endlocal

Edited December 3, 2007 by mikesw

[heffalump]

Is it possible to do a query of an existing setupreg.hiv just to check the LBA key? Just want to read the value to see if it is in there... thanks!

[mikesw]

Is it possible to do a query of an existing setupreg.hiv just to check the LBA key? Just want to read the value to see if it is in there... thanks!

set regkey=SYSTEM\CurrentControlSet\Services\atapi\Parameters

reg query HKLM\%regkey% /v EnableBigLba

Just copy the above two lines and paste it at the command prompt and it will dump the contents to the screen or you

could just use regedit and go to the above path to verify it.

Edited December 3, 2007 by mikesw

[heffalump]

That worked! It is in there already for me. Thanks