New mother board

I have installed a new mother board (system board) and CPU now vista does
not start. Even safe mode does not work.
Old board was flakey and I put a new one New one is a DFI the old one Systec
board
Do I have to reinstall.

Do you have the Bios set to boot on the harddrive?
"Tony" <ballatileandrenovation@bellnet.ca> wrote in message
news:F3DE77B3-C47C-4CB0-AC96-482E70763195@microsoft.com...
>I have installed a new mother board (system board) and CPU now vista does
>not start. Even safe mode does not work.
> Old board was flakey and I put a new one New one is a DFI the old one
> Systec board
> Do I have to reinstall.
>

"Tony" <ballatileandrenovation@bellnet.ca> wrote ...
>I have installed a new mother board (system board) and CPU now vista does
>not start. Even safe mode does not work.
> Old board was flakey and I put a new one New one is a DFI the old one
> Systec board. Do I have to reinstall.

Hi Tony,

Reinstalling Vista from scratch is certainly the most reliable approach.

When you replace the motherboard, you are effectively replacing the whole
computer (especially these days, when so many system components are
integrated onto the motherboard). Even though various hardware interfaces
are supposedly standard - maybe you have a SATA hard disk, for example, and
SATA is SATA, right? - but the hard disk controller, although a standard
SATA device, will probably have a different PnP Identifier from the
controller on the old motherboard. If the PnP identifiers don't match,
you'll get a STOP 0x7B blue screen when you try to boot. And so on. All the
very careful and precise hardware detection which Vista does when you first
install it, you will be effectively throwing away, if you don't re-install.


Basically, the motherboard and CPU are not *fungible* components - unlike
the keyboard, case, power supply etc.

Some folks might respond and suggest ways to hack your existing Vista
installation back into life. This is sometimes possible. But it is likely to
be a less reliable solution in the long run - you'll end up with a bunch of
left-over dead-end device drivers hanging around, registry crud, occasional
mysterious blue screens, etc, etc. If you really, *really* need to resurrect
your existing installation, boot from the Vista DVD, and then do an in-place
"upgrade" of your existing installation. This will preserve your user data
and existing applications. It will repeat the hardware detection and append
the necessary drivers, PnP definitions etc to make the system bootable.

Alternatively and preferably: boot from the Vista DVD, go to a Command
Prompt in the repair console, and back-up your user data to a safe location.
Then reformat the system drive, and re-install Vista from scratch.

There's a certain element of opinion and risk assessment here; some might
disagree with me. But I'm pretty sure this is the best advice for you. It's
what I always do myself, when I replace a motherboard.

Hope it helps,
--
Andrew McLaren
amclar (at) optusnet dot com dot au

"Andrew McLaren" <andrew@fakeaddress.com> wrote in message
news:%23ohamx93HHA.948@TK2MSFTNGP06.phx.gbl...
> "Tony" <ballatileandrenovation@bellnet.ca> wrote ...
>>I have installed a new mother board (system board) and CPU now vista does
>>not start. Even safe mode does not work.
>> Old board was flakey and I put a new one New one is a DFI the old one
>> Systec board. Do I have to reinstall.
>
> Hi Tony,
>
> Reinstalling Vista from scratch is certainly the most reliable approach.
>
> When you replace the motherboard, you are effectively replacing the whole
> computer (especially these days, when so many system components are
> integrated onto the motherboard). Even though various hardware interfaces
> are supposedly standard - maybe you have a SATA hard disk, for example,
> and SATA is SATA, right? - but the hard disk controller, although a
> standard SATA device, will probably have a different PnP Identifier from
> the controller on the old motherboard. If the PnP identifiers don't match,
> you'll get a STOP 0x7B blue screen when you try to boot. And so on. All
> the very careful and precise hardware detection which Vista does when you
> first install it, you will be effectively throwing away, if you don't
> re-install.
>
>
> Basically, the motherboard and CPU are not *fungible* components - unlike
> the keyboard, case, power supply etc.
>
> Some folks might respond and suggest ways to hack your existing Vista
> installation back into life. This is sometimes possible. But it is likely
> to be a less reliable solution in the long run - you'll end up with a
> bunch of left-over dead-end device drivers hanging around, registry crud,
> occasional mysterious blue screens, etc, etc. If you really, *really* need
> to resurrect your existing installation, boot from the Vista DVD, and then
> do an in-place "upgrade" of your existing installation. This will preserve
> your user data and existing applications. It will repeat the hardware
> detection and append the necessary drivers, PnP definitions etc to make
> the system bootable.
>
> Alternatively and preferably: boot from the Vista DVD, go to a Command
> Prompt in the repair console, and back-up your user data to a safe
> location. Then reformat the system drive, and re-install Vista from
> scratch.
>
> There's a certain element of opinion and risk assessment here; some might
> disagree with me. But I'm pretty sure this is the best advice for you.
> It's what I always do myself, when I replace a motherboard.

