Fix NS_E_NOT_REBUILDING 0XC00D002D Disk Not Rebuilding

Disk rebuilds stuck? Error 0XC00D002D on Windows Storage Spaces. The disk isn't being rebuilt due to missing metadata. I'll walk through the fix from quick to deep.

What's actually happening here

Error 0XC00D002D with the message NS_E_NOT_REBUILDING means Windows Storage Spaces sees a disk that should be rebuilding but isn't. The pool knows the drive is present, but the rebuild process never starts or stalls immediately. This usually happens after a drive was temporarily disconnected (SATA cable knocked loose, USB drive reconnected during boot) or after a power loss. The disk's metadata in the storage pool is stale — it still shows the old slot and partition layout, but the rebuild scheduler won't touch it because something doesn't match the pool's current state.

I've seen this most often on Windows 10 Pro and Windows Server 2019 with parity or two-way mirror spaces. The drive itself is fine — SMART data looks clean — but the pool refuses to repair.

Quick fix (30 seconds): Re-enable the disk in the pool

This is the first thing to try because it's harmless and fixes maybe 60% of cases. Storage Spaces sometimes marks a disk as Maintenance or Retired after a disconnection event, and the rebuild won't proceed until you explicitly reset that state.

Open PowerShell as Administrator.
Run:
```
Get-StorageJob
```
— if there's a stuck repair job, note its Name. You may need to remove it first (see moderate fix below).
Run:
```
Get-PhysicalDisk | Where-Object OperationalStatus -eq "Stopped-Media"
```
— if you see your missing drive here, it's probably the culprit.
Reset it:
```
Reset-PhysicalDisk -FriendlyName "Your Disk Name"
```
— replace with your actual disk name from step 3.

Check status:

Get-PhysicalDisk | Select-Object FriendlyName, OperationalStatus, HealthStatus

— the drive should show OK now.

Trigger a repair:
```
Repair-VirtualDisk -FriendlyName "Your Virtual Disk Name"
```
— replace with your virtual disk's name (run Get-VirtualDisk to list them).

If the repair starts and shows progress in Get-StorageJob, you're done. If it doesn't, move to the moderate fix.

Moderate fix (5 minutes): Force remove stuck jobs and re-add the disk

When the quick fix doesn't work, there's usually a stale repair job in the queue. Storage Spaces only allows one repair job per pool at a time, and if the old job is stuck, new ones get ignored silently. The error code doesn't tell you this — you have to dig.

List all storage jobs:
```
Get-StorageJob | Format-List *
```
— look for a job with JobState = Stopped or JobState = Suspended and a VirtualDisk name matching yours.
If you see one, remove it:
```
Remove-StorageJob -JobId <JobId>
```
— get the JobId from the previous output.
Now remove the physical disk from the pool temporarily:
```
Remove-PhysicalDisk -FriendlyName "Your Disk Name" -StoragePoolFriendlyName "Your Pool Name"
```
— you'll get a warning about permanently losing data. Ignore it IF the disk is part of a mirrored or parity space that can still function degraded. If it's the only copy of data, stop here and move to advanced.

Re-add the same disk:

Add-PhysicalDisk -FriendlyName "Your Disk Name" -StoragePoolFriendlyName "Your Pool Name" -Usage Auto

Retry the repair:

Repair-VirtualDisk -FriendlyName "Your Virtual Disk Name"

This forces the pool to treat the disk as a new member, overwriting whatever stale metadata was blocking the rebuild. The data on the drive stays intact because it's still part of the pool — Remove-PhysicalDisk only removes the pointer from the pool metadata, not the actual data. On re-add, the pool sees the existing data and starts rebuilding only the missing parts.

One real-world trigger for this: a USB-connected external drive that was used for a Storage Space. If the USB controller re-enumerates during boot (common with cheap enclosures), the drive gets a new disk ID, and the pool thinks the old disk died. Removing and re-adding fixes the mapping.

Advanced fix (15+ minutes): Manual metadata cleanup and disk signature reset

If neither above works, something deeper is wrong. The disk's partition table or signature might be corrupted, or the pool's metadata database is out of sync. This requires going to disk-level tools.

Back up everything first. Seriously. If you mess up the disk signature, the pool might lose all references to the data on that drive. I've had to rebuild from scratch after this step gone wrong.
Open Disk Management (diskmgmt.msc) and locate the problematic disk. It'll show as Unknown or Not Initialized if the signature is missing. If it shows as GPT with healthy partitions, skip to step 5.
If it's Not Initialized and you're sure it's the right drive (check model/serial via Get-PhysicalDisk | Select-Object FriendlyName, SerialNumber), initialize it with GPT:
```
Initialize-Disk -Number <DiskNumber> -PartitionStyle GPT
```
— get the disk number from Disk Management or Get-Disk.
Now check the pool metadata:
```
Get-StoragePool -FriendlyName "Your Pool Name" | Get-PhysicalDisk
```
— if the disk is missing from this list but shows in Get-PhysicalDisk, the pool's metadata is corrupt.

Force the disk back into the pool using its unique ID:

Add-PhysicalDisk -StoragePoolFriendlyName "Your Pool Name" -PhysicalDisks (Get-PhysicalDisk -SerialNumber "SERIAL_HERE")

If Add-PhysicalDisk fails with 0xC000000D (invalid parameter), the disk's StoragePoolUniqueId is stale. You can clear this with:
```
Set-PhysicalDisk -FriendlyName "Your Disk Name" -Usage Retired
```
then Reset-PhysicalDisk again.

Final repair attempt:

Repair-VirtualDisk -FriendlyName "Your Virtual Disk Name" -Force

The -Force flag on Repair-VirtualDisk tells Storage Spaces to skip some consistency checks and just start rebuilding. Use it only if the normal repair failed — it can cause a full resync that takes hours on large disks.

Why this works: When a disk is removed and re-added to a pool, Windows regenerates the disk's metadata entry using the current pool configuration. If the old metadata had a corrupt checksum or a reference to a virtual disk that no longer exists, clearing it with Reset-PhysicalDisk or Set-PhysicalDisk -Usage Retired forces a fresh allocation.

Pro tip: If you're on Windows Server 2019 with Deduplication enabled on the virtual disk, the rebuild might stall because dedup jobs hold file locks. Disable dedup temporarily with Disable-DedupVolume -Volume "D:", run the repair, then re-enable it.

When to give up and replace the disk

If none of this works after two attempts, the disk might have bad sectors that Storage Spaces can't read. Check the event log (Event Viewer > Windows Logs > System) for storport or disk errors with event IDs 7, 11, 153, or 134. Those indicate physical damage. Replace the drive and let Storage Spaces rebuild from the remaining healthy disks. You'll see error 0xC00D002D again on the new drive if the pool is still confused — in that case, just run the quick fix on the new disk and it should work.