DISCLAIMER: I did not design this fix, and credit to the source is at the end of this post. The information is helpful, and thus I feel it should be shared in order to be easier to find.
I recently had a server 2012 R2 machine go dead in the water with a BSOD 0x00000CA, or a “PNP_DETECTED_FATAL_ERROR” fault. What this fault means is that the Plug n Play manager (the software that controls hardware that is ‘plug n play’) has encountered a problem (usually with a driver of some description). As near as I can tell, there is no fix for it other than to roll back to a backup before the error (at least, no fix for now).
Now, if you’re like me, backups aren’t the first thing that get set up. Sure, they’re important. And they’re in the list of things to set up (I swear). They’re just not first in the list.
So, back everything up in safe mode and then a custom install of Server 2012 over the top to ensure I lose no files. Not quite a bare-metal rebuild, but better than nothing.
Now, the fault I found – the server was configured to use storage pools for data storage. They provide an incredible level of control over how Windows manages storage across drives. One problem – they’re configured by the OS, which has just been reinstalled. The new installation has no idea of the configuration prior.
Now we come to the good part – Server 2012 writes the configuration to disk on the array/drives used by the pool, not to the registry (as Microsoft were so fond of doing in the past). This means that if you bring the RAID array or the drives online (attaching them to the new installation), then Windows is able to see what pools (in the form of virtual disk files) were allocated on that volume. We need to right click the storage pools and set read-write access, after which we can attach the drives to the new installation. Right click the drive and bring it online, and voilà – data remains intact, and is accessible once again.
Almost done now – your freshly mounted storage pools won’t survive a reboot, meaning they won’t automatically reattach at boot. Not to worry, there’s a fix for that. It involves getting into Powershell, but only just.
You need to launch Powershell as Administrator, and run this command:
Get-VirtualDisk | Where-Object {$_.IsManualAttach –eq $True}
This will list all your virtual disks (storage pools) that have been manually attached. Now, to run the command again – but this time we’re going to pipe the output into another command, like so:
Get-VirtualDisk | Where-Object {$_.IsManualAttach –eq $True} | Set-VirtualDisk –IsManualAttach $False
What this does is remove the ‘manual attach’ setting from the drives – which to Windows, is equivalent to ‘auto attach’. Seems a little counter-intuitive, until you think about the fact that it means there is only one variable to adjust and not two. We’re done with Powershell now – type “exit” to close (no quotes, of course).
You will, of course, have a “windows.old” folder in C drive now, but removing that is a job for when your machine is back at full speed.
Credit for this fix has to be given where it is due – many thanks to Rick Claus, also known as RicksterCDN, over at The Regular IT Guy. His blog has all sorts of useful hints, tips, fixes and tricks to help get you out of tight spots in tech. You can find the post with this fix here.
