You plug in the external drive that’s worked for years, double-click it in Explorer, and get: “D:\ is not accessible. The parameter is incorrect.” The drive is right there — it has a letter, it shows in Disk Management, Windows clearly sees it — but every attempt to open it produces the same blank, bureaucratic refusal. Or the error appears mid-operation instead: a file copy dies with it, a folder throws it while opening, a backup logs it against one specific path.

“The parameter is incorrect” (error 0x80070057) may be the least informative message Windows produces about a storage problem, because it isn’t a storage message at all — it’s a generic failure code, the operating system’s equivalent of a shrug, returned whenever a deeper operation fails in a way nothing bothered to translate. When it appears against a drive or a file operation, something real failed underneath: usually filesystem metadata that Windows tried to parse and couldn’t, sometimes hardware that returned garbage, occasionally something as mundane as a bad cable. The error doesn’t tell you which. This page does.

What’s usually behind it

Corrupted filesystem metadata — the most common cause on a drive that won’t open. When Windows mounts an NTFS volume, it reads the boot sector for the volume geometry, then walks into the Master File Table to find the volume’s structures. If what it reads is internally inconsistent — a boot sector with impossible values, an MFT whose critical records don’t parse — the mount fails, and the failure frequently surfaces as this error. It’s a close cousin of the volume showing as RAW; which message you get depends on where in the parsing Windows gave up. The causes are the usual suspects from our NTFS deep-dive: unclean removal of an external drive mid-write (write caching makes unplug-without-eject a real risk, not a nagging myth), power loss during writes, and bad sectors landing on metadata structures.

A failing drive returning unreadable or wrong data. Sometimes the metadata isn’t corrupt on the platters — the drive just can’t deliver it. Sectors that read intermittently, a head that’s degrading, a USB bridge garbling transfers: Windows receives something that doesn’t parse and reports the same error. The tell is company: slowness, clicking or buzzing, the drive disappearing and reappearing, the error alternating with I/O device errors or CRC errors on different attempts. Any of those alongside “the parameter is incorrect” reclassifies the situation as a hardware case, and the priority becomes getting the drive imaged before further use — not fixing the filesystem it can’t reliably present.

The enclosure, cable, or port — the causes worth eliminating first. A marginal USB cable, an underpowered port, or a failing USB-to-SATA bridge in the enclosure can corrupt the conversation between Windows and a perfectly healthy drive. Before assuming the worst: different cable, different port (rear motherboard ports beat front-panel and hub ports), and — if you’re comfortable — the bare drive tested outside its enclosure. One caveat on that last step: many WD external drives hardware-encrypt data through the bridge board, so a shucked WD drive showing unreadable contents in another enclosure may be encryption, not damage — a wrinkle covered on our WD external drive page.

The narrow, fixable oddities. A small share of cases are genuine parameter problems: a volume formatted with an exotic cluster size an old system can’t handle, a drive from a very old system with a nonstandard partition layout, timestamp edge cases hit during copies between filesystems (FAT32’s date limits, most famously). These tend to announce themselves by context — the error appears only against one operation or one destination, while the volume otherwise behaves — and they’re configuration problems, not data loss.

The triage, in order

• 1. Eliminate the path. Different cable, different port, no hub. If the error vanishes, it was never the drive.
• 2. Listen and watch. New noises, slowness, disappearing/reappearing, other errors mixed in? Hardware case — stop here and skip to the last section. A drive with failing hardware should not be troubleshot further while it holds the only copy of anything.
• 3. Check Disk Management. If the volume now shows RAW where it said NTFS, or the drive shows “unknown, not initialized,” the filesystem metadata is the problem — and the data behind it is typically intact. Decline any offer to initialize or format.
• 4. Resist chkdsk — at least for now. This is the step where most people reach for chkdsk /f, and on a healthy drive with trivial corruption it sometimes works. But chkdsk repairs by discarding what it can’t reconcile, writes its changes irreversibly, and cannot tell a corrupt volume from a failing drive presenting one. If the volume matters and the damage is more than cosmetic, chkdsk converts a recoverable situation into a salvage job — the full argument is on the NTFS page. Run it only on data you could afford to lose, or after the drive has been imaged.

If the data matters

The version of this error that brings drives to our lab is steps 2 and 3: a drive with hardware symptoms, or a volume whose metadata damage goes deeper than a boot-sector fix. The recovery path is the standard one — image the drive on hardware built for failing media, then reconstruct the NTFS structures against the image, using the volume’s own redundancy (backup boot sector, MFT mirror, the per-file records that survive directory damage) or full metadata scanning when the damage is extensive. Outcomes on this error family are generally good, provided the drive arrives before repeated mount attempts, chkdsk passes, and recovery-software scans have worked it over.

Single-drive cases — which is nearly all of them — fit our standard risk-free model: free evaluation, flat-rate quote in writing before any work, payment only on successful recovery. And if your situation is the good kind — a cable, an enclosure, a settings quirk — the free consultation will tell you that too, and cost you nothing.