Windows Devices Not Working, Diagnosed and Fixed (2026 Guide)

Why Windows Devices Not Working During Deployment or After Updates

Picture this: you're an IT admin rolling out a fresh Windows image across a batch of Surface devices. You've done this a hundred times. MDT is configured, the task sequence is solid, and then, one machine bricks halfway through. The bdd.log file spits out something like "Disk(0) was not found. Unable to continue." and the deployment just stops dead. Or maybe it's a different scenario, you pushed a routine UEFI firmware update overnight, came in the next morning, and now half your Surface fleet is sitting at a BitLocker recovery screen, stuck in an infinite reboot loop. Neither situation is fun. Both are fixable.

I've seen both of these scenarios more times than I'd like to admit, and the frustrating part is that Windows' own error messages are nearly useless at pointing you toward the real cause. "Missing Storage Driver." "Disk OSDDiskIndex(0) can not be found." These messages sound like hardware failures. They're not. They're a configuration mismatch, one that Microsoft has documented, but buries under KB numbers that most admins never stumble on until they're already in the weeds.

So why does this happen? There are two distinct root causes at play in modern Surface deployments, and they sometimes overlap in ways that make diagnosis even harder.

Root Cause #1, Storage Spaces and the phantom Disk0. Certain Surface devices with a 1-TB storage configuration don't actually use a single 1-TB SSD. Instead, they use Microsoft's Storage Spaces technology to stitch two 512-GB SSDs together into one virtual drive. The problem is that Storage Spaces drives are virtual, meaning the operating system lists them after the physical drives in the disk enumeration order. So when your MDT task sequence targets Disk0, the way it always has, it finds the physical drives first and the virtual storage volume ends up at Disk2 or Disk3. Windows Devices Not Working in this way is entirely a software enumeration issue, not a driver problem, not a hardware failure.

Root Cause #2, BitLocker PCR misconfiguration and firmware updates. On Surface devices where BitLocker is active, a firmware update to the UEFI or the Trusted Platform Module (TPM) changes the cryptographic signature that BitLocker uses to verify boot integrity. Normally this is fine, BitLocker is designed to tolerate small changes like this. The problem only surfaces (no pun intended) when BitLocker isn't binding to the default Platform Configuration Registers (PCR 7 and PCR 11). If someone has manually defined PCR values through Group Policy, or if Secure Boot has been turned off, then a firmware update that would ordinarily be transparent instead looks like a tampered boot environment. BitLocker panics, demands the recovery key, and when the recovery key doesn't solve the loop, it doesn't, because the real issue is the PCR binding, the device keeps rebooting.

Both problems affect real enterprise environments running real Surface hardware. The affected device list is specific, and knowing whether your machine is on it saves hours of pointless driver hunting. Browse all Microsoft fix guides →

The Quick Fix, Try This First When Windows Devices Not Working

Before you spend two hours rebuilding your MDT task sequence or calling Microsoft Support, run through this quick diagnostic to identify which of the two root causes you're dealing with. The fix for each is fast once you know which path you're on.

If your Windows device not working symptom is a failed MDT deployment with a Disk0 error:

Check your device model and storage size first. Open the Surface's UEFI settings (hold Volume Up and press the Power button), navigate to the device information screen, and look at the storage configuration. If you're on a Surface Pro (5th Gen) 1-TB, Surface Laptop (1st Gen) 1-TB, Surface Pro 6 1-TB, or Surface Laptop 2 1-TB, you're almost certainly hitting the Storage Spaces disk enumeration issue. Your fix is a single change in MDT: swap the disk target from Disk 0 to Disk 2 in your "Format and Partition Disk (UEFI)" task sequence step. If an SD card is inserted in the device, bump that to Disk 3 instead. That's it. No driver updates needed, no imaging changes, no hardware replacements.

If your Windows device not working symptom is a BitLocker recovery prompt after a firmware update:

Don't keep entering the recovery key, it won't fix the loop. Open an elevated PowerShell session on a working machine and suspend BitLocker on the affected drive first. The command is:

Suspend-BitLocker -MountPoint "C:" -RebootCount 0

The -RebootCount 0 parameter is important, it keeps BitLocker suspended through multiple reboots, which matters because UEFI and TPM firmware updates often require two or three restarts to complete. Once the firmware installation is fully done and the device is booting normally, resume protection with:

Resume-BitLocker -MountPoint "C:"

If the device is already in the reboot loop and you can't get to a command prompt, you'll need to boot into Windows Recovery Environment (WinRE) first. Hold Shift while clicking Restart from the login screen, or boot from a USB recovery drive, then open Command Prompt from the advanced options. From there the same PowerShell cmdlets will work.

Advanced Troubleshooting for Windows Devices Not Working at Enterprise Scale

The steps above handle individual machines. But in an enterprise environment managing hundreds or thousands of Surface devices, you need to think about these issues differently, at the fleet level. Here's how to get on top of both the MDT deployment issue and the BitLocker PCR problem across your whole org.

