Re: Changing Hardware Platform

From: Jeff Middleton [SBS-MVP] (jeff_at_cfisolutions.com)
Date: 05/18/04 

Date: Tue, 18 May 2004 10:29:33 -0500

Root, your reply comments aren't really helpful, just argumentative. The outcome of what I explained is accurate, as is the explanation of the issue involved, even if I made an abbreviated set of statements the first time. Now I'll offer more detailed information.

Since you didn't elaborate on your point, I'll try to interpret it for others just for the sake of discussion. You seem to be trying to insert a point that among the various phases of system POST through startup until user logon, there are many separately managed phases of PnP invoked, some of which occurs at the BIOS level. Each PnP process is related to a common standard of origin, but executed under different control management and for different aspects of the total process. There is a phase of PnP that initializes and enumerates hardware devices which is managed by the BIOS. However, that BIOS level PnP isn't the control manager responsible for the PnP based implementation of adding the OS driver and startup support that enables a Kernel mode boot from the boot device. The system boot transitions into Kernel mode and then invokes another PnP enumeration managed by the to determine is new devices can/should now be installed to the OS itself. These detected devices will become available in the current logon session, but that PnP process actually follows the point at which the switch to Kernel mode was invoked, and therefore that transition requires the boot device kernel driver is already be present and configured among the boot device startup parameters supported by Kernel mode prior to the PnP driver installation scan. That's the reason for the 7b Stop.

The relevant point to my previous post is that the sequence of startup of Windows will fail at the point at which the primary boot device is called to transition to kernel mode if in fact there isn't a compatible kernel mode driver established in the Windows configuration. The sequence of POST and PnP support which is invoked by normal startup of Windows 2000 and higher versions currently doesn't provide the means to bootstrap the installation of a kernel mode boot device driver at boot time, not even if you repeatedly restart. That's because the PnP services that provide the ability to install detect, configure and install device drivers in Windows OS are not invoked until after the boot driver is required to have been initialized as an existing boot device driver configured in the OS. That illustrates why you can install a boot device driver if you install a PnP compatible controller capable of being a boot device, but doing it while booting from a pre-existing boot device for that session. The only transparent option is to have it preinstalled prior to the boot attempt. Otherwise, you have to move to non-transparent steps like rerunning Windows Setup, or manually perform the installation steps in some manner.

Some folks will find these two Kbs informative on troubleshooting related startup issues:

How to troubleshoot "Stop 0x0000007B" error messages in Windows 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;822052&Product=win2000#6g

HOW TO: Troubleshoot Startup Problems in Windows 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;315396&Product=win2000

For anyone interested in the technical background I summarized above for the bootstrap process for Windows XP (which is similar for versions W2k - 2003), this is usefult to review:

http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/prmc_str_njcq.asp

I'm pasting in the entire relevant page (about 10 lines further below) where you will want to notice the first column, which I've summarize as bullets immediately below:

      Startup Stage
        a.. Power-on self test (POST)
     
        a.. Initial startup (before the-operating system loads)
     
        a.. Ntldr starts
     
        a.. Hardware detection occurs
     
        a.. Kernel loads
     
        a.. Drivers load and the user logs on
     
        a.. Plug and Play detects and configures new
     

Summary of the Startup Process
Table 28.8 lists the startup phases and provides a descriptive summary of each one.

