Boot problem solved........

[jeffk55]

Thanks for this and your earlier reply. That advice I accepted . Problem w/ any system restore ect is that the new MB has all new chipset (nVidia 3) ect. Didn't think any of this would help. Do believe that going back to my original XP CD and repairing from there might solve the problem. Of course then it boils down to some weird SP-2 incompatability. Wish I wasn't so gung ho originally and didn't load sp2 before thoroughally testing the system. Did have a problem w/ the upgrade disc though. Eneded up re-repairing using a slipstreamed CD. Sometimes I wonder if a "repair call" isn't left at some low level ie XP thinking it should be "fixing" something but it doesn't have to. Anyways too long ago to remember any specifics. The fact I can boot perfectly using \sos but not normal boot still leads me to believe it is a simple fix somewhere. Not knowing EXACTLY what the difference between the 2 is killing me. Theory is it just shuts off "no echo" but there are screen differences to contend with so it isn't as simple as it looks I would guess. Have also contemplated dropping the BIOS back to an earlier edition. The one on the board is new and a post beta (by a couple of weeks) BIOS from Chaintech. Still think this is a problem but they have been silent on it.
No minidumps (therefore no driver crashes) doen't help either. I swear I'll get to the bottom of this sooner or later (famous last words).
There must be a small program/routine difference between the 2 boot methods.
Bottom line is I'm still here plunking away w/ tests showing the box is faster than anything I've had before in memory writes/re-writes to RAM ect.
After plunking around in the registry I am finally realizing the amount of garbage there and a format/ install is looming. Problem is if the same thing occurres after I do that you'll have to drag me out of here w/ a net. l
AFTER looking over this from MS.. none would seem to apply since the \sos switch works w/ NO ERRORS. Adds to the frustration though...
http://support.microsoft.com/?kbid=330182&sd=RMVP
Now if I knew what this really meant:
"this issue may occur if a system thread generates an exception that the error handler does not catch".
And why would it catch it w the \sos switch???????

 

[dclive]

Clearly you're no longer in a crisis, though, so this bothers you only if you let it.

However, if you really wanted to fix it, you could try the suggestions on that part - remove all third party drivers so you're running MS-only drivers, and run driver verifier to see if you can cause a driver to fail, and check driver signatures and remove unsigned drivers.

That said, I wouldn't bother. You have to boot with /SOS - big deal. Make it your default, and move on. How often do you boot, anyway? On my laptops I might boot once every month, around the second Tuesday of the month (due to Microsoft updates); otherwise, why worry about it?

 

[jeffk55]

Agee. I've booted more times this past month then I did in years. LOL. Anyways as to the 3rd party driver thing, on a related topic I did a search of "certified" drivers' and apparently my system had NONE whatsoever. Not to mention windows drivers are not the best anyways and
again considering the /sos switch and how it works just fine I have a hard time believing it's ANY driver on my system is causing a problem.

 

[dclive]

I think you might be a bit confused. Windows drivers are the best if you want stability - they've been thru rigorous driver testing, and while they may not have all the features of an OEM driver, they'll work, they won't BSOD the box, and they'll be reliable.

I'm sure you have plenty of Microsoft certified drivers; you may be a bit confused on how to find them.

MPSReports (found in my .sig) will run reports that will tell you which drivers are and are not certified; that's one simple way to check.

When you went back to the original registry on the box (by copying over the sam/software/system/security files, after making a backup, from recovery console) what happened?

 

[jeffk55]

Ran the altenate ntdetect. Can honestly say I didn't have a clue there Lots of pretty text though. After that was done it BSOD on me as usual. Had to f8 and boot to VGA mode. Then correct resolution, run msconfig and check /sos again. Then rebooted. Alt ntdetect ran again, then "normal" boot. Changed back to normal ntdetect.
As to the other suggestoin: I assume the steps your talking about would "restore" to the last repair install. Which didn't work either. There were 2 repair installs. one right after the other. From the dates on the files I assume this just backed up the first repair install so I doubt if that would help but I'll have to dig some more into your suggestion.
Pretty sure your program link was the one that told me "no certified" drivers. Will check again.
CAB file:www.qualiteitems.com/images/JEFFK_MPSReports.cab
OR
CAB

 

[jeffk55]

Lots of "stuff in that file. Brings back years of memories.
Confused by Microsoft???? There's a concept LOL.
So if the error occurs after ntdetect but prior to loading drivers what does that leave????
Using the /sos switch successfully loads all the drivers and gets me to logon screen.

 

[dclive]

I have no idea what you are saying about 'alternate ntdetect'. If you want to boot permanently using /sos, just edit boot.ini on c:.

re: repair files, you can do a quick search on here and you should find the procedure for the placement of those sam/software/system/security files. Find the dates on those files in c:\windows\repair, and ask yourself if your system worked/booted normally at that time. Did it?

 

[jeffk55]

There's an "alternate ntdetect.com on the Windows disc. It is a "debug" version. All you do is rename ntdetect in the root drive and then paste the "alternate" file.
see this link
http://www.windowsitlibrary.com/Content/435/13/6.html
I've set the /sos swiutch in mscofig and also checked the "don't show this screen again" box.
In effect a perminent /sos boot w/ no nag screens.

 

