STATUS_NOT_SAME_DEVICE (0xC00000D4) Fix Guide

You drag a folder from one drive to another, halfway through Windows throws STATUS_NOT_SAME_DEVICE (0xC00000D4), and now you've got half a folder in two places. Frustrating as hell.

Here's the fix. Then I'll explain why Windows does this and how to keep it from happening again.

The fix

Stop what you're doing. Don't retry the move yet. The error almost always means Windows lost the connection to one of the two drives mid-transfer — usually the source. Reconnecting and retrying blindly is how people corrupt folders.

Check both drives are still visible. Open File Explorer. If the source drive dropped off, you'll see it missing from This PC. If both are still listed, right-click each one and pick Properties to confirm Windows still sees them.
Reconnect the flaky drive. If it's USB, unplug it, wait ten seconds, plug it back into a different port — ideally one directly on the motherboard, not a hub or front-panel header.
Copy, don't move. This is the big one. For the retry, use copy. Move operations delete the source as they go. If the drive vanishes halfway through a move, you've got data in limbo. Copy leaves the source intact until the whole thing finishes.
Use Robocopy for anything big. Explorer's copy dialog is fragile. Robocopy retries on failure and can resume. From an admin Command Prompt:

robocopy "D:\Source" "E:\Destination" /E /COPY:DAT /R:3 /W:5 /LOG:C:\temp\copy.log

That copies everything including subfolders, retries three times with a five-second wait between attempts, and logs the whole thing so you can see what broke.

Check the drive health. If this happens more than once on the same drive, it's dying. Run:

chkdsk D: /f /r

Swap D: for whichever drive is misbehaving. Then pull the S.M.A.R.T. data with CrystalDiskInfo or the manufacturer's utility. Reallocated sectors or pending sectors are a warning shot. Back up immediately.

Why this actually works

STATUS_NOT_SAME_DEVICE is a Windows kernel-level status code, not a filesystem error. It fires when a file operation expects two handles that point to the same device, but one handle now points somewhere else — or nowhere. During a move, Windows opens the source file, creates the destination file, streams bytes across, then deletes the source. If the source drive disappears mid-stream, the handle goes stale and Windows can't reconcile the two paths. Same error can appear if a drive letter gets reassigned by another device, a card reader, or a VM mounting the same volume.

Copy avoids the delete-the-source step, so a dropped drive just means a partial copy you can rerun. Robocopy bypasses Explorer's copy engine entirely and handles transient I/O failures without throwing the whole operation away. Checking drive health matters because the root cause is often physical — a cheap USB-SATA bridge chip overheating, a failing spindle, or a cable with a damaged connector.

Had a client last month whose entire print queue died because of this. Same error code, different symptom. Their print spooler folder was on a USB drive that kept dropping off the bus. Spooler couldn't write the job file, threw 0xC00000D4, and queued jobs piled up until nothing would print. Moving the spool folder to C: and replacing the drive fixed it in ten minutes.

Less common variations

Drive letter collision

If you map a network share or plug in a USB stick that Windows assigns the same letter as an existing drive, file operations can flip mid-transfer. Open Disk Management (diskmgmt.msc) and give every drive a letter far from the ones you use for removable media. I keep network shares on M: through P: for exactly this reason.

Failing USB-SATA bridge

Enclosures with the JMicron JMS578 or older ASMedia chipsets drop off the bus under sustained writes. Symptom: transfers die at roughly the same size every time, then the drive reappears. Pull the drive out and connect it via a direct SATA cable. If the error vanishes, the bridge was the problem.

BitLocker or third-party encryption mid-move

Moving files between a BitLocker volume and an unencrypted one can trip this error if the encryption driver stalls. Unlock both volumes first, wait for the padlock icon to clear in Explorer, then retry.

Virtual machine shared folders

VMware and VirtualBox shared folders love to throw 0xC00000D4 when the host drive re-enumerates. Mount the source as a real network share or a mapped drive instead of using the shared folder feature. It's slower but it doesn't randomly lose its handle.

Rogue drive-letter assignment

Some backup software, game launchers, and imaging tools mount VHDs and ISOs on the fly and steal free letters. Check Task Manager for anything mounting volumes, and quit it before big transfers.

Prevention

Copy, verify, then delete. Never use Move for anything important. Copy first. Confirm the destination is complete. Then delete the source manually.
Direct ports only. No hubs, no front-panel USB headers, no daisy chains. Rear I/O ports straight off the motherboard.
Decent cables and enclosures. The free cable in the box is why this error exists. StarTech and Sabrent enclosures with ASM1153E or JMS578 chipsets (the good revisions) hold up better than no-name Amazon specials.
Watch S.M.A.R.T. monthly. CrystalDiskInfo set to run at startup and alert on warnings. Ten seconds of attention beats a failed drive.
Use Robocopy or TeraCopy for anything over a few GB. Explorer's copy is fine for a Word doc. It's a liability for a 200 GB video archive.
Back up before you move. If the data only exists in one place and you're about to relocate it, that's the riskiest moment in its life. Copy to the destination first, keep the source until you're sure.

Most people hit 0xC00000D4 once, panic, retry, and get lucky. The ones who hit it twice are running a dying drive or a garbage USB enclosure. Treat it as a warning, not a one-off glitch.