We have recently run into the following issue :

Startup Repair : The Startup Repair tool can solve many common startup problems automatically. Startup Repair performs an exhaustive analysis to diagnose your startup problems, including analyzing boot sectors, the Boot Manager, disk configuration, disk integrity, BCD registry file integrity, system file integrity, registry integrity, boot logs, and event logs. It will then attempt to solve the problem, which may involve repairing configuration files, solving simple disk problems, replacing missing system files, or running System Restore to return the computer to an earlier state. Because Startup Repair performs these tasks automatically, you can solve startup problems much faster than performing the analysis and repair manually.

In our case, this behavior is disjoining our systems from the domain because it is restoring the system back to it's original image. It blows away most if not all of the installed software. I'm not convinced Startup Repair is making the right choice.

How can this be disabled if we choose to do so and can it be disabled globally (bcdedit ?) ? If it is disabled would the systems then just "Blue Screen" when a similar event occurs ?

Let me know if any of you have had to deal with this issue, or what really is the best practice here. I would hate for a large power failure etc to cause 100 systems to invoke startup repair and disjoin themselves.



This should do the trick:

bcdedit /set {default} bootstatuspolicy ignoreallfailures


bcdedit /set {default} recoveryenabled No

Also, you can clear the registry key here: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ BootExecute

(Haven't tried this yet, but it looks promising)

Windows self-repair... never quite what I was hoping for.

As for automating, it looks like bcdedit has /save and /import flags - so if that export is transferrable to another system, you should be able to roll that into a login script easily.

(pre-edit idealistic thinking) Sorry if I'm oversimplifying, but if you take a system snapshot after the system is completely setup (or update your image to include that snapshot), I'd think that would cause the automatic rollback to revert to the state you're hoping for.

  • You make a good point, however I still would not want the system ever to do a System Restore on it's own. I would like to prevent the ability for the Startup Repair to be able to invoke any rollback without administrator intervention. – Kev Sep 1 '10 at 17:21
  • I'm curious about what you'd be worried would happen? This seems like it would generally be helpful, but maybe I'm missing something about how it works? – Kara Marfia Sep 2 '10 at 1:59
  • I am worried about this happening in large numbers, such as a power event which hard powers downs say 500 systems. A percentage of them with boot issues may run the System Restore, which will : 1. Disjoin the machine from the domain, Roll Back Software, Updates, Antivirus etc. 2. Even if we take a snapshot going forward after the domain is joined or as a part of the image, if this happens the secure channel between the machine and the domain may not auth depending how long it's been. 3. It just seems like the potential is there for a messy situtation requiring admin intervention – Kev Sep 2 '10 at 3:32
  • Thanks, I can see that now. Especially since my home system lost power yesterday and I got to experience this firsthand... I'll be editing the settings in once I finish reading. SRT seems a bit overaggressive in its desire to back up to restore points. – Kara Marfia Sep 2 '10 at 15:00
  • 1
    bcdedit /set {current} bootstatuspolicy ignoreallfailures - I had to use this command - FYI – Kev Sep 15 '10 at 12:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.