STATUS_SOURCE_ELEMENT_EMPTY (0xC0000283) Fix
This error hits when a backup or tape migration tool asks a medium changer to pull media from a slot that's already empty. The fix is usually a slot remap or driver update.
When this error hits
You're running a backup job — maybe with Backup Exec, Veeam, or native Windows Backup — and it fails with STATUS_SOURCE_ELEMENT_EMPTY (0xC0000283). The job log shows the medium changer (the robot arm inside a tape library) tried to pick a tape from a specific slot, but nothing was there. This usually happens after someone manually removed a tape without updating the library's inventory, or after a slot mapping got corrupted.
What's actually happening here
Modern tape libraries use a SCSI medium changer element that maps physical slots, drives, and import/export ports. Each slot has an element address. When backup software requests a tape by barcode or slot number, the changer's firmware validates the slot has media before moving it. If the slot is empty — because a tape was ejected, the slot was never loaded, or the inventory is stale — the firmware returns 0xC0000283. Windows translates this to the STATUS_SOURCE_ELEMENT_EMPTY error you see.
The root cause is almost always a mismatch between the logical inventory the software holds and the physical contents of the library. The library itself hasn't failed; it's just telling you honestly: "There's nothing in slot 17, boss."
The fix — step by step
1. Rescan the library inventory
Open your backup software's device management panel. Find the medium changer device and trigger an inventory rescan. In Backup Exec, that's under Devices > right-click changer > Inventory. In Veeam, it's Inventory > Tape Infrastructure > Rescan.
Let it scan all slots. This forces the changer to report what's actually in each slot. If the tape was just misplaced or the inventory was stale, this alone often clears the error.
2. Check for slot mapping corruption
If the rescan shows empty slots where you know tapes exist, the slot-to-element mapping is broken. The library's internal element addressing might have shifted — rare, but happens after a firmware update or hardware reset.
Run the following command from an elevated Command Prompt to query the changer directly:
chkntfs /? (not helpful here — use mchanger or a vendor tool instead)Better: download mchanger from the Windows Driver Kit, or use your library vendor's diagnostic tool (e.g., IBM Tape Library Diagnostic Tool, Quantum iLayer, HP Library & Tape Tools). Run an element scan:
mchanger -e -l 0This lists all element addresses and their status. Look for slots that show Empty when they should have media. If you find one, note the element address.
3. Force a re-inventory via the front panel
Go to the tape library's front panel LCD or web interface. Find the Inventory or Scan Slots option. Run a full inventory from hardware. This bypasses any cached data in the backup software.
On many Quantum and HP libraries, you need to hold the Menu button for 5 seconds, navigate to System > Inventory > Run. This forces the robot arm to physically sweep every slot and record what's there.
4. Update the firmware on the changer
If slot mapping keeps shifting, you've got a firmware bug. Check the library model and current firmware version against the vendor's release notes. Look for any fix that mentions "element addressing" or "slot inventory."
Download the latest firmware from the vendor's support site. Apply it following their instructions — usually via a TFTP update or a USB stick on the library's control card. After update, reboot the library and run inventory again.
5. Manually move the tape to a known slot
When all else fails and you have a tape stuck in a slot that the library insists is empty, physically remove that tape and re-insert it into a different slot. This forces the library to re-recognize its barcode. After insertion, run the inventory from the front panel. Then update the backup software's media database to point to the new slot.
If it still fails
Check two things. First, the SCSI cable or fiber channel link between the library and your server. A flaky connection can cause the changer to report stale data. Swap the cable if you can. Second, look at the Windows Device Manager: under Medium Changer Devices, does the driver show a yellow exclamation? Right-click and update the driver, or reinstall it from the vendor's package. If that doesn't fix it, the library's robot mechanism might have a mechanical issue — the arm's position sensor is miscalibrated. That's a call to the vendor's support for a calibration tape or hardware service.
Was this solution helpful?