I try not to reboot my PCs too often – frankly I thought I’d left the days of daily reboots behind with Windows 95 – but, faced with a display driver bug on my Surface Pro 3 (that seems to be triggered by the Azure Portal), a change of password that led to repeated authentication prompts (and OneDrive refusing to sync), together with some software updates pushed to my PC from SCCM, I had little choice this afternoon.

Unfortunately that “quick reboot to get things working again” turned into a disaster, with an hour long support call, followed by a desperate attempt to recover the last few hours’ work.

Stuck in a BitLocker loop

Friday the 13th. Restart PC following updates and get this. Arghhh! pic.twitter.com/f1gizmxHg0

— Mark Wilson (@markwilsonit) May 13, 2016

After rebooting, I found that a Windows 10 update hadn’t properly applied. Each time I entered my BitLocker PIN, I was faced with a message that invited me to use the BitLocker key to recover my PC. My IT support team gave me my key… and then after a restart we went round the loop again. We tried hard resets, turning the TPM on and off in the BIOS and more, until I found a TechNet wiki article that seemed to describe the issue (or at least something very like it).

To terminate this BitLocker recovery loop, I needed to suspend BitLocker from within the Windows Recovery Environment (WinRE). That’s OK, as long as you have the recovery key and, following the advice in the article linked above, I chose the “Skip this drive” link at the bottom of the page that requests entry of the recovery key, before selecting Advanced options/Troubleshoot/Advanced options/Command Prompt.

Next, I disarmed BitLocker using the following commands:

manage-bde -status c:
manage-bde -unlock c: -rp recoverypassword
manage-bde -protectors -disable c:

With BitLocker disabled, I hoped to be able to restart the PC and boot Windows, but unfortunately it was still not playing ball. I’ll be driving to the office on Monday for someone to take a look at my PC and I suspect a rebuild will be on the cards…

Work in progress

Despite the support team’s assurances that all of my data is on servers, I’m pretty sure it’s not. All of my data until I changed my password is on servers but anything since then has been failing to sync. If the sync engine can’t authenticate, I’m pretty sure I must be working from a local copy – which will be lost if the PC is rebuilt!

The items of most concern to me were some scripts I’d finally got working this afternoon; and any notes in OneNote.  I wrote last year about issues with OneNote and OneDrive (now overcome by doing it properly) but goodness knows where the unsynced changes are (again, I found a backup, but it doesn’t have the latest changes in it).

Again, using the WinRE Command Prompt, I backed up the files I thought were most likely to be missed. I tracked down the scripts that I’d finally completed and that had led to a few late nights this week (phew!) – and made a backup copy of my user profile, just in case.

The last worry for me was my browser. Forced by policy to use a Microsoft browser, I had lots of open tabs in Edge, as well as a few in Internet Explorer. The ones in Edge included the various posts I’d found that had helped me to complete my scripts – and I wanted to go back through them to blog about what I found…

Edge does recover sessions after a crash but, with a potential PC rebuild on the cards, I’m not sure I’ll ever get the chance so I tried tracking down the location of the recovery data.  Brent Muir’s fascinating look at Windows 10 – Microsoft Edge Browser Forensics told me where to find the recovery files (in %userprofile%\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC\MicrosoftEdge\User\Default\Recovery\Active) but they are binary. Gleb Derzkij’s answer to a Stack Overflow forum post looked useful but I couldn’t get it to work.  What I could do though was open each of the (115!) .dat files in the Active Recovery folder using Notepad and see enough information in there to identify the URIs, then manually copy and paste them to a text file (ready to open when I’m back at my PC).

So that’s recaptured my work and the PC is ready to be completely razed to the ground if necessary. And the moral of the story? Never apply updates on Friday the 13th!

@markwilsonit have you not learned, change freeze on a friday 13th :-)

— Mark Vale (@UnifiedVale) May 13, 2016