[geeks] The Registry (?)

[Jon Gilbert]

Thanks a million for the massive info. I mean, the system boots,  
everything seems to be running fine. The only problem is the inability  
of the thing to set sound volume without crashing that application.  
So, we'll see if I can hack it to work. hahaha

On Aug 31, 2008, at 12:13 AM, Alois Hammer wrote:

> 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.
> _______________________________________________
> GEEKS:  http://www.sunhelp.org/mailman/listinfo/geeks


-
Jon Gilbert
PGP fingerprint: 7FA9 B168 73CA A698 DD9E  2DF2 EE1A 3E73 3119 741F