Table 28.8 Summary of the Startup Process

      Startup Stage x86-based Systems Itanium-based Systems
      Power-on self test (POST) CPU initiates motherboard POST routines.
      Individual adapter POST routines start after the motherboard POST is complete.
     CPU initiates motherboard POST routines.
      Individual adapter POST routines start after the motherboard POST is complete.
     
      Initial startup (before the-operating system loads) The system searches for a boot device according to the boot order setting stored in CMOS. If the boot device is a hard disk, Ntldr starts. The EFI starts and the boot manager searches for a boot device according to the boot order settings stored in NVRAM.
      Ntldr starts Ntldr switches the CPU to protected mode, starts the file system, and then reads the contents of the Boot.ini file. This information determines the startup options and initial boot menu selections. Global system variables and settings are read from NVRAM and boot manager information is used to determine the startup options.
      Hardware detection occurs Ntdetect.com gathers basic hardware configuration data and passes this information to Ntldr. If more than one hardware profile exists, Windows XP Professional attempts to use the one that is correct for the current configuration.
      If the firmware complies with ACPI specifications, Windows XP Professional uses ACPI functionality to enumerate and initialize devices.
     The boot manager searches for and starts IA64ldr.efi.
      The operating system starts devices by using ACPI functionality.
     
      Kernel loads Ntldr passes the information collected by Ntdetect.com to Ntoskrnl.exe. Ntoskrnl then loads the kernel, HAL, and registry information. A progress indicator appears near the bottom of the screen. IA64ldr.efi loads the kernel, the HAL, and registry information. A progress indicator appears near the bottom of the screen.
      Drivers load and the user logs on Networking-related components, such as TCP/IP, load asynchronously with other services and the Begin Logon prompt appears on screen. After a user logs on successfully, Windows XP Professional updates the Last Known Good Configuration information to reflect the current state.
      Plug and Play detects and configures new devices If Windows XP Professional detects new devices, they are assigned system resources. Windows XP Professional extracts the needed driver files from the Driver.cab file or if the driver files are not found, prompts the user to provide them. Device detection occurs asynchronously with the operating system logon process.

Table 28.9 lists the files that are processed by x86-based and Itanium-based systems during the startup process. This information is useful if your organization uses Windows XP Professional on x86-based and Itanium-based computers. For example, when diagnosing a problem on an Itanium-based system, you can immediately eliminate Boot.ini and Ntdetect.com from your list of potential causes.

Table 28.9 Files Processed During Startup

      File Name x86-based
      Systems
     Itanium-based
      Systems
     
      Boot.ini
      Bootsect.dos (multiple-boot systems only)
      FPSWA.efi
      Hal.dll
      IA64ldr.efi
      Ntbootdd.sys
      Ntdetect.com
      Ntldr
      Ntoskrnl.exe
      Files in the systemroot\System32\Config folder
      Files in thesystemroot\System32\Drivers folder

