Fix STATUS_DESTINATION_ELEMENT_FULL 0XC0000284

Quick answer: The medium changer was told to move media into a destination element (slot, drive, or import/export station) that already reports media present — clear the slot or resync inventory, then retry the move.

This is an NTSTATUS code, not a Windows dialog box error. It surfaces in Backup Exec, Veeam, Arcserve, IBM Spectrum Protect, Veritas NetBackup, or whatever's driving your library — usually buried in job logs or the Removable Storage Manager event log. The value 0XC0000284 is STATUS_DESTINATION_ELEMENT_FULL. A medium changer (the robotic arm inside a tape library) got a MOVE MEDIUM command with a destination element address that its own inventory says is occupied. The robot refuses because it can't stack two cartridges in one slot. That's the whole story.

I've seen this pop up most often right after someone swaps tapes by hand and forgets to run a library inventory, or after a failed move left the changer's internal slot map out of sync with physical reality. It also shows up when a cleaning tape gets parked in a slot your backup software thinks is empty, or when an archive job tries to dump a tape into a slot that's still holding last week's full backup. Compaq/HP MSL, IBM TS3xxx, Quantum Scalar i40/i80, and Dell ML3 libraries all throw it — the vendor doesn't matter, the element map does.

Before you touch anything

Stop the backup service or pause the job. Any move in flight will fight you. On Windows, the culprits are usually:

Removable Storage Manager (RSM) — disable the service if you're using vendor software that has its own changer driver. Run services.msc, find Removable Storage, set Startup type to Disabled, reboot.
Vendor service — Backup Exec's Backup Exec Device & Media Service or Veeam's Veeam Tape Service. Stop both, not one.

Step-by-step fix

Identify the destination element address. The error log will list a destination element — often a decimal like 1031 or a hex like 0x407. Write it down. In Backup Exec, check Tools > Devices > tape library > Slots. In IBM's ITDT or the library web UI, look at the element address map.
Physically look at that slot. Open the library's front door (on most MSL and Scalar units you press the unlock button, and the magazine pops out). Find the slot matching the address. I'll bet you a coffee there's a cartridge sitting in it. If it's a mail slot or I/E station, same story.
Decide: clear it or redirect the job. If the tape in that slot isn't needed, pull it out and put it somewhere safe. If it is needed, change your job's destination slot in the software — don't try to force the move.
Run a full library inventory. This is the step people skip and then wonder why the error comes back. In Backup Exec: Devices > right-click library > Inventory. In Veeam: Tape Infrastructure > right-click library > Inventory. In IBM ITDT: itdt -f /dev/sg2 inventory (device path varies).
Watch the inventory complete. You should see a status of Success and a slot count that matches the physical cartridge count. If the numbers disagree, the changer's barcode reader missed a label — clean or replace the label and rerun.
Retry the move. Kick off the job again. It should now succeed. If it fails with the same 0XC0000284, jump to the alternative fixes below.

Alternative fixes when the slot already looks empty

If the slot is physically empty but the software still insists it's full, the changer's internal element map is stuck. Try these in order:

Power-cycle the library. Not the server — the library itself. Pull the power, wait 30 seconds, plug back in, wait for the POST to finish (usually 2–3 minutes on larger units), then rerun inventory.
Move the tape out via the changer, not by hand. Use the vendor tool to eject the offending cartridge to the I/E station. That forces the changer to update its element status.
Reset the changer driver. In Device Manager, expand Medium Changers, right-click the library, choose Uninstall device, then Scan for hardware changes. Reboot to be safe.
Check the vendor's element address map. Some libraries reserve slot 0 or the last slot for a cleaning tape. If your software tries to use that slot for user data, you'll hit this error every time. Adjust the slot range in the backup software.
Update the library firmware. IBM TS4300 firmware below 5.2.0 and older HP MSL 2024 firmware had inventory bugs that produced phantom "full" slots after a failed move. Check the vendor's download page.

Prevention

The real fix is process, not software. Every time someone opens the library door — for a tape swap, a cleaning cartridge, anything — run a full inventory before the next backup window. Tape it to the inside of the door if you have to. And if you're scripting jobs, add a pre-flight inventory call before any MOVE MEDIUM. It costs a few minutes and saves you from explaining to your boss why the Friday night full backup failed at 2 a.m.

One more thing: if you're still running RSM on a modern Windows Server (2016 or later), turn it off. RSM hasn't been meaningfully updated in over a decade and fights with every vendor's changer driver. Disable it and let the backup software own the library exclusively.