MDT Deployment at Scale, Managing Multiple Task Sequences

The official Microsoft guidance is clear: a task sequence targeting Disk2 for Storage Spaces devices cannot be shared with standard single-SSD devices. This is non-negotiable. In practice, the cleanest approach is to maintain two separate deployment task sequences: one for your Storage Spaces 1-TB Surface fleet and one for everything else. You can use MDT's dynamic variable list and database queries to automatically select the right task sequence based on the device's Make and Model. In CustomSettings.ini, a rule like this can help:

[Surface Pro (5th Gen)]
OSDDiskIndex=2

[Surface Laptop]
OSDDiskIndex=2

[Default]
OSDDiskIndex=0

Test this logic carefully, MDT's model detection pulls from WMI and the exact string it returns for "Surface Pro (5th Gen)" may vary. Use wmic computersystem get model on the device itself to confirm the exact string before building rules around it.

BitLocker at Scale, Group Policy and SCCM/Intune Integration

If you're managing BitLocker through Group Policy or Microsoft Intune, the PCR configuration policy is likely being pushed from the top down. Before any fleet-wide firmware update campaign, audit your BitLocker GPO settings. Pull a report of all devices showing non-default PCR bindings using PowerShell remoting:

Invoke-Command -ComputerName $deviceList -ScriptBlock {
    manage-bde.exe -protectors -get C: | Select-String "PCR"
}

Any device returning PCR values other than 7 and 11 needs the Secure Boot + PCR remediation treatment before it gets a firmware update. Tag those devices in your CMDB and create a separate pre-update remediation task for them.

Event Viewer Analysis for BitLocker Loop Diagnosis

When a device is stuck in a BitLocker recovery loop and you're not sure if the issue is PCR-related or something else, the Windows event logs can help. If you can get the device to boot into WinRE, open Event Viewer and navigate to Applications and Services Logs > Microsoft > Windows > BitLocker-API > Management. Event ID 853 indicates that BitLocker found a change in the boot configuration that doesn't match the sealed PCR measurements. Event ID 778 means the TPM was unable to seal the BitLocker keys, which often points to a TPM firmware version issue. These event IDs help you distinguish between a PCR mismatch (fixable with Secure Boot remediation) and a more serious TPM hardware problem (which may require a TPM reset or escalation).

When a TPM Reset May Be Required

In rare cases, particularly after a failed or interrupted dTPM firmware update, the TPM itself may be in a bad state. A stuck or corrupted TPM cannot seal new BitLocker keys, which means even after you fix the PCR configuration, BitLocker can't resume properly. Signs of this include BitLocker resuming successfully in PowerShell but the device still prompting for recovery at next boot, or manage-bde.exe -status showing "Protection On" but "Conversion Status: Fully Decrypted." A TPM reset through UEFI (Security > Clear TPM) will resolve this, but it will also invalidate all TPM-protected keys, including your BitLocker keys. Have your recovery key ready and backed up before you do this.

Prevention & Best Practices for Windows Devices Not Working in the Future

Both issues covered in this guide are entirely preventable with the right preparation. I've watched organizations hit these problems repeatedly, the MDT Disk0 error on every new Surface refresh, the BitLocker loop every firmware cycle, simply because no one took 20 minutes to lock in the right procedures once and document them properly. Here's how to make sure you're never in this situation again.

Build device-awareness into your MDT structure from day one. Every Surface device model that enters your fleet should be catalogued for its storage configuration. Before a new model ships, check Microsoft's documentation to confirm whether it uses Storage Spaces or a single SSD. Create a dedicated task sequence for any Storage Spaces model, label it clearly ("Surface 1TB Storage Spaces Deployment"), and restrict it so it can only be selected for the appropriate device types. Don't rely on technicians remembering, enforce it through MDT's device collection rules.

Automate PCR checks as part of your pre-patch process. Before any firmware update campaign, run a fleet-wide PCR audit. This is a five-minute PowerShell script, not a project. Build it into your patch preparation runbook and run it at the start of every Surface firmware update cycle. Non-compliant devices get suspended BitLocker and Secure Boot remediation before the firmware goes out. Compliant devices go straight to the update. No exceptions.

Rotate and escrow your BitLocker recovery keys regularly. Recovery keys should live in Active Directory, Azure AD, or your enterprise key management solution, not in someone's spreadsheet. Audit recovery key escrow health monthly. A device with no escrowed recovery key is a device that becomes a paperweight if the unexpected happens. This matters doubly for Surface devices, because their firmware update cadence is active and their BitLocker interaction is more complex than standard PCs.

Test firmware updates on a canary group first. Never push a Surface firmware update to the whole fleet simultaneously. Pick 5-10 representative devices, push the update to those first, watch them through two or three reboot cycles, confirm BitLocker re-engages properly, and only then roll out to the broader fleet. This 48-hour canary period has saved more than one admin from a fleet-wide incident.

Frequently Asked Questions