[geeks] The Registry (?)

[Alois Hammer]

On Sat, 30 Aug 2008 20:24:36 -0700, "Jon Gilbert" <jjj at io.com> said:
> Well, I guess I am lucky it booted. But it did. As far as wipe &  
> reinstall, that's not really an option, since I don't have any of the

I didn't think it was.  I'm just sayin'.

> tab disabled, cannot control-alt-delete, etc.). So ideally, I would  
> very much like to know if it is possible to get this to work *without*  
> having to "wipe the machine and reinstall."

Maybe.  I don't know much of anything about the machines.

> I did DirectX update but that didn't help. I'm wondering now if  
> updating .NET would be more the thing to do, since the error message  
> is directly related to a .NET class. In fact I think that the kiosk  
> incorporated some open-source volume-setting code which can be found  
> here:
> http://bytes.com/forum/thread246970.html
> MIXERLINE_COMPONENTTYPE_DST_SPEAKERS,type,out seems to be being sent  
> to .NET but for some reason it's not working.

Possibly, but you could also break things.  I know next to nothing about
.NET, other than it's at least as bad as trying to support Java apps. 
Since I don't have any details about the code, I don't even know whether
to advise you to grab .NET 1.1 hotfixes from thehotfixshare.net and
apply them, or if you're using .NET 2.0 instead, or maybe-possibly even
one of the 2.0 extension sets (3.0 and 3.5).  In any case, you're
probably dealing with legacy troubles from the old motherboard, and not
.NET.

> I'm curious as to why Windows cares if you swap motherboards out from  
> under it... As long as you give it the drivers for the new  
> motherboard, why wouldn't it be happy? And if it's not, how do you fix  
> that?

Lots of reasons.  Here's a really good one: you can't switch a Windows
installation from ACPI-aware to non-ACPI-aware or vice versa.  In
theory, it shouldn't be too much harder than copying over the proper HAL
DLLs, but in practice, I've tried it and seen other people try it, and
you generally end up with a hopelessly corrupted Windows install.  In
your case, your old motherboards are *probably* just new enough to have
working, ACPI-compliant BIOSes, but not necessarily.  Of course, if
Windows was installed as non-ACPI-aware, and you upgrade your BIOS (on
an old motherboard, like yours) and it makes it speak ACPI properly,
Windows will never be able to take advantage of it.

Here's another good reason: Windows generally can't abide switches from
one vendor's chipset to another.  If you start with (for example) a
board with an Intel i815 chipset and move to a board with an i945, you
may be okay, because Windows is loading the generic Intel IDE and other
drivers really early at boot time.  But if you switch from a VIA board
to Intel, Windows will attempt to load the VIA drivers, fail, probably
find no other drivers (depending on how your install was built), and
die.  Also, with some vendors, like NVIDIA, chances are that if you
upgrade from, say, an original nForce chipset to a board with an
nForce4, those old nForce drivers (they stopped updating them a long
time ago) will utterly fail to drive the nForce4 chipset, and you may
not even get as far as a BSOD.  I've seen black screens of death where
Windows has failed so thoroughly that it can't even paint the screen
blue and tell you about it.

Basically, we're talking about some very core drivers that Windows loads
immediately after NTLDR stops and NTOSKRNL starts.  If you have a bunch
of boot-time (or F6-time, for installation purposes) drivers for
multiple vendors built into the boot routine *and* the drivers
(processor, northbridge, GART, IDE controller, whatever) that Windows
fails to load don't cause the kernel to commit suicide when they fail,
but allow Windows to keep trying drivers, you just may come out alive. 
Windows does not expect the early-load hardware or drivers to ever
change, so there's no hardware detection built in to this process like
there is in Linux.  (I'm guessing you've been using Linux or OSX or
something else, and you'd like to know why Windows can't do it just as
well.)  If the hardware ever changes, Windows isn't even going to start
*looking* for those changes until sometime after your graphics driver
kicks in and you get the Blue (teal?) Screen of Startup.  *First* the
core services manager loads.  *Before* that, it has to load credentials
services so that the services have some to run under.  Before *that*,
you need drivers and a kernel loaded.  *After* all that, the PnP
hardware detection service can start.  So, sure, you can change your
network card.  Your sound card.  Add another disk controller.  Change
drives (just don't go from ATA to SATA, or SATA to SCSI, or anything
else with a completely different interface).  If it's absolutely core to
your computer, Windows loads it very, very early and has next to no
flexibility for change.

(Note that I have just a sliver of Vista experience, but so far as I can
see, nothing's really changed in this process.  And XP SP3 killed a lot
of OEM (and corporate) Windows installs because they had the Intel power
management driver built in, but were actually using AMD CPUs.  Something
in the upgrade to SP3 caused the failed intelppm.sys load to kill the
boot process instead of just allowing a graceful failure.  This is just
an example of how buggered Windows can be during IPL.)

> And when you say registry cleaning should require thought and  
> intervention, that scares me, since I don't know anything about  
> registries. Or else I could probably fix it *without* a cleaner app,  
> right? I mean what good is the cleaner app if you already know enough?  
> Sorry for the noob questions but that's where I'm at. Thanks.

Well, with RegSeeker, the intervention is automatic.  It'll grep your
Registry, throw a lot of what it thinks are stale keys, subkeys, and
values at you, and ask you to make the decision about whether to remove
them.  The fully- or nearly-automatic Registry cleaners have a habit of
a) not cleaning much of anything at all or b) buggering your system and
c) sometimes both.  See: Norton Utilities.

Bear in mind that the typical Windows system, with just a few apps
installed, has a Registry sizing anywhere from 20-40MB as a very rough
guesstimate.  It's 100% binary yuck (not counting stored strings). 
That's a *huge* number of little toggle switches, some of them
multi-position.  Then you start adding user hives, and you can be
talking about 500MB of Registry easy on a Terminal Services box with
just ten to twenty users logged in.  And is it all documented?  Yeah. 
Sort of.  Mostly.  In ten thousand different places.  A lot of the
documentation is out of date or purposely obfuscated, too.

When I clean cruft out of Windows Registries, I'm making guesses, guided
by experience, and covered with backups.


If you're terrified of smashing the Registry (and rightly so), my best
advice is: download Sysinternals' Autoruns.  It's now owned by Microsoft
(but still free to use).  Have a long, hard look at the Logon tab. 
*Most* things in there can be disabled safely without killing a
computer.  If you see anything that looks like it belongs to the old
drivers, uncheck it and reboot.  If that doesn't help, start peeking in
the other tabs.  The Drivers tab in particular *may* help.  Tiptoe
carefully in there, and in any other tab.  This will at least restrict
you to areas of the Registry that are likely to be related to the
crashes, and it's a lot harder to typo.