Boot failure due to "bad patch" - need fix collaborators

[gregrocker]

Over time here we've learned that the most fatal and irreparable cause of Win7 failure to boot is labeled by Startup Repair as a bad patch. As it's often reported by OP as having been Windows Update or a driver just installed I'm wondering if there is some last-resort surgery that can be done when all other known repairs solutions fail.

I am testing right now if all recent content of System32/drivers can be backed up and then deleted in Windows Recovery console using Copy & Paste - in Windows Recovery Console. If the fatal driver is gone my thinking is that Win7 might start and reload all drivers from Driver Store.

I'd also like to test if recently installed Updates can be backed up and deleted from their install location similarly using a boot disk. I realize this is fraught with danger and merely is experimental to save an installation in which all else has been tried and hope lost.

Can any Updates experts suggest where exactly to look and what to include to get the latest Updates? Any predictions on efficacy, or other ideas to save installs that won't boot on this error?

 

[NoelDP]

Beware of relying on file dates for anything in the System32 structure - the apparent dates may be vastly different from the installed dates, and some of the files are dynamic as well.

If the problem is truly 'failed updates' check the softwaredistribution\ folders to see what's there - it should give some clues, and the dates will be more reliable.

 

[gregrocker]

Is it even conceivable to delete the latest updates from these folders from WinRE, and how would you go about that Noel?

I understand some registry keys are toggled during install of these updates which aren't populated in the Updates folder, but will having the update itself gone give it a chance to start?

 

[NoelDP]

Messing around with the Winsxs folder isn't to be recommended in general - the drivers folder is a bit different, as it does have backups.

I would **never** delete stuff - renaming it is acceptable and easy to do from RE, since it seems basically to ignore permissions (you can easily replace/delete/rename files owned by TrustedInstaller at least, without having to mess with permissions)

<thinking aloud>
All updates will make significant changes to the COMPONENTS registry hive - it may be worth copying that to a working machine and loading it to examine the changes there using something like RegScanner (NirSoft) which can search by modification date.
You could then compare the file structure found with what's supposed to be present according to the hive.
(Arduous work but I suppose it could be semi-automated?)

</thinking - it hurts too much <g/>

 

[gregrocker]

I know, that's why I've never gone there. But it would be nice to have a fix for "Bad Patch" which is the most common fatal Startup Repair condition.

To delete critical system drivers from sys32/drivers (accidentally) in WinRe forces auto-repair that restores their shadow copy or from Driver Store. Hence wanting to use the date to find the latest, to avoid deleting unnecessarily. However since not all are installed in /drivers it's a real can of worms.

OP would almost need to know the driver to research it's install location. Likewise Update?

 

[NoelDP]

Many drivers will be referenced in the registry - either in
HKLM\SYSTEM\CurrentControlSet\Enum\Root
or in the Services key
again - searching by date could be productive there.

 

[gregrocker]

From WinRe? Path?

 

[NoelDP]

You'll have to import the hive into a working machine, I suspect.
The HKLM hive is a bit of a fun one..... C:\Windows\System32\config\SYSTEM would be the hive to load.

 

[Cosmitz]

Sorry to bump in but in trying to get my old system up i spent a great deal of time with the System hive. While i did end up doing a reinstall after a good 90 torturous hours of debugging, it's plagued me so much that i'm halfwilling to go wild on it and try any and all conceivable things. I'll setup a testbed sometime this week and see if i can put to use any of the tips.

I've also found a few bootflag objects that might help forcing the system to start up driver-less, oddly while tweaking my new install, which i'll give a shot.

I really wish the MSDN would be a bit more technically inclined sometimes. Found great info on there that on occasions was dumbed down or partial.

 

[tom982]

You'll have to import the hive into a working machine, I suspect.
The HKLM hive is a bit of a fun one..... C:\Windows\System32\config\SYSTEM would be the hive to load.

HKLM isn't a hive, it's a root key handle; SYSTEM is the hive

 

[NoelDP]

Hey - I learned Windows when HKLM was a hive in itself!


Not my fault they changed the goalposts again.

 

[tom982]

Hey - I learned Windows when HKLM was a hive in itself!


Not my fault they changed the goalposts again.

:roflmao:

Excuse my ignorance then, that predates me by quite a bit Wonder why they changed it...

 

[NoelDP]

That was back in the days of Win9x (and I might be getting confused anyhow - it's been years since I looked in a Win9x registry!)

 

[gregrocker]

Cosmitz has a test bed with this exact "Bad Patch" boot failure he's willing to offer for testing fix surgeries from WinRe.

Would you want to guide him Noel (or anyone else with experience at this) to try deleting the last month's-worth of Updates and drivers?

 

[NoelDP]

I'm likely to be only periodically available over the next few days - whereabouts is he? (think time-differences)

 

[gregrocker]

Post #9 above.

He's also here with the precipitating boot failure: 0x7b - 0xC34 - Win7 Pro 32bit

 

[NoelDP]

Duh! - it's bedtime!
I'll sleep on it and get back to you after looking at the thread.