[dclive]

Completely remove Symantec - all program features. Does this still happen?

Description = DVD/CD-ROM drives
UpperFilters = GEARAspiWDM
Remove that. Still?

Remove your Logitech mouse drivers, also filter drivers. Still happen?

Per QFECheck, you should reinstall:
KB902400: This hotfix should be reinstalled.
The following files are incorrect for this hotfix:
C:\WINDOWS\SYSTEM32\DLLCACHE\MIGREGDB.EXE

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager
BootExecute REG_MULTI_SZ autocheck autochk *\0sprestrt\0sprestrt\0\0
^^ That's not normal. Normal is "autocheck autochk *". What is that other stuff?

Easy way to see signed vs. unsigned drivers: Run verifier.exe from Start/Run. Click Next, then Next. What you see in that list is the unsigned drivers on your system.

 

[dclive]

Originally posted by: jeffk55
There's an "alternate ntdetect.com on the Windows disc. It is a "debug" version. All you do is rename ntdetect in the root drive and then paste the "alternate" file.
see this link
http://www.windowsitlibrary.com/Content/435/13/6.html
I've set the /sos swiutch in mscofig and also checked the "don't show this screen again" box.
In effect a perminent /sos boot w/ no nag screens.

You don't have a debugger attached; why would you run the debug version of ntdetect?

 

[dclive]

re: repair files, you can do a quick search on here and you should find the procedure for the placement of those sam/software/system/security files. Find the dates on those files in c:\windows\repair, and ask yourself if your system worked/booted normally at that time. Did it?
^^^
Let me know.

 

[jeffk55]

Your asking me???? Anyways I found this:
sprestrt....... It's windows stuff I think..
http://www.microsoft.com/technet/prodte...8284e-d1d2-4dc7-88d3-4e75bbf63a97.mspx
will check the other stuff after looking at this.
http://www.programchecker.com/file/2519.aspx

 

[jeffk55]

No there dated Nov 15th or so... Not good.
I used the term debug mode loosly. Basically gives you an echo for the loading of hardware prior to GUI stuff That one registry key though... There should be a file associated with it that wasn't created. Will back up registry and delete the 2 instances of sprestrt. Really think that should do it.
Here goes nothing.
NOTHING..... Still think it's related to the loading bar screen. The one that's bypassed during /sos boot. that SPRESTRT is tied into it somehow but there must be another key related to it. Or deleting the sprestrt in that other key wasn't done correctly....
spestart.exe seems to be authentic. At least version info is OK. Wonder if I can run it at a command prompt to repair "gui"???? Can you tell I'm treading water here?

 

[dclive]

Originally posted by: jeffk55
Your asking me???? Anyways I found this:
sprestrt....... It's windows stuff I think..
http://www.microsoft.com/technet/prodte...8284e-d1d2-4dc7-88d3-4e75bbf63a97.mspx
will check the other stuff after looking at this.
http://www.programchecker.com/file/2519.aspx

I have no idea what you are referring to. What are you talking about?

 

[dclive]

Originally posted by: jeffk55
No there dated Nov 15th or so... Not good.
I used the term debug mode loosly. Basically gives you an echo for the loading of hardware prior to GUI stuff That one registry key though... There should be a file associated with it that wasn't created. Will back up registry and delete the 2 instances of sprestrt. Really think that should do it.
Here goes nothing.

Why wouldn't briefly trying the Nov 15 registry be a good idea?
What about all of the other suggestions?

 

[jeffk55]

Well maybe i'm being too logical about all this stuff. After all this is Windows All the other suggestions involve modifying things that have worked for months if not years. I know there is a lot of garbage in the registry from prev OS's, motherboards, software ect. but all was well behaved. 5 minidumps in 3 years is a pretty good track record for my system. The Nov thing is when I redid the motherboard/cpu ect. The obsession with the bar progress report and that being the apparent only differece between /sos and normal boot, the fact that there are programs that load (in particular the bar graph) that are native NT API's (if my VERY quick reading is correct) (which is where I believe my system falls down) and that anomoly in the registry key pointing to a failed GUI load ect. are keeping me focused on this path till full failure looms. Latest key I'm looking into to see what it does:
If sprestrt.exe is trying to run in normal boot it should find this file Undo_Guimode.txt, which doesn't appear to exist. So my twisted logic is that there is a glitch somewhere in this system as to running some native API prior to loading the "real windows" so to speak. Working on "real windows" problems is counter productive.
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Nls\MUILanguages\RCV2\sprestrt.exe

FROM MS:
Sprestrt.exe and Undo_Guimode.txt


Sprestrt.exe, which runs at the start of GUI mode, determines if GUI mode ran previously and failed. If so, Undo_Guimode.txt is used to bring files back to the state appropriate for the beginning of GUI mode.

 

[jeffk55]

FOUND IT.................. SOOOOOOOOO SIMPLE (so far)
Extracted and installed NTLDR from my original CD (pre SP1 version) replacing the buggy/damamged or whatever NTLDR from the SP2 disc.
No formats, no software reinstalls YEA>>>>>>>> Excuse my enthusiasm
BOOT COMPLETELY NORMALLY............. Funny isn't it.......