Fix ERROR_LOG_SECTOR_REMAPPED (0x000019CA) on Windows Server

You're running a file server or maybe a domain controller, and suddenly the event log lights up with ERROR_LOG_SECTOR_REMAPPED (0x000019CA). The log service choked because a sector on the disk — where it writes transaction logs — got marked as bad and remapped by the disk firmware. I've seen this most often on aging SATA drives in Dell PowerEdge servers running Windows Server 2016 or 2019, especially after a sudden power loss or during a heavy write load. One client had it happen right after a UPS failure took down their Hyper-V host. The disk didn't fail outright, but the log service couldn't write to that spot anymore.

What's actually happening?

The NTFS file system uses a log file (usually $LogFile) to track metadata changes — think file creates, deletes, security changes. If the disk has a bad sector in the middle of that log area, the hard drive's firmware remaps it to a spare sector. That's a normal error-recovery process. But the log service doesn't like that. It sees the remap and throws 0x000019CA to tell you: "Hey, the underlying hardware is degrading." It's not just a random glitch — it's a warning that your disk or file system is starting to fail.

Don't ignore this. That remapped sector is one of a limited pool. If more go bad, you're looking at a full disk failure or file system corruption.

What you need to fix it

Here's the plan — step-by-step, no fluff. Start with the disk health check, then repair the file system, then verify.

Step 1: Check the disk's SMART status

1. Open Command Prompt as Administrator.
2. Run wmic diskdrive get status, model, serialnumber.
3. If any drive shows Bad, replace it immediately. Don't bother fixing the log — the drive is toast. I had a client last month whose RAID 5 array had one drive showing Pred Fail. They replaced it, and the error disappeared.
4. For a deeper check, download GSmartControl or use fsutil dirty query c: to check if the volume is flagged dirty.

Step 2: Run a full chkdsk

1. Open Command Prompt as Administrator.
2. Run chkdsk c: /f /r /x. The /r flag locates bad sectors and recovers readable data. The /x forces the volume to dismount first — needed if the disk is in use (like on a live server).
3. It'll ask if you want to schedule it at next reboot. Type Y and restart the server. Yes, this means downtime. Plan for it.
4. After reboot, chkdsk runs in three phases. Phase 1 checks files, Phase 2 checks indexes, Phase 3 look for bad sectors. Let it finish — this can take hours on large drives.

Note: If chkdsk hangs or throws errors like "Unable to write to $LogFile," you've got deeper corruption. I'd then boot from a Windows Server installation media and run chkdsk /f from the recovery environment.

Step 3: Verify the log file is clean

1. After chkdsk completes, run fsutil dirty query c: to confirm the dirty bit is cleared.
2. Open Event Viewer → Windows Logs → System. Look for any new 0x000019CA errors. If none, you're good.
3. To be thorough, run chkntfs c: — it shows if chkdsk is pending. If it's scheduled again, something's still off.

Step 4: If the error persists, check for hardware issues

1. Open the server's hardware management console (iDRAC, iLO, or whatever your brand uses). Check the storage logs for reallocated sectors or pending clusters.
2. Run a non-destructive disk test — usually called "Long S.M.A.R.T. test" or "Conveyance test" — from the RAID controller. If it fails, replace the drive.
3. If you're on a RAID array, also update the RAID firmware and driver. I once saw 0x000019CA on a Dell PERC H730P because of a known firmware bug with reallocated sector reporting.

What if it still fails after all this?

If the error comes back after chkdsk and hardware tests pass without issues, you might be looking at a failing RAID controller or a bad backplane. I'd run a memory test too — faulty RAM can corrupt disk writes in flight and trigger phantom remap events. Swap the drive to a different slot on the backplane if possible. If that clears it, the slot itself is bad.

One last thing: if you're running Hyper-V or SQL Server on that volume, also run repair-bde or a database consistency check — the log corruption could have spread to application data. Don't assume chkdsk fixed everything.

Bottom line: 0x000019CA is your server waving a yellow flag. Treat it seriously. Replace failing drives early, keep backups, and don't skip the SMART checks.