Hi Andrew

What is needed is a different Hardware Abstraction Layer. If the
replacement motherboard did not use a different chipset, this would most
probably not be necessary.

I have transferred OS installations from one computer to another with
totally different hardware using Acronis TrueImage with Universal Restore.
It resets the HAL in the process. I have also used it to turn OS
installations into VirtualPC virtual machines.

I would think that just changing the HAL would work fine. This can also be
done using a repair installation in XP (not sure about Vista's Recovery
Environment) and there is also a way of manually resetting the HAL that you
can Google for.

ss.

"Synapse Syndrome" <synapse@NOSPAMgomez404.elitemail.org> wrote...
> What is needed is a different Hardware Abstraction Layer. If the
> replacement motherboard did not use a different chipset, this would most
> probably not be necessary.

Hi Synapse,

I admire and respect the excellent, high-quality answers you provide in this
newsgroup. So, I really hate to disagree with you. But, um ... I disagree
:-)

Well actually, I both agree and disagree. Yes, replacing the HAL may be
necessary; but it may not be sufficient for transferring a Windows
installation to another motherboard.

The role of the Hardware Abstraction Layer is often exaggerated in popular
thinking about Windows. It is often claimed that the HAL provides a
generalised abstraction of the hardware; almost to the point of providing a
"virtual machine" for Windows to run on (they may not use that "v" word, but
that's what is implied). In fact the HAL has a much narrower focus - it
places a layer of code between the NT Executive and the hardware to handle
processor-dependent routines (eg, masking big-endian and little-endian
architectures). It does not replace device drivers, for example, which
contain the device-specific code to drive the hardware; but with the HAL in
place, hardware vendors can write device drivers to handle their hardware in
a fairly processor-independent way, without needing to supply different
versions of the driver for every possible processor (obviously, different
object code is still required for different instruction sets). Device
drivers don't interface direct to the hardware, but instead call kernel
routines in the HAL. But you still need to install and configure the right
device drivers, to match the specific hardware on which you are running.

This role of the HAL was more important in the past, when 2 circumstances
needed to be dealt with:

1) Windows ran on many different architectures besides x86: NT 3.5 and 3.51
ran on RISC processors like MIPS R4000, DEC Alpha and Motorola/IBM PowerPC,
as well as the traditional Intel IA-32. The RISC chips were all big-endian.
Today, there are only 2 processor families: IA-32 and IA-64 Itanium.

2) standard PC hardware had not converged as much as it has today; so each
PC vendor supplied a custom HAL specific to their hardware. For example,
Compaq SystemPro servers needed a specific HAL to use their Triflex buss
design; Toshiba PCs needed aspecific HAL or they wouldn't boot, and so on.
These days, there are only a few variations in possible HAL:
- APCI or not?
- uniprocessor or multiprocessor?

(And even the uniprocessor factor is going away, as dual core machines
become standard. There are also Itanium machines, but I'll skip over them
.... not many Itanium users in this forum, anyway :-).

The list of HALs in a Vista distribution is far shorter than it was in NT
3.51! We are down to about 6 major HALs, I think (haven't checked the exact
number).

Additionaly, the hardware waters were muddied again in NT 4.0 and Windows
2000, with the introduction of Plug-n-Play. The kernel-mode Plug-and-Play
Manager runs in the NT Executive, above the HAL layer. Like all components,
it relies on the HAL to provide processor-independent interfaces to low
level hardware events, like interrupts etc; but the mapping of compatible
PnP Device IDs happens "way up here" in the PnP Manager, not "way down
there" in the HAL.

So for example you could have 2 machines, each with a SATA Hard disk. On
Machine "A", the device ID of the SATA Contoller is:
PCI\VEN_8086&DEV_2824&SUBSYS_514D8086&REV_02
On machine "B", the device ID of the SATA Controller is:
PCI\VEN_10DE&DEV_0054&SUBSYS_B0031458&REV_F3

