Native Windows file recovery for NTFS, FAT, exFAT and ext2/3/4. One engine for GUI and CLI, with metadata, journal and RAW scanning.

KVC File Recovery Tool

Recover deleted files from NTFS, FAT12/16/32, exFAT and ext2/3/4, or scan a whole disk or flat image without a usable file system. The native Win32 GUI and CLI use the same scanning and recovery engine. No installer, service or application framework is required; the static-runtime builds do not need a separate Visual C++ runtime.

The engine reads the source and writes recovered files to another disk. It uses surviving names, sizes and allocation maps where available, and checks file structure when carving. Results distinguish Full, Partial, MetadataOnly and unavailable data. A surviving file record is not a promise that its original bytes still exist.

Changelog

[13.10.2026]

[18.07.2026] — First public release

NTFS, FAT32 and exFAT recovery, USN history, signature scanning, GUI/CLI operation and four x64/x86 binary variants.

Recovery methods

USN records alone do not reconstruct file contents. If the matching MFT record is gone, its history is metadata only. Carving normally assumes contiguous data; complete surviving ext block maps can let it follow fragments and skip metadata blocks. RAW does not discover missing fragment maps.

Ext volumes are read directly by the engine; an installed ext driver is not required. Metadata parsing covers ext2/3/4; the recorded ext recovery scenarios exercise ext3 and ext4.

File types

Metadata recovery is not limited to the extensions below. These are the formats exercised by the current signature-recovery tests:

ZIP-based Office extensions are inferred from package member names. This does not validate their XML contents. The presence of a format's signature in the source code does not by itself establish complete recovery support.

Download and requirements

Download the password-protected archive, extract it with github.com, and choose a binary:

Administrator rights are required for direct disk and volume access. Development validation is performed on Windows 11 x64. The application uses native Windows APIs; Mica depends on OS support and falls back to an opaque surface.

Preserve the source. Stop writing to it after deletion, and save recovered files and reports to another physical disk. On SSD/NVMe, data already discarded through TRIM may no longer be readable.

GUI

1. Run the application as administrator.
2. Select a volume, a whole disk, or Open image for a flat image.
3. Choose the discovery methods and optional name/path filters. Whole-disk and image sources enable RAW, which is separate from the file-system methods.
4. Start scanning and inspect names, sizes and reported recovery quality.
5. Select rows with Ctrl/Shift or Ctrl+A, then Recover selected to another physical disk.

Scanning runs in the background and results arrive in batches. The interface follows Windows light/dark and high-contrast settings. Fonts and controls scale with DPI, including 150% scaling.

CLI

Run from an elevated terminal. --mft selects the source file system's own records, including FAT/exFAT and ext; it is not restricted to NTFS. Use --usn for NTFS history, --carving for free-space signatures, or --all to combine those methods. --raw is a separate mode.

# List available volumes.
.\FRT_x64.exe --cli --list

# Recover from file-system records.
.\FRT_x64.exe --cli --drive E --mft --recover --output D:\Recovered

# Combine metadata, history and free-space signatures; save a report.
.\FRT_x64.exe --cli --drive E --all --csv D:\results.csv --recover --output D:\Recovered

# Scan a volume that has no drive letter, including an ext volume.
.\FRT_x64.exe --cli --volume \\.\HarddiskVolume7 --mft --recover --output D:\Recovered

# Scan a flat byte-for-byte image without file-system metadata.
.\FRT_x64.exe --cli --image D:\images\source.img --raw --diagnostics --recover --output E:\Recovered

# Scan a whole physical disk. Verify the device number before use.
.\FRT_x64.exe --cli --volume \\.\PhysicalDrive2 --raw --csv E:\raw.csv

.\FRT_x64.exe --help

VHD/VHDX containers must be mounted first and scanned through their disk or volume device. --image expects a flat image. The program checks the physical source disk against recovery/report destinations; another partition of the same disk is rejected. For flat images, overwriting the input, including through a hard link, is rejected.

Validation

The tests create and delete their own fixtures on isolated disks in a Windows 11 Hyper-V guest. They recover through the production CLI, compare SHA-256, and check output counts and quality. Fragmentation is measured from the actual physical extent map before deletion.

Selected results recorded on 13.10.2026:

Additional cases check corrupted/truncated archives and PDFs, source immutability, RAW destination checks, menu text in three palettes, and truthful metadata-only results after NTFS loses extension-record maps.

These are controlled recovery tests, not a physical NVMe/TRIM benchmark or a success rate for arbitrary damaged disks. DPI changes are simulated; they do not replace physical multi-monitor testing. See test methods, results and limitations for the detailed matrices.

Current limits

• Lost bytes: overwritten or discarded/TRIMmed contents cannot be reconstructed by these methods.
• Fragmentation: without a surviving map, signature recovery cannot generally assemble arbitrary fragmented files. RAW currently assumes contiguous data and limits each candidate to 2 GiB.
• NTFS: deletion can clear maps held in extension records. Those files are metadata only; allocation-map recovery from $LogFile is not implemented.
• Archives: full ZIP64 central directories/end records and split archives are unsupported. 7z header CRC checks do not decode or validate every compressed payload.
• PDF: cross-reference streams require a direct length; their entries and the full document are not decoded. Complex or damaged PDFs need broader coverage.
• Damaged file systems: quick-format NTFS, damaged boot records and MFT/FAT fallback paths still need dedicated recovery tests.

Full describes the available recovery map and boundaries, not a complete content-decoder verdict. The tests independently open/decode selected recovered files, but scanning does not perform that validation for every format.

Build and source layout

Use Visual Studio C++ tools with the platform toolset named by the project, a Windows SDK and PowerShell 7. The build script locates usable x64/x86 compilers, MSBuild and Windows SDK resource compilers from files on disk.

pwsh -File build.ps1 -Rebuild

This builds all four release variants into bin/. build_all.bat calls the same script. For only the tested x64 static-runtime build, use pwsh -File tests/build-x64.ps1 -Rebuild. The solution is kvc_recovery.slnx.

src/ separates entry points, GUI, scan orchestration, disk I/O, file-system parsers, carving, recovery and support code. Visual Studio filters mirror the directory structure. Both interfaces call DiskForensicsCore and RecoveryEngine; the CLI is also the route used by the recovery test harness.

License and author

MIT License.

Marek Wesołowski (WESMAR)

GitHub · kvc.pl · marek@wesolowski.eu.org

Add a comment

Name (optional)

Email (optional, never published)

Comment *

Type the characters from the image *

Submit

Comments

Extremely performant recovery tool ! I have recovered most of the files from my SD Card that a previous SD Android "backup tool" had completely wrecked. However, the paths of the recovered files are displayed, but when I save to Csv, only a few dozen files are in the CSV file. Do you accept donations in one form or another ? Best regards

Written on Sun, 04 Oct 2026 12:50:52 by Harry K

Author reply

Harry, glad you recovered most of your files. That’s exactly why I built this tool. I’ll fix the export issue when I add ext4 support. Thanks for offering to donate. I’ll add a donation button in the future. I currently cover all infrastructure costs myself, including electricity for the test farms. Long low-level test runs add up. Marek

Marek Wesołowski · Mon, 05 Oct 2026 00:04:08