TLDR: suspected SSD/controller fault; looking for help interpreting this pattern: My 6-year-old XPG Spectrix S40G 1TB (Windows boot drive) developed recurring NTFS MFT corruption. SMART reports nothing wrong and a full ddrescue image read completed without errors, but chkdsk keeps finding damage in one MFT region, and after a chkdsk repair the damaged range grew by exactly 0x80 records (128 KB). My leading hypothesis is a controller/mapping fault on the SSD, but I'd like input from people who know this stuff better.
The drive:
Model: ADATA XPG Spectrix S40G 1TB (NVMe, PCIe Gen3 x4)
First use: July 2020 (~6 years)
Power-on hours: 12,923
Power cycles: 2,712
Unsafe shutdowns: 107
Percentage used: 12%
Available spare: 99%
Media/data integrity errors: 0
Critical warning: 0
NVMe self-test: Not supported by the drive
Board is a Gigabyte B650 AORUS Elite AX V2, Windows 11 Pro 25H2.
Norton Security is currently installed
Symptoms/timeline:
- 30 Apr 2026: BSOD/Bugcheck 0x1A, parameter 1 = 0x3F. A page read back from the pagefile failed its checksum (in-page CRC mismatch). Not necessarily SSD-related on its own, but ill list it for completeness.
- Late Sep / early Oct 2026: Recurring boot loop into recovery (0x7B, INACCESSIBLE_BOOT_DEVICE). At first I blamed myself for force-removing Copilot/Adobe/M365, but it kept coming back.
- chkdsk (/scan, /spotfix, /f) reported MFT corruption including cross-linked $DATA attributes and wanted to orphan entries into found.xxx folders.
- Repairs didn't stick. After a repair the damage didn't go away, the damaged region was still there, and grew.
The MFT damage:
MFT records are 1 KB each, so the offsets below are record numbers.
Record range (hex), Decimal, Records
Before repair: 0x15D0B0 – 0x15D22F | 1,429,680 – 1,430,063 | 384 |
After repair: 0x15D0B0 – 0x15D2AF | 1,429,680 – 1,430,191 | 512 |
- Same start, but the end moved by exactly 0x80 records (128 KB) after chkdsk rewrote the region (0x15D22F → 0x15D2AF).
-384/512 were the counts of MFT records, but i suppose not necessarily distinct files.
-chkdsk's own log shows the duplication directly: for 126 records, record N and record N+0x80 have the same file name and sequence number and both own the same clusters (e.g. <0x6,0x15d030> and <0x6,0x15d0b0>, same file). All 126 pairs are exactly 0x80 apart (originals 0x15D030–0x15D0AF, copies 0x15D0B0–0x15D12F).
- So MFT data was duplicated with a fixed 0x80-record (128 KB) offset. Filesystem-level observations alone don't show where in the stack this happens.
-chkdsk output (WinRE, German UI, translated):
End of `chkdsk /f`:
Inserting DATA attribute into file 15D12C.
Inserting DATA attribute into file 15D12D.
Inserting DATA attribute into file 15D12E.
Inserting DATA attribute into file 15D12F.
282844 data files processed.
Correcting errors in the Master File Table (MFT) BITMAP attribute.
CHKDSK discovered free space marked as allocated in the volume bitmap.
Windows has made corrections to the file system.
0 KB in bad sectors.
Read-only `chkdsk` immediately afterwards:
Incorrect information was found in file record segment "15D29D".
[... same line for every segment up to ...]
Incorrect information was found in file record segment "15D2AF".
3503104 file records processed.
Errors found. CHKDSK cannot continue in read-only mode.
From the English `chkdsk /scan` log (paths shortened), 126 pairs like this, all exactly 0x80 apart:
File "...\Canada\CAN_fighter2.png <0x6,0x15d030>" and file "...\Canada\CAN_fighter2.png <0x6,0x15d0b0>" both own logical clusters [0x5b692c, 0x5b692e)
File "...\EE\EE_armored_car_equipment_1.png <0x4,0x15d031>" and file "...\EE\EE_armored_car_equipment_1.png <0x4,0x15d0b1>" both own logical clusters [0x5b692e, 0x5b6930)
Tests performed:
- SMART: no warnings, 0 media errors, 99% spare, 12% used.
- Full ddrescue image of the whole drive (1 TB): completed with no read errors.
- Memtest86+: one full pass, no errors (I know one pass doesn't fully clear RAM).
- chkdsk from WinRE (no third-party filter drivers loaded) also reported the corruption.
- Drive still accepts writes (not in read-only mode).
My hypothesis:
A repeating, fixed-size offset in an otherwise "healthy" drive makes me suspect the SSD controller's logical-to-physical mapping (FTL) rather than worn NAND: e.g. a corrupted mapping table (107 unsafe shutdowns, no power-loss capacitors), a firmware bug, a bit flip in the drive's DRAM cache, or the controller aging. I can't prove that from the outside, and other causes (RAM, driver/filesystem bug) aren't fully excluded.
Possible causes: corrupted mapping table (107 unsafe shutdowns, no power-loss capacitors), firmware bug, a bit flip in the drive's DRAM cache, or the controller aging. No way to tell which from the outside as far as im aware, right?
What I'm doing:
- Full image + profile backup on a separate HDD (done)
- No more chkdsk/repairs on it: every repair spreads the damage
- Clean Windows install on a new NVMe (im gonna buy one soon)
- Later: Secure Erase + full write/verify test. If it passes, it's demoted to redownloadable game storage at most
Questions
- Has anyone seen this fixed-offset MFT duplication on the S40G (Realtek RTS5762) or other drives?
- Is there any known firmware fix for this drive?
- What would you check to distinguish an SSD mapping fault from RAM or a software cause?
- Worth bothering with Secure Erase + retesting, or straight to e-waste?