Last night I softly (which sounds like was very gentle and kind to Windows) rebooted (to let Patch Tuesday do its work) my persistent Windows 7 virtual desktop (using Horizon View 5.2) and today I found I couldn’t connect to it. Why? In my View I run two of everything – two Security Servers, two Connection Servers and yes, two Windows 7 virtual desktops in case one stops working explicably. Opening the VMware Remote Console on the VM in question I discovered it was stuck in a loop attempting and failing an unwanted repair job. This is caused by the default when you get one of those ugly black screens in Windows being “Launch Start-up Repair”.
I’ve had this happen to me a couple of times in my time of using Windows especially the more recent Windows /7/8/2012 releases which all display this functionality. 9 times out 10 the repair either is unnecessary or doesn’t work. So decide to consult the technical bible of the day – twitter – for suggestions on how to stop this ever happening again. Heck, I might even consider using in all my templates and parent VMs in linked clones.
Chris Neale of chrisneale.wordpress.com came up trumps first:
Followed quickly by Marcus Toovey
BCDedit is a utility for modifying what Microsoft call “Boot Configuration Data” (BCD) files provide a store that is used to describe boot applications and boot application settings. The objects and elements in the store effectively replace Boot.ini. Ahhh, boot.ini. That takes me back to when I was lowly NT4 instructor teaching RISC paths to hopeful MCSE candidates.
Whether the change should be applied to “current” or “default” is perhaps a bit moot – I imagine the default, is the current one – unless you selected a different boot option at start-up. What interested me was different settings being applied – and which was the right one. Chris quickly pointed me to a Microsoft MSDN article that summarises the differences:
I was also interested to know what criteria triggers a Startup Repair job if one hasn’t been manually requested. I have a feeling there is some sort of intergar in the Windows registry which accrues on N number of dirty shutdowns, and then N number of dirty shutdowns has occured this triggers the repair option – perhaps regardless of whether there is anything to repair as such.
As for the settings the general verdict is to turn them all on – in a belt and braces approach to try and stop this happening again.