How can I debug NTFS corruption that occurs after successful eject?

Lately when I write to an external drive formatted as NTFS* and then eject it, and wait a full minute before un-powering, then upon re-powering it won't auto-mount and manual mount attempts give an error. It wasn't like this before as it started around 2 months ago. An Ext4-formatted drive doesn't have this problem, and can even be hot-unplugged without issues (discovered by having a bad dock). Log excerpt: (Important point: $MFTMirr does not match $MFT)

Mar 10 14:42:39 confucius kernel: usb 4-1.1: new SuperSpeed USB device number 10 using xhci_hcd
Mar 10 14:42:39 confucius kernel: usb 4-1.1: New USB device found, idVendor=1058, idProduct=107c, bcdDevice=10.42
Mar 10 14:42:39 confucius kernel: usb 4-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
Mar 10 14:42:39 confucius kernel: usb 4-1.1: Product: Elements 107C
Mar 10 14:42:39 confucius kernel: usb 4-1.1: Manufacturer: Western Digital
Mar 10 14:42:39 confucius kernel: usb 4-1.1: SerialNumber: 574343344E30353730323533
Mar 10 14:42:39 confucius kernel: usb-storage 4-1.1:1.0: USB Mass Storage device detected
Mar 10 14:42:39 confucius kernel: scsi host5: usb-storage 4-1.1:1.0
Mar 10 14:42:39 confucius mtp-probe: checking bus 4, device 10: "/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/usb4/4-1/4-1.1"
Mar 10 14:42:39 confucius mtp-probe: bus: 4, device: 10 was not an MTP device
Mar 10 14:42:39 confucius mtp-probe: checking bus 4, device 10: "/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/usb4/4-1/4-1.1"
Mar 10 14:42:39 confucius mtp-probe: bus: 4, device: 10 was not an MTP device
Mar 10 14:42:40 confucius kernel: scsi 5:0:0:0: Direct-Access     WD       Elements 107C    1042 PQ: 0 ANSI: 6
Mar 10 14:42:40 confucius kernel: sd 5:0:0:0: Attached scsi generic sg4 type 0
Mar 10 14:42:40 confucius kernel: sd 5:0:0:0: [sdd] Spinning up disk...
Mar 10 14:42:49 confucius kernel: .........ready
Mar 10 14:42:49 confucius kernel: sd 5:0:0:0: [sdd] 732558336 4096-byte logical blocks: (3.00 TB/2.73 TiB)
Mar 10 14:42:49 confucius kernel: sd 5:0:0:0: [sdd] Write Protect is off
Mar 10 14:42:49 confucius kernel: sd 5:0:0:0: [sdd] No Caching mode page found
Mar 10 14:42:49 confucius kernel: sd 5:0:0:0: [sdd] Assuming drive cache: write through
Mar 10 14:42:49 confucius kernel: sdd: sdd1
Mar 10 14:42:49 confucius kernel: sd 5:0:0:0: [sdd] Attached SCSI disk
Mar 10 14:42:50 confucius kernel: ntfs3: Max link count 4000
Mar 10 14:42:50 confucius kernel: ntfs3: Enabled Linux POSIX ACLs support
Mar 10 14:42:50 confucius kernel: ntfs3: Read-only LZX/Xpress compression included
Mar 10 14:43:05 confucius kernel: ntfs3: sdd1: volume is dirty and "force" flag is not set!
Mar 10 14:43:05 confucius udisksd: $MFTMirr does not match $MFT (record 3).
Mar 10 14:43:05 confucius udisksd: Failed to mount '/dev/sdd1': Input/output error
Mar 10 14:43:05 confucius udisksd: NTFS is either inconsistent, or there is a hardware fault, or it's a
Mar 10 14:43:05 confucius udisksd: SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
Mar 10 14:43:05 confucius udisksd: then reboot into Windows twice. The usage of the /f parameter is very
Mar 10 14:43:05 confucius udisksd: important! If the device is a SoftRAID/FakeRAID then first activate
Mar 10 14:43:05 confucius udisksd: it and mount a different device under the /dev/mapper/ directory, (e.g.
Mar 10 14:43:05 confucius udisksd: /dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
Mar 10 14:43:05 confucius udisksd: for more details.

Doing a disk check in Windows takes very long, I think in the order of 5 hours. This isn't a workable situation for us. Is there a way that I can troubleshoot this error in a reasonable manner (not taking 5 hours each time), or a way to just fix this by discarding/ignoring one of the $MFT? * drive shares data with Windows PCs --- Nemo has auto-mounting enabled. I eject with the eject button in Nemo (i.e. not umount)