When this error shows up
You're running a backup job, maybe with NTBackup or a modern tool like Veeam. The first tape fills up. The software asks you to insert tape 2. You swap tapes, press OK, and then bam — STATUS_INVALID_BLOCK_LENGTH (0xC0000173). The job dies. Or it happens on restore: you load the first tape fine, but when you load the second, the drive refuses.
What's actually happening here
The tape drive remembers the block size from the previous tape. When you insert a new tape (or a different volume in a set), the drive still expects data in the old block size. The new tape might use a different block size — or the drive just didn't reset. Windows throws 0xC0000173 because the block length in the request doesn't match what the drive has cached.
On older SCSI tape drives (like HP DAT, IBM LTO-1/2/3), this is common. Modern LTO-5+ handle it better, but still can trip up if the backup software doesn't send a proper MODE SENSE command between tapes.
The fix — reset the blocksize
The real fix is to force the drive to re-read the block size from the tape. Skip the GUI tools — they often hide this. Use the command line.
Step 1: Find your tape device path
Open an admin command prompt and run:
wmic tape drive get name, deviceidLook for something like \\.\TAPE0 or TAPE1. Write that down.
Step 2: Use tapeinfo to check current block size
If you have mt (from Windows Server backup tools or a freeware package) or tapeinfo, run:
tapeinfo -f \\.\TAPE0Look for "Block size" in the output. If it shows 0 (variable) or some fixed number like 1024, that's your problem.
Step 3: Reset the block size
Tell the drive to use variable block size (most common for backup tapes):
mt -f \\.\TAPE0 setblk 0The number after setblk is the block size in bytes. 0 means variable — the drive negotiates with the tape. This fixes most cases. For fixed-block tapes (like old QIC drives), you'd put the exact size (e.g., 1024).
Step 4: Verify the change
tapeinfo -f \\.\TAPE0 | findstr BlockShould now show "Block size: 0" (or whatever you set).
Step 5: Retry your backup/restore
Don't close the command window. Start your backup software again and try the operation. If it still fails, go to What to check if it still fails below.
Why step 3 works
The drive stores the block size in its internal state. When you change tapes, the drive doesn't automatically clear that state — it's a design quirk of SCSI tape drives. By setting block size to 0, you force a MODE SELECT command that resets the cache. The next read/write triggers a MODE SENSE, and the drive picks up the correct block size from the tape's media header.
What to check if it still fails
- Driver: Update the tape device driver. On Windows 10/11 and Server 2016+, old driver stack can cause this. Go to Device Manager, find your tape drive under Tape drives, right-click, Update driver.
- Firmware: Check the manufacturer's site (HP, IBM, Quantum) for firmware updates. I've seen LTO-4 drives hang on block size after firmware version 1.20 or older.
- Backup software config: Some apps like Backup Exec have a "Logical Block Size" override. Set it to 0 (auto) or match your tape media.
- SCSI cable or HBA: Loose termination on an external SCSI chain can corrupt mode page requests. Reseat cables, check termination.
- Tape itself: Rare, but a damaged tape header can report wrong block size. Try a different tape from the same set.
Pro tip for regular backups
If this keeps happening, add the mt setblk 0 command to your backup script before every tape change. Most backup software has a pre-tape-change script hook. Use it. It's a band-aid, but it works until you replace the drive.