If you move the Windows installation from machine A to machine B, you are
relying on *something* in Windows to be smart enough, during the boot
process, to work out at a very low level, whether or not the device called
PCI\VEN_8086&DEV_2824&SUBSYS_514D8086&REV_02 can be treated the same way as
the device called PCI\VEN_10DE&DEV_0054&SUBSYS_B0031458&REV_F3.

This is *not guaranteed* to FAIL for every move to a new machine ... hey,
Windows is pretty smart! :-) ... but, it *is guaranteed* to fail for SOME
cases. That's when you see errors like the STOP 0x7B, described in KB
article 314082 (http://support.microsoft.com/kb/314082). Changing the HAL
won't fix that problem, you need a whole new IDE driver (or whatever). So as
I described, it's not a case of "This will never work"; it's a case of
"Sometimes this will work, and sometimes this will fail". Once we accept
that, then we are in the world of risk management - what frequency of
failures can we expect, relative to non-failures? And what level of
frequency is acceptable to us, given other extraneous (non-technical)
factors like, how much time are we willing to repair the cases that don't
work, etc.

If the board uses exactly the same chipset, then: Yes, the chances of
getting a successful move are fairly good (eg P965 to P965). If the new
board uses a similar chipset in the same family, the chances are good but
not as high (eg move from P915 to P965). If the chipset is from a different
vendor (eg NForce 4 to P965) the chances of a successful move are starting
to get pretty low.

Most of Windows' hardware detection happens at a level which requires no
user interaction; so many users - even quite technical users working up in
user-mode applications - are fairly oblivious to it. This is a good thing,
and how it should be. But once you start writing device drivers, or doing
any kind of hardware debugging down in kernel mode, you realise there is a
ton of stuff that appears to happen "by magic", but in fact is very complex,
detailed, fiddly and sometimes fragile work.

The common home user is not in a very good position to make these kinds of
assessments. So - IMHO - their best bet is to stick to reliable and proven
safe techniques. Back up their data, and make a clean installation of
Windows from scratch. This is what I always do, myself.

But there's no clear right-or-wrong answer. So ... we can disagree, and
we'll still both be correct! :-) (or, um, both wrong :-))

Best regards,
--
Andrew McLaren
amclar (at) optusnet dot com dot au

"Andrew McLaren" <andrew@fakeaddress.com> wrote in message
news:ed9rFUG4HHA.4900@TK2MSFTNGP04.phx.gbl...
> "Synapse Syndrome" <synapse@NOSPAMgomez404.elitemail.org> wrote...
>> What is needed is a different Hardware Abstraction Layer. If the
>> replacement motherboard did not use a different chipset, this would most
>> probably not be necessary.
>
> Hi Synapse,
>
> I admire and respect the excellent, high-quality answers you provide in
> this newsgroup. So, I really hate to disagree with you. But, um ... I
> disagree :-)
>
> Well actually, I both agree and disagree. Yes, replacing the HAL may be
> necessary; but it may not be sufficient for transferring a Windows
> installation to another motherboard.
>
> The role of the Hardware Abstraction Layer is often exaggerated in popular
> thinking about Windows. It is often claimed that the HAL provides a
> generalised abstraction of the hardware; almost to the point of providing
> a "virtual machine" for Windows to run on (they may not use that "v" word,
> but that's what is implied). In fact the HAL has a much narrower focus -
> it places a layer of code between the NT Executive and the hardware to
> handle processor-dependent routines (eg, masking big-endian and
> little-endian architectures). It does not replace device drivers, for
> example, which contain the device-specific code to drive the hardware; but
> with the HAL in place, hardware vendors can write device drivers to handle
> their hardware in a fairly processor-independent way, without needing to
> supply different versions of the driver for every possible processor
> (obviously, different object code is still required for different
> instruction sets). Device drivers don't interface direct to the hardware,
> but instead call kernel routines in the HAL. But you still need to install
> and configure the right device drivers, to match the specific hardware on
> which you are running.
>
> This role of the HAL was more important in the past, when 2 circumstances
> needed to be dealt with:
>
> 1) Windows ran on many different architectures besides x86: NT 3.5 and
> 3.51 ran on RISC processors like MIPS R4000, DEC Alpha and Motorola/IBM
> PowerPC, as well as the traditional Intel IA-32. The RISC chips were all
> big-endian. Today, there are only 2 processor families: IA-32 and IA-64
> Itanium.
>
> 2) standard PC hardware had not converged as much as it has today; so each
> PC vendor supplied a custom HAL specific to their hardware. For example,
> Compaq SystemPro servers needed a specific HAL to use their Triflex buss
> design; Toshiba PCs needed aspecific HAL or they wouldn't boot, and so on.
> These days, there are only a few variations in possible HAL:
> - APCI or not?
> - uniprocessor or multiprocessor?
>
> (And even the uniprocessor factor is going away, as dual core machines
> become standard. There are also Itanium machines, but I'll skip over them
> ... not many Itanium users in this forum, anyway :-).
>
> The list of HALs in a Vista distribution is far shorter than it was in NT
> 3.51! We are down to about 6 major HALs, I think (haven't checked the
> exact number).
>
> Additionaly, the hardware waters were muddied again in NT 4.0 and Windows
> 2000, with the introduction of Plug-n-Play. The kernel-mode Plug-and-Play
> Manager runs in the NT Executive, above the HAL layer. Like all
> components, it relies on the HAL to provide processor-independent
> interfaces to low level hardware events, like interrupts etc; but the
> mapping of compatible PnP Device IDs happens "way up here" in the PnP
> Manager, not "way down there" in the HAL.
>
> So for example you could have 2 machines, each with a SATA Hard disk. On
> Machine "A", the device ID of the SATA Contoller is:
> PCI\VEN_8086&DEV_2824&SUBSYS_514D8086&REV_02
> On machine "B", the device ID of the SATA Controller is:
> PCI\VEN_10DE&DEV_0054&SUBSYS_B0031458&REV_F3
>
> If you move the Windows installation from machine A to machine B, you are
> relying on *something* in Windows to be smart enough, during the boot
> process, to work out at a very low level, whether or not the device called
> PCI\VEN_8086&DEV_2824&SUBSYS_514D8086&REV_02 can be treated the same way
> as the device called PCI\VEN_10DE&DEV_0054&SUBSYS_B0031458&REV_F3.
>
> This is *not guaranteed* to FAIL for every move to a new machine ... hey,
> Windows is pretty smart! :-) ... but, it *is guaranteed* to fail for SOME
> cases. That's when you see errors like the STOP 0x7B, described in KB
> article 314082 (http://support.microsoft.com/kb/314082). Changing the HAL
> won't fix that problem, you need a whole new IDE driver (or whatever). So
> as I described, it's not a case of "This will never work"; it's a case of
> "Sometimes this will work, and sometimes this will fail". Once we accept
> that, then we are in the world of risk management - what frequency of
> failures can we expect, relative to non-failures? And what level of
> frequency is acceptable to us, given other extraneous (non-technical)
> factors like, how much time are we willing to repair the cases that don't
> work, etc.
>
> If the board uses exactly the same chipset, then: Yes, the chances of
> getting a successful move are fairly good (eg P965 to P965). If the new
> board uses a similar chipset in the same family, the chances are good but
> not as high (eg move from P915 to P965). If the chipset is from a
> different vendor (eg NForce 4 to P965) the chances of a successful move
> are starting to get pretty low.
>
> Most of Windows' hardware detection happens at a level which requires no
> user interaction; so many users - even quite technical users working up in
> user-mode applications - are fairly oblivious to it. This is a good thing,
> and how it should be. But once you start writing device drivers, or doing
> any kind of hardware debugging down in kernel mode, you realise there is a
> ton of stuff that appears to happen "by magic", but in fact is very
> complex, detailed, fiddly and sometimes fragile work.
>
> The common home user is not in a very good position to make these kinds of
> assessments. So - IMHO - their best bet is to stick to reliable and proven
> safe techniques. Back up their data, and make a clean installation of
> Windows from scratch. This is what I always do, myself.
>
> But there's no clear right-or-wrong answer. So ... we can disagree, and
> we'll still both be correct! :-) (or, um, both wrong :-))

Hi Andrew

You obviously know more about computers than I do (I am not even a computer
professional), and I have taken your points onboard. But I personally have
hardly ever had any trouble with moving OS installations from one computer
to another, or to a virtual machine. I only do this for convenience, and it
is preferable to feel that everything is perfect, with no old drivers
knocking around. I once had a XP OS installation that had seen total
hardware changes twice and was running perfectly for over three years.

Cheers

ss.