Free chkdsk log reader
Windows ran a disk check.
Read what it wrote down.
ChkdskVerdict lists every file, record and attribute your chkdsk transcript names, each with the line it came from, and identifies FOUND.000 fragments by their signature. It reports what the log says. It does not guess why the check ran.
- Read in your browser; your file is never uploaded
- No account, cookies, analytics or ads
- Free — donations only
What is a chkdsk log, and why can't you read it?
When Windows checks a disk at startup, it prints a running transcript to a screen nobody is watching, then closes it. The text is not lost — it is written to the Application event log under the source Wininit, event ID 1001, and on some runs to C:\chkdsk.log as well.
The transcript is the only record of what the check changed. It names files. It says which index entries were removed and which file records were deleted. Almost every article about chkdsk ignores this file entirely and offers general advice instead.
This page reads the transcript and lays out its contents: every named item, every counter, every stage, the closing space table, and any line it did not recognise. Each value shows the line it came from so you can check it.
How to find your chkdsk log
There are three places the transcript can be, in order of reliability.
- Event Viewer
Press Win+R, run eventvwr.msc. Open Windows Logs → Application. Click Filter Current Log, set Event sources to Wininit. Open the newest entry — the whole transcript is the event's message text. Right-click → Copy → Copy details as text, paste into Notepad, save as .txt. - PowerShell, in one line
Run PowerShell as administrator and paste:
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Microsoft-Windows-Wininit'} | Select-Object -First 1 -Expand Message | Out-File $env:USERPROFILE\Desktop\chkdsk.txt
That writes chkdsk.txt to your desktop. - C:\chkdsk.log
Some runs write this file at the root of the checked volume. It is not always there, so do not worry if it is missing.
If you also have a FOUND.000 folder, put it and the log into one .zip and drop that instead. The fragments are then identified by signature alongside the transcript.
What the messages mean
These are the lines that name something. Every one of them is reported with its line number, and the full list of what appeared in your file is in the report.
| Line in your log | What it records |
|---|---|
| Deleting index entry NAME in index $I30 of file N | A filename was removed from a directory index. The name is preserved in this line. The line says nothing about where the file's contents went. |
| Deleting orphan file record segment N | A file record with no valid parent directory was removed. This line carries a record number and no filename, so no name for it exists in the transcript. |
| Recovering orphaned file NAME into directory file N | A file that had lost its directory entry was placed back under a directory record, keeping its name. |
| Deleting corrupt attribute record (128, "") | An attribute was removed from a file record. Type 128 is $DATA — the attribute that holds a file's contents. Type 48 is $FILE_NAME, 160 is $INDEX_ALLOCATION. |
| Cleaning up N unused index entries from index $SII of file 9 | Routine housekeeping of security-descriptor indexes. It appears on most runs and concerns internal bookkeeping, not user files. |
| N KB in bad sectors | Space the volume has marked unusable, as printed by this run. The transcript does not say when they were marked or whether the figure is growing. |
| Insufficient disk space to recover lost data | The run stopped recovering data because the volume had no room for it. |
| Windows has made corrections to the file system | The closing line of a run that changed something. |
| Windows has scanned the file system and found no problems | The closing line of a run that changed nothing. A different outcome entirely, and worth checking which one your log ends with. |
The lines chkdsk writes, and what each means for your files
A chkdsk transcript is a list of statements about individual files, and each kind means something different for whether that file still exists. Every line below is one this reader extracts and shows with its line number.
| What you will see in the file | What it records |
|---|---|
Deleting index entry IMG_0421.JPG in index $I30 of file 5Deleting index entry IMG_0421.JPG in index $I30 of file 5. | The name was removed from a directory. $I30 is the NTFS index holding filenames for one folder, and file 5 is that folder’s record number. The data may still exist with no name pointing at it. |
Deleting orphan file record segment 44032Deleting orphan file record segment 44032. | A file record no directory referenced was removed — the other half of the case above: data with no name, rather than a name with no data. |
Recovering orphaned file X into directory file 3Recovering orphaned file X into directory file 3. | The opposite of a deletion: a file that had lost its directory entry was reattached. directory file 3 is a record number; record 5 is the volume root. |
Deleting corrupt attribute record (128, "")Deleting corrupt attribute record (128, "") from file record segment 44032. | Attribute type 128 is $DATA — the file’s contents. Empty quotes mean the unnamed default stream. This line concerns the data, not the name. |
Windows has made corrections to the file systemWindows has made corrections to the file system. | The closing statement when chkdsk changed something. Its absence is equally informative: a clean run says it scanned and found no problems instead. |
FOUND.000FOUND.000\FILE0001.CHK | The folder chkdsk creates at the root of the volume for recovered fragments. Hidden and system-marked, so it stays invisible in Explorer until protected files are shown. |
FILE0001.CHKFOUND.000\FILE0001.CHK | One recovered fragment, numbered in write order. The original name is not stored inside it — which is why the transcript, which does hold names, is the more useful half. |
FOUND.000 and .CHK files
When a disk check recovers data whose directory entry is gone, it writes the data into a folder named FOUND.000 (then FOUND.001, and so on) as files called FILE0001.CHK. The extension is not a format. It means “recovered fragment” and nothing else, which is why no program opens them.
Drop the folder in a zip with your log and each fragment is identified from its first 4 KB and its size: JPEG, PNG, PDF, OOXML, OLE2, SQLite, MP4 and several dozen more. Where a JPEG carries Exif in that window, the camera make, model and capture date are read out too.
What is deliberately not done: matching fragments to the names in the transcript. FOUND.000 contains fragments that no transcript line mentions, and record numbers do not carry across, so any such mapping would be invented. The two lists are shown side by side and left that way.
Every line is accounted for
The report ends with a coverage figure: how many lines your file has, how many were recognised, and — line by line, quoted verbatim — any that were not. A reader that quietly skips what it does not understand can show you a confident, mostly-empty summary of a file it barely read.
If your transcript is not in English, the report says so and extracts nothing. An empty result is reported as an empty result, never as a clean bill of health.
Frequently asked questions
Does this tell me why the disk check ran?
No. The transcript records what the run did, not what prompted it. Windows schedules a check when a volume is flagged dirty, but the reason for the flag is not in this file.
Can I get my files back with this?
This reads the log; it is not recovery software. What it gives you is the list of names the log contains and an inventory of what is in FOUND.000 — the information a recovery service would otherwise spend an hour establishing.
Is my log uploaded anywhere?
No. The reader is JavaScript: the log is read from disk into memory in your own browser, parsed there, and never sent anywhere. No account, no cookies, no analytics, nothing stored.
My log has lines the report says it did not recognise.
They are listed verbatim with their line numbers. chkdsk has message forms that vary by Windows build and filesystem; anything unmatched is shown rather than dropped, and those lines are how the reader's grammar gets extended.
Does it read ReFS or FAT transcripts?
The message grammar is the NTFS one. A FAT or ReFS transcript will produce many unrecognised lines, and the report will show them as such.