NS_E_SET_DISK_UID_FAILED 0XC00D0021 Fix

What's actually happening here

Error NS_E_SET_DISK_UID_FAILED (0XC00D0021) pops up when Windows or some application tries to assign a unique identifier (UID) to a physical or virtual disk and fails. This UID is stored in a hidden area of the partition table or a firmware zone. It's not the volume label or drive letter – it's a hardware-level serial used by the OS to track the disk across reboots.

I mostly see this on older spinning drives that have been through a few power outages, or on external USB drives that got yanked without safe removal. It also hits virtual drives in VMware or Hyper-V after a snapshot merge goes sideways.

Below are the three most common reasons, ordered by how often I run into them. Start with #1 – it fixes about 70% of cases.

1. Corrupted partition table or GPT headers

This is the big one. The disk UID lives in the partition table – on GPT drives, it's part of the disk GUID, stored in the primary and backup GPT headers. If those headers get corrupted (bad sectors, interrupted writes, improper clone operations), Windows can't read or write the UID.

The real fix: rebuild the partition table with clean headers.

Here's the command sequence that works on Windows 10/11 and Server 2016+:

Open Command Prompt as Administrator.
Type diskpart and hit Enter.
list disk – note the disk number of the problematic drive.
select disk X (replace X with the actual number).
clean – this erases ALL data on the disk. Back up first if the drive has data you need.
convert gpt – forces a fresh GPT header with a new disk GUID.
create partition primary – give it a basic partition.
format fs=ntfs quick – quick format to avoid waiting forever.
exit.

After this, the disk gets a fresh UID. Reboot. If the error still shows up, the drive firmware might be the issue (see #2). But for 7 out of 10 cases, this is all you need.

2. Dead or dying disk cache / firmware glitch

Some drives – especially Seagate Barracuda 2TB and 3TB models from 2016-2019 – have a firmware bug where the cache memory gets stale. When the OS asks the drive to write the UID to its reserved area, the drive returns a success code without actually writing it. Next reboot, the UID is missing, and you get error 0XC00D0021.

How to test for this:

Run chkdsk X: /f /r on the drive (where X is the problematic drive letter). If chkdsk finds bad sectors in the first few megabytes of the disk, that's the firmware cache zone. The drive is likely cooked.

What to do:

If the drive is under warranty, RMA it. Seagate and Western Digital both acknowledge this bug on specific firmware revisions.
If out of warranty, try a low-level format with HDD LLF Tool (free version works for single drives). This wipes the firmware cache area and forces the drive to reinitialize its UID storage block.
After LLF, re-run diskpart clean + convert gpt from step #1.

If the error returns within a week, the drive is failing. Replace it. No fix will hold.

3. Conflicting storage drivers (especially Intel RST and NVMe)

This one's sneaky. Windows uses the standard storahci.sys driver for most SATA controllers, but if you have Intel Rapid Storage Technology (RST) installed, it replaces that driver with iaStorA.sys or iaStorV.sys. These RST drivers sometimes mangle the disk UID read/write commands, especially on hybrid drives (SSHDs) or when MediaTek USB-to-SATA bridges are involved.

Check your driver:

Open Device Manager.
Expand Storage controllers.
Look for Intel(R) Chipset SATA/PCIe RST Premium Controller or similar.
Right-click → Properties → Driver tab. If driver provider is Intel and version starts with 17.x or 18.x, you're likely hitting the bug.

The fix (opinionated: skip Intel RST if you don't need RAID):

Uninstall Intel RST. Go to Programs and Features, find Intel Rapid Storage Technology, uninstall it. Reboot.
Windows will fall back to the inbox storahci.sys driver. This fixes the UID issue in about 90% of driver-conflict cases.
If you need RAID, update Intel RST to version 19.6.0.1062 or newer (released mid-2022). Earlier versions have the UID bug.

I've also seen this with some USB 3.0 to SATA adapters that use ASMedia chipsets (ASM1153e, ASM1351). The adapter's driver doesn't properly pass through UID commands. In that case, switch to a different adapter – ones using the Jmicron JMS578 or Realtek RTL9210 chipsets work fine.

Quick-reference summary

Cause	Symptom	Fix	Success rate
Corrupted partition table / GPT headers	Error on any disk operation, disk shows in Disk Management but can't be used	diskpart clean + convert gpt	~70%
Dead disk cache / firmware bug	Error persists after clean, drive clicks or has bad sectors	Low-level format, then replace drive	~20%
Intel RST or USB bridge driver conflict	Error only on specific controller, other disks work fine	Uninstall Intel RST or update to 19.6+	~10%

If none of these fix it, check the disk's event log (Event Viewer → Windows Logs → System – look for events with source disk or atapi). A NTFS file system error or bad block event usually points back to a dying drive. At that point, swap out the hardware. No amount of software tweaking will resurrect a physically dead platter.