"root" <postmaster@buchanangc.com> wrote in message news:eOjvnYIPEHA.1612@TK2MSFTNGP11.phx.gbl...
>
> "Jeff Middleton [SBS-MVP]" <jeff@cfisolutions.com> wrote in message
> news:e4lcZTIPEHA.540@TK2MSFTNGP11.phx.gbl...
> > > > only about 3 common HALs in the Windows OS library....there are
> > literally
> > > > dozens of EIDE controllers...perhaps even a dozen-dozen. Your chances
> of
> > > the
> > > > move failing because of a 7b Stop error is really high.
> > >
> > > Has that changed significantly from XP to SBS2003? There was much FUD
> > > around about similar things in XP and that turns out to be not so. If
> the
> > > HALs are the same then the OS figures out what's needed IDE wise and
> does
> > > the change transparently in most cases in XP. If one carefully looks at
> > the
> > > driver structure then one finds that there are just a few IDE drivers.
> > The
> > > number of possible IDE controllers isn't relevant since that gets
> detected
> > > on the fly.
> > >
> >
> > This hasn't changed at all. In fact, I'd say it's getting worse for an odd
> > reason. Used to be in the late 1990s and early 2000 time frame, most
> > motherboards were still going to be compliant to a baseline IDE driver
> that
> > was generic. This is what we remember from the grand days of Win9x.
> >
> > With release of Windows 2000, the floodgates openned and the number of
> > permutations of EIDE drivers exploded. Now you have multiples of chipsets
> > and EIDE controllers combined.
> >
> > The main point though that you are asking about is a common misconception.
> >
> > You can't expect PnP to solve your boot controller issue.
>
> Nope but the mobo BIOS does that.
>
> >Windows doesn't
> > use PnP to detect the primary boot controller. That device has to
> pre-exist
> > in the registry, the driver has to pre-exist in the 32-bit drivers cache,
> > the driver itself needs to be set to start at boot....not automatic...and
> > that means that the driver is effectively preinstalled, not detected.
>
> Correct but the IDE controller support is 'detected' since the catchall
> generic ATA driver that is used stays the same.
>
> > It's
> > only after the boot controller has been located that the PnP kicks in, so
> as
> > that case would lead us to, you can't make Windows boot from a controller
> it
> > hasn't previously been through a boot cycle without either manually
> updating
> > the registry and the driver cache, or else by running Windows Setup again
> to
> > let it do the job for you.
>
> That's false.
>
> >Windows Setup requires the typical 45 minutes to
> > install, same as a scratch install, only difference is that you preserve
> the
> > balance of the system configuration.
> >
> > The method I outlined works 19 out of 20 times. The times that it doesn't
> > work are going to be due to pretty odd conditions, for instance, a boot
> > controller that requires boot.ini entries that are SCSI(x), rather than
> > multi(x)...which implies that the NTBOOTDD.SYS is a custom file, etc. That
> > can be overcome by a custom boot floppy, but on the whole the method I
> > described makes that somewhat less of a risk to do.
> >
> > To put a finer point on it, at the end of 2001, I had been working on a
> > project in which it was my desire to produce a single drive image with
> > Windows 2000 Pro on it that would actually boot every Intel (brand)
> > motherboard I had sold in the past 4 yrs. I got the image requirements
> done
> > to two images. One for non-ACPI HAL, one for ACPI HAL. About that time
> that
> > XP shipped in 2002 (9 mos later), I was back up to 3 images for XP for
> > various reasons, mainly that I couldn't get drivers preinstalled for each
> > HAL and device driver without actually moving an reinstalling drivers from
> > scratch by rerunning setup. There was about a 1yr delay from Intel
> releasing
> > the utility that preloaded the Intel EIDE drivers and chipset drivers.
> >
> > I can now do it with 2 XP images (last time I looked at it), but it's a
> > moving target now because the patching update requirements have lead me to
> > no longer care as much about maintaining a single image as much as
> > preserving the ability to install without prompts....which XP does better
> > than W2K did.
> >
> > As for Server 2003, I really haven't even started into replacing my
> servers
> > that aren't SBS yet....MS has managed to total hose the licensing
> incentives
> > for upgrading servers from W2K to W2K3. Therefore, I'm not really imaging
> > Server 2003 at the moment much. That said, I do have a couple of sites
> that
> > I can push a single drive image to any one of a dozen different servers
> that
> > are a range of PIII, Dual PIII, Dual Xeon motherboards. On that basis, I'm
> > less concerned with having an image from the previous night, as much as I
> > want any image at all that allows me to boot the machine again, rename it,
> > then restore from tape of the last night. Recovery time is about 30-45
> > minutes in a lab setting, closer to 90 minutes in production situation. I
> > actually used the same tools as a technique to add a 4th TS apps server to
> a
> > site in under 2hrs from a bare metal configuration. That included the time
> > to go from PXE boot, push the image, rename the server, join the domain
> > manually, then manually install Office and a couple of applications not in
> > the image, then reconfirm group policy configurations that are server
> > specific in path naming. It was a case of an emergency deployment that
> > worked pretty well.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > "root" <postmaster@buchanangc.com> wrote in message
> > news:emq2qCHPEHA.3708@TK2MSFTNGP10.phx.gbl...
> > >
> > > "Jeff Middleton [SBS-MVP]" <jeff@cfisolutions.com> wrote in message
> > > news:ewEAoZGPEHA.736@tk2msftngp13.phx.gbl...
> > > > In addition to Root's comments....
> > > >
> > > > An EIDE drive is a bad choice for lifting a complete installation
> > between
> > > > different server hardware. That's because if you plan to use the
> onboard
> > > > EIDE at the target server, you will find out eventually that while
> there
> > > are
> > > > only about 3 common HALs in the Windows OS library....there are
> > literally
> > > > dozens of EIDE controllers...perhaps even a dozen-dozen. Your chances
> of
> > > the
> > > > move failing because of a 7b Stop error is really high.
> > >
> > > Has that changed significantly from XP to SBS2003? There was much FUD
> > > around about similar things in XP and that turns out to be not so. If
> the
> > > HALs are the same then the OS figures out what's needed IDE wise and
> does
> > > the change transparently in most cases in XP. If one carefully looks at
> > the
> > > driver structure then one finds that there are just a few IDE drivers.
> > The
> > > number of possible IDE controllers isn't relevant since that gets
> detected
> > > on the fly.
> > >
> > > > You could be better
> > > > off either using a PCI EIDE card or a PCI SCSI card and drive. If you
> > have
> > > > compatible SCSI controller planned for the other server (or SCSI on
> both
> > > > motherboards that you plan to use), you may well find that the drive
> > > mounts
> > > > without a problem, but I would be very careful about assuming that a
> > RAID
> > > > can be lifted that way unless the controller, drives and Hotswap
> Chassis
> > > > move as an entire set, including the internal cable.
> > > >
> > > > As was suggested, make an image of your system drive to do the test
> > with.
> > > >
> > > > If you are a dealer and want to do this on a regular basis, do
> yourself
> > a
> > > > favor and pick PCI based combination of controller and drive that you
> > can
> > > > use. Preinstall the controller in the source system with your "Travel"
> > > drive
> > > > connected to it. Do a full boot cycle and install the drivers for the
> > > card.
> > > > Shutdown, image the drives (or do a mirror mate and split if you have
> > that
> > > > kind of time an no imaging software). Shutdown and take the production
> > > > drives offline.
> > > >
> > > >
> > > > Disconnect the NIC cables. (you don't want any authentications, email
> or
> > > > other traffic flowing while you do this test.) Attempt to boot the
> > source
> > > > machine from the Travel drive. If it succeeds, you are ready to try it
> > on
> > > > the target server.
> > > >
> > > > Disconnect the NIC cables on the target server, same reason as before.
> > > > Install the PCI card and the travel drive to the target server. If you
> > can
> > > > boot this target machine with the Travel drive, you now know that the
> > > system
> > > > installation is going to work without modifications. If the boot
> fails,
> > > > depending upon the error message, you are either going to need to
> change
> > > the
> > > > HAL indicated on -this- drive's system installation by moving it back
> to
> > > the
> > > > source server and doing a HAL change before a shutdown.....or possibly
> > you
> > > > have an issue with the boot order of the boot devices on the target
> > > machine.
> > > > There are other explanations, but these are the most likely.
> > > >
> > > >
> > > >
> > > >
> > > > "root" <postmaster@buchanangc.com> wrote in message
> > > > news:uwngaOJOEHA.4036@TK2MSFTNGP12.phx.gbl...
> > > > >
> > > > > "Craig Schaefer" <anonymous@discussions.microsoft.com> wrote in
> > message
> > > > > news:c04001c43826$7ed92810$a301280a@phx.gbl...
> > > > > >
> > > > > > In the past on this Newsgroup I have seen links to site
> > > > > > where there is a procedure for moving an SBS Server
> > > > > > installation to new hardware that has a different HAL. I
> > > > > > want to physically move an IDE drive to a different
> > > > > > computer.
> > > > >
> > > > > A different HAL and moving an IDE drive aren't the same thing.
> What's
> > > the
> > > > > mobo and CPU on both systems? It might just outright work. If you
> > can
> > > > > image the drive for safe keeping then just try it.
> > > > >
> > > > > > Is someone able to point me in that direction ?
> > > > > >
> > > > > > Thank You
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Relevant Pages

  • Re: Changing Hardware Platform
    ... >> HALs are the same then the OS figures out what's needed IDE wise and ... >> driver structure then one finds that there are just a few IDE drivers. ... > You can't expect PnP to solve your boot controller issue. ...
    (microsoft.public.windows.server.sbs)
  • Re: XP install problem
    ... You can enable boot logging from the advanced ... Since this is a new install you can also check the setuperr.log file in the ... whats causing your startup problem. ... each driver as it is loaded during startup. ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: Easier way to install on 3ware 9550 card?
    ... I have a new system with NO FLOPPY CONTROLLER and a 3ware 9550 card. ... I don't think you need a driver - it's already there. ... then why didn't I just install the OS? ... The card doesn't probe at boot, and there's an elaborate howto on 3ware's ...
    (freebsd-questions)
  • Re: Event ID 51
    ... I don't have computer with nForce controller in front of me, ... choose the driver to install'. ... open computer / move your HD to different SATA port (if HD was ... Boot / go to BIOS / change boot from if required ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: IRP_MJ_SCSI
    ... root enumerate drivers are started too late in the boot process to be ... used as the boot disk stack. ... driver would be a good idea. ... I also need to support attaching CD/DVD devices to my controller ...
    (microsoft.public.development.device.drivers)