0xC00002CA Fix: Transport Element Full in Tape Library

Quick answer for pros: run changer list in ntbackup or wbadmin to see which element is busy, then use changer move to force the robot to drop the tape into a slot. If that fails, power-cycle the library.

What actually triggers this error

STATUS_TRANSPORT_FULL (0xC00002CA) shows up when the tape library's robotic arm—the picker—is already holding a cartridge and the backup software tries to move another tape into the drive. Think of it like a vending machine where the robot arm is stuck in the middle of a transaction. The backup job fails, and you see this error in the Windows event log or in whatever backup app you're using (Veeam, Backup Exec, Windows Server Backup).

This usually happens after a failed backup job that didn't cleanly release the tape. Maybe the server crashed, a network drop killed the connection, or the tape drive timed out. I had a client last month whose entire print queue died because of this—turned out a dangling tape in the picker was blocking all subsequent backups for three days. The library looked fine from the front panel, but the robot arm was holding a tape from a job that had aborted mid-transport.

Step-by-step fix — clear the stuck transport

Open the tape library's management interface. Get into the web UI or front panel. Look for a status display showing the robot arm position. Most modern libraries (HP MSL, IBM TS, Dell PowerVault) show this as \"picker status\" or \"transport element.\"
Check which slot or drive has the tape stuck in transport. On the front panel, there's typically a \"move media\" or \"inventory\" option. Hit \"inventory\" to map every slot and drive. If you see a tape listed as \"in transport\" (sometimes labeled \"picker\" or \"robotic arm\"), that's the culprit.
Force the robot to drop the tape into an empty slot. Use the library's manual move command: select the stuck tape, pick a destination slot that's definitely empty (check the inventory first), and tell the robot to move it there. If the library supports it, a \"home\" or \"park\" command will also work—the robot will drop the tape into its default slot.
If the UI won't let you move it, power-cycle the library. Turn it off, wait 30 seconds, turn it back on. Most libraries run a self-test on boot and will automatically retract the tape from the picker into a slot. This fixes about 80% of stuck-transport issues. I've seen an IBM TS3200 do exactly this after a firmware panic left the arm frozen.
After power cycle, run a full inventory. In Windows, open a command prompt as admin and run:
```
wbadmin get disk
```
If you're using the old ntbackup tool (still on some legacy servers), run:
```
ntbackup changer /List
```
This will show you the tape library's current state. Verify no elements show as \"transport full.\"
Restart the backup service. For Windows Server Backup, restart the Windows Backup service. For third-party apps like Veeam or Backup Exec, restart that service too. Then try a test backup to a known-good tape.

Alternative fixes if the main steps don't clear it

Use the tape library's debug or maintenance mode. Some libraries (like the HP MSL G3 series) have a hidden menu accessed by holding the \"OK\" button during boot. From there, you can issue a direct \"release picker\" command. Check your vendor's manual for the exact sequence.
Physically inspect the library. Open the door (if it's safe—some libraries have interlocks that stop the robot). Look for a tape jammed in the picker assembly. I've seen a bent guide pin catch a cartridge and prevent it from seating properly. Gently nudge the tape free. Do this with the power off unless you're sure the robot won't move.
Update firmware. If this error keeps happening after clearing, the library firmware might have a bug. Check your vendor's support site. An old HP MSL4048 I dealt with had a known issue where the picker would hang after a failed SCSI command—firmware 4.20 fixed it.
On Windows Server, disable and re-enable the medium changer device. Open Device Manager, find \"Medium Changer Devices\" or \"Changer Device\" under your tape drive. Right-click, disable, then re-enable it. This resets the kernel-mode driver state without a reboot. I've seen this work when the transport flag gets stuck in memory.

How to avoid this happening again

This error is usually a symptom of a dirty shutdown or a hung backup job. Here's what I tell my clients:

Never kill a backup job manually. Use the software's cancel function. If you have to force-kill the process, expect the library to be in a weird state. Always run a library inventory after an abrupt interruption.
Set your backup software to perform a pre-job library inventory. In Veeam, check \"Rescan tape library before job.\" In Backup Exec, enable \"Inventory changer at job start.\" This catches stuck tapes before the job starts.
Schedule a weekly library cleaning. Most libraries have a dedicated cleaning slot. A dirty drive can cause tape stickiness that jams the picker.
Keep the firmware up to date. Tape library vendors release firmware updates specifically to fix transport bugs. Set a calendar reminder to check every six months.

Real-world story: I had a client with an HP MSL2024 that threw 0xC00002CA every Tuesday at 3 AM for three weeks. Turns out a scheduled virus scan was hitting the backup server right as the backup job was trying to eject a tape. The CPU spike caused the backup service to timeout and leave the picker half-open. We moved the scan to a different time and never saw the error again.

The bottom line: STATUS_TRANSPORT_FULL is almost always a stuck robot arm. Clear it via the library UI or power cycle, and you'll be back in business in five minutes. If it keeps happening, look at your backup job timing and library firmware—it's rarely a hardware failure.