Repair a boot failure that names ntfs.sys and displays 0xc0000098

Windows Recovery identifies \Windows\System32\drivers\ntfs.sys as missing, invalid, corrupt, or unverified, often with 0xc0000098. ntfs.sys is the Windows NTFS file-system driver. The displayed filename can reflect corruption of that file, a component-store problem, unreadable sectors, RAM corruption, or a storage/filter driver damaging data. It does not make BCD rebuilding the default repair.

Searchable Windows error codes and exact messages

Useful searches include the full code, File: \Windows\System32\drivers\ntfs.sys, and the exact message. Do not omit the filename when searching 0xc0000098; without it, results are dominated by BCD cases.

Use this procedure when the Recovery screen explicitly names ntfs.sys, the Windows volume is consistently detected and readable in WinRE, and no hardware diagnostic has failed.

Do not apply it to a generic 0xc0000098 that names BCD, to a missing disk, to a volume that repeatedly disappears, or to confirmed physical media failure. Use the general checksum procedure when another boot-critical file is named.

The exact build may remain unknown for initial SFC. It becomes required when DISM needs a matching repair source. The named file, Windows volume, storage stability, and result of each integrity check may not remain unknown.

• WinRE or Windows installation media
• A backup destination for logs and the existing ntfs.sys
• Stable access to the Windows volume
• Matching Windows installation media if component-store repair is required
• Hardware diagnostics when I/O or repeated corruption is present

Open WinRE Command Prompt. Detect the Windows volume and assign it W:. Do not assume it is C:.

1. Record the code, complete message, and File: line.

2. Detect volumes:

   diskpart
   list volume
   

3. Select the known Windows volume and assign W if necessary:

   select volume <Windows-volume-number>
   detail volume
   assign letter=W
   exit
   

4. Verify Windows and inspect the file:

   dir W:\Windows\System32\Config\SYSTEM
   dir W:\Windows\System32\drivers\ntfs.sys
   

5. Create an evidence folder and preserve the file if readable:

   md W:\BootRepairBackup\ntfs
   copy W:\Windows\System32\drivers\ntfs.sys W:\BootRepairBackup\ntfs\ntfs.sys.before-repair
   

6. Check the volume without forcing a repair first:

   chkdsk W:
   

7. Interpret the result:

   • If CHKDSK reports no problems and the volume is stable, proceed to SFC.
   • If it reports logical errors but no hardware warning, use the controlled file-system branch.
   • If it reports unreadable sectors, repeated I/O errors, or cannot complete, stop repairs and image/diagnose the storage device.

8. If multiple protected files have changed or corruption returns after repair, plan memory testing before trusting the installation.

Branch A — Repair the protected file with offline SFC

1. Run offline System File Checker against the detected installation:

   sfc /scannow /offbootdir=W:\ /offwindir=W:\Windows
   

2. Record the exact final message.

3. Copy the servicing log before restarting:

   copy W:\Windows\Logs\CBS\CBS.log W:\BootRepairBackup\ntfs\CBS-after-SFC.log
   

4. If SFC reports that it repaired files, restart and test twice.

5. If SFC cannot repair ntfs.sys, continue to the matching-source branch.

Branch B — Repair the component store with matching media

1. Determine the installed edition, architecture, language, and build closely enough to choose a compatible source. Exact version matters here.

2. Assign the installation-media volume M: and identify whether it contains install.wim or install.esd:

   dir M:\sources\install.*
   

3. List indexes and select the one matching the installed edition:

   dism /Get-WimInfo /WimFile:M:\sources\install.wim
   

   If the media uses ESD:

   dism /Get-WimInfo /WimFile:M:\sources\install.esd
   

4. Repair the offline image with the matching source.

   WIM example:

   dism /Image:W:\ /Cleanup-Image /RestoreHealth /Source:wim:M:\sources\install.wim:<index> /LimitAccess
   

   ESD example:

   dism /Image:W:\ /Cleanup-Image /RestoreHealth /Source:esd:M:\sources\install.esd:<index> /LimitAccess
   

5. Run offline SFC again:

   sfc /scannow /offbootdir=W:\ /offwindir=W:\Windows
   

6. Preserve DISM.log and CBS.log, then restart.

Branch C — Repair demonstrated logical NTFS errors

1. Confirm the disk remains stable and the only evidence is logical file-system damage.

2. Run:

   chkdsk W: /f
   

3. Do not interrupt it. Record whether it repaired indexes, security descriptors, the bitmap, or other metadata.

4. After CHKDSK completes, run offline SFC as in Branch A.

5. If errors recur, stop. Repeated logical corruption after repair points to hardware, memory, power, controller, or filter-driver problems.

Branch D — Recurring or multi-file corruption

1. Return CPU and memory settings to documented defaults and disable XMP/EXPO temporarily.

2. Follow FIX-028 to test memory.

3. Review recent antivirus, backup, encryption, snapshot, and file-system filter software. Remove or update a demonstrated third-party filter through its supported uninstaller.

4. Re-run SFC only after memory and storage are stable.

• SFC repairs ntfs.sys and Windows starts: The protected-file copy or component reference was damaged.
• DISM plus SFC succeeds: The local component source required repair before SFC could restore the file.
• CHKDSK reports repeated bad clusters or I/O failures: Stop using the device for repair attempts and prioritize imaging and hardware replacement.
• The screen still shows 0xc0000098 but no longer names ntfs.sys: Reassess BCD and the new File: line.
• The machine later displays 0x24: Review the dump, storage events, free space, and third-party file-system filters.
• Corruption returns in different files: Test RAM and the storage path rather than repeatedly replacing files.

• Do not download ntfs.sys from a file-download site or copy it from an arbitrary computer.
• Do not rebuild BCD just because the numeric code is 0xc0000098.
• Do not run chkdsk /r repeatedly on a failing drive.
• Do not force DISM to use media with the wrong edition, architecture, language, or unsuitable build.
• Do not disable signature enforcement as the permanent solution to 0xc0000428.
• Do not declare the disk healthy merely because it is an SSD; HDDs and SSDs can both return I/O errors.

SFC, DISM, and CHKDSK do not provide a simple per-file undo. The verified system image or backup is the rollback. Preserve the pre-repair file and logs for comparison, but do not manually copy the old file back if Windows has replaced it with a verified copy.

• Windows starts normally twice and cold-starts once.
• sfc /scannow from running Windows reports no remaining integrity violation.
• No new 0xc0000098, 0xc0000221, 0xc0000428, or 0x24 appears.
• Storage diagnostics and event logs show no recurring I/O problem.
• Memory testing is clean when corruption had affected more than one file.
• The pre-repair file and CBS/DISM logs are preserved.

Confidence is high when the Recovery screen names ntfs.sys, storage is stable, SFC replaces the file, and the system remains clean. Confidence is moderate when component-store repair is required. Stop if the disk disappears, CHKDSK cannot complete, I/O errors recur, corruption returns, or compatible repair media cannot be identified.