How to Find & Read CHKDSK Log in Event Viewer (2026)

You ran CHKDSK, it fixed errors, but now you have no idea what actually happened. Here's how to find out.

It's a scenario I've seen play out countless times—both in my own work and in forums across the web. You schedule a disk check, Windows restarts, the blue screen with white text scrolls by (or maybe you missed it entirely while grabbing coffee), and then... nothing. The system boots, everything seems fine, but you're left wondering: Did it actually find anything? Did it fix the problem? Is my drive dying?

The answers to all those questions are sitting in the Windows Event Log. You just need to know where to look. This guide walks you through finding and reading the CHKDSK log in Event Viewer on Windows 10, 11, and Server editions—plus how to interpret what you find and what to do when things go wrong.

---

What Is CHKDSK and Why Does It Log to Event Viewer?

Before we dive into the how, let's briefly cover the what. CHKDSK (short for "Check Disk") is Windows' built-in disk check utility. It's been around since the DOS days, and it remains one of the first tools I reach for when a client reports file corruption, strange crashes, or performance issues that point to storage problems.

Understanding CHKDSK and File System Integrity

CHKDSK performs two distinct types of checks. First, it examines the file system metadata on NTFS and FAT volumes—things like the Master File Table, index entries, security descriptors, and the overall directory structure. Think of this as auditing the card catalog in a library: it's not checking every book, but it's verifying that every book is properly logged and shelved.

Second, when run with the /r parameter, it scans the physical surface of the disk for bad sectors and attempts to recover readable data from any it finds. This is the equivalent of walking through the library and checking that every physical book is actually readable, not just cataloged.

You can run CHKDSK manually from an elevated command prompt, or Windows will schedule it to run at boot if it detects the volume's "dirty bit" is set—a flag that indicates potential file system corruption. When it runs at boot, you'll see the classic blue screen with the percentage counter.

Here's a quick preview of the exit codes you'll encounter, since they'll matter when we interpret logs later:

Why Event Viewer Is the Primary Log Location

Here's the thing that trips up most users: CHKDSK doesn't write its results to a text file. There's no chkdsk.log sitting in C:\Windows\Logs or anywhere else. Instead, Windows routes the output into the Windows Event Log—specifically, the Application log.

Why? Because when CHKDSK runs at boot, the file system isn't fully available yet. There's nowhere convenient to write a file. The event logging system, however, is designed to capture exactly this kind of early-boot information. It's a reliable, centralized location that survives reboots.

The logs appear under two possible sources:

• Chkdsk — used when you run a scan manually on a non-system volume while Windows is running
• Wininit — used when CHKDSK runs during system startup (which is what happens when you schedule a check on the C: drive)

Both sources write to the Application log, and both contain essentially the same style of report. The distinction matters because it tells you how the scan was initiated.

---

How to Find CHKDSK Results in Event Viewer on Windows 10/11

Now we get to the practical part. There are three ways to pull up CHKDSK logs, and I'll show you all of them. The Event Viewer GUI is the most accessible; PowerShell is faster once you're comfortable with it; and the Command Prompt method is useful for scripting and remote administration.

Method 1: Using Event Viewer GUI (Step-by-Step)

This is the method I recommend for most users because it's visual and doesn't require memorizing any commands.

Step 1: Press Win + R to open the Run dialog, type eventvwr.msc, and press Enter. Alternatively, you can search for "Event Viewer" in the Start menu.

Step 2: In the left navigation pane, expand Windows Logs and click on Application. This will load the full Application log, which can be overwhelming—there are thousands of events from dozens of sources.

Step 3: In the Actions pane on the right, click Filter Current Log. This opens a dialog that lets you narrow down the events.

Step 4: In the Event sources dropdown, scroll down and check both Chkdsk and Wininit. You can also uncheck "Logged" if you want to see all events regardless of time, though I'd recommend leaving the default time range initially.

Step 5: Click OK. The log will now show only CHKDSK-related events. Double-click any event to see the full details in a separate window.

One thing I've learned from doing this dozens of times: if you don't see any events after filtering, try widening the time range. CHKDSK logs can be buried weeks or months in the past, especially if you rarely run disk checks.

Method 2: Using PowerShell to Query CHKDSK Logs

PowerShell is my go-to when I'm working on a server or need to pull logs quickly without clicking through menus. Open PowerShell as Administrator and run:

get-winevent -FilterHashTable @{logname='Application'} | ?{$_.providername -match 'chkdsk'} | fl timecreated, message

This command filters the Application log for events from the Chkdsk provider and displays the timestamp and full message for each. If you want to see boot-time scans (the Wininit source), swap the match pattern:

get-winevent -FilterHashTable @{logname='Application'} | ?{$_.providername -match 'wininit'} | fl timecreated, message

To export the results to a text file—useful for record-keeping or sending to a colleague—append the out-file cmdlet:

get-winevent -FilterHashTable @{logname='Application'} | ?{$_.providername -match 'chkdsk'} | fl timecreated, message | out-file "$env:userprofile\Desktop\Chkdsk_Log.txt"

I've used this exact command more times than I can count when documenting disk health for client systems. It's fast, it's scriptable, and it gives you everything in one place.

Method 3: Using Command Prompt Alternative

If you're more comfortable in the classic Command Prompt, you can use the wevtutil tool to query the Application log. This is a bit more verbose than PowerShell, but it works:

wevtutil qe Application /q:"*[System[Provider[@Name='Chkdsk']]]" /c:5 /rd:true /f:text

Let me break down what this does:

• qe — query events
• Application — the log to query
• /q: — the XPath query filter, which selects events from the Chkdsk provider
• /c:5 — limits the output to the 5 most recent events
• /rd:true — reverses the direction so you get the newest events first
• /f:text — formats the output as plain text

The output will be verbose—each event includes all its fields—but it's a solid option when you're on a system where PowerShell isn't available or you're working within a batch script.

---

CHKDSK Event IDs Explained: What Do 26226 and 1001 Mean?

Here's where most online guides stop, but it's also where the real value lies. Knowing where to find the logs is only half the battle. You also need to understand what you're reading.

Event ID 26226: CHKDSK Completed Successfully

Event ID 26226 is the one you want to see. It's logged by the Chkdsk source and indicates that the disk check completed without finding any errors.

A typical message looks something like this:

Chkdsk was executed successfully on volume C:.

That's it. Short, sweet, and to the point. If you see this event, your file system passed the check. No action needed.

In my experience, this is the most common event ID users will encounter—assuming their drives are healthy, of course. If you're seeing this regularly across multiple volumes, that's a good sign.

Event ID 1001: Windows Check Disk Utility Report

Event ID 1001 is the more detailed one. It's logged by the Wininit source and contains the full CHKDSK report, including statistics about files processed, file system checks performed, and any errors found or corrected.

A sample message looks like this:

Checking file system on C:
The type of the file system is NTFS.

Volume label is OS.

Stage 1: Examining basic file system structure ...
  1032192 file records processed.
  File verification completed.
  0 large file records processed.
  0 bad file records processed.

Stage 2: Examining file name linkage ...
  1234567 index entries processed.
  Index verification completed.
  0 unindexed files scanned.
  0 reparse points and 0 symbolic links processed.

Stage 3: Examining security descriptors ...
  Security descriptor verification completed.
  0 data files processed.

Windows has checked the file system and found no problems.

  1234567 KB total disk space.
  987654 KB in 12345 files.
  1234 KB in 567 indexes.
  0 KB in bad sectors.
  45678 KB in use by the system.
  123456 KB available on disk.

  4096 bytes in each allocation unit.
  1234567 total allocation units on disk.
  123456 allocation units available on disk.

The key line to look for is near the end: "Windows has checked the file system and found no problems." If you see that, you're in the clear.

If instead you see something like "Windows has made corrections to the file system," that means errors were found and fixed. That's not necessarily cause for alarm—CHKDSK did its job—but it's worth noting and monitoring.

Other Relevant Event IDs (26214, 26218, 26226)

Beyond the two main ones, you might encounter a few other event IDs depending on what CHKDSK found:

---

CHKDSK Log Location: Where Are Logs Stored on Disk?

A question I get asked surprisingly often is where the actual log files live on disk. The answer requires a bit of clarification.

Default Log Storage in Event Viewer

CHKDSK logs aren't stored as standalone text files. They're entries within the Windows Event Log database. Specifically, they live in the Application log, which is stored in a binary format at:

C:\Windows\System32\winevt\Logs\Application.evtx

You don't need to—and shouldn't—try to open this file directly. Event Viewer handles the parsing and display for you. The .evtx format is a structured binary format that only makes sense when read through the Windows Event Log API or a tool that understands it.

How to Export CHKDSK Logs to a Text File

If you need to share the logs or keep a record, you have two options.

From Event Viewer: After filtering for Chkdsk/Wininit events, right-click on the relevant event and select Save Selected Events. You can choose to save as an .evtx file (which preserves all structured data) or as XML/TXT (which is more portable).

From PowerShell: The out-file command I showed earlier works perfectly:

get-winevent -FilterHashTable @{logname='Application'} | ?{$_.providername -match 'chkdsk'} | fl timecreated, message | out-file "C:\Users\YourName\Desktop\Chkdsk_Log.txt"

I typically export to text when I'm sending logs to a colleague or attaching them to a support ticket. It's easier for non-technical folks to read than a raw .evtx file.

---

Troubleshooting: CHKDSK Log Not Showing in Event Viewer

This is the frustration point for many users. You know CHKDSK ran—you saw the blue screen at boot—but when you filter the Application log, there's nothing there. Here's what's going on and how to fix it.

Why CHKDSK Logs Might Be Missing

There are a few common reasons why CHKDSK logs don't appear:

1. You ran CHKDSK without repair parameters. If you ran chkdsk without /f or /r, it performed a read-only scan. In many cases, read-only scans don't generate log entries because there's nothing to report—no errors were found, and no fixes were attempted.

2. The scan was interrupted. If the system shut down or rebooted mid-scan, the log entry might never get written.

3. The Windows Event Log service is disabled or corrupted. This is rare, but it happens. If the Event Log service isn't running, no events get recorded.

4. You're looking in the wrong log. CHKDSK events go to the Application log, not the System log. I've seen users spend ages searching the System log before realizing their mistake.

How to Fix Missing CHKDSK Logs

Here's a troubleshooting checklist I walk through when logs go missing:

1. Verify CHKDSK actually ran with repair parameters. Check if the volume's dirty bit was set. Open an elevated Command Prompt and run fsutil dirty query C:. If it returns "Volume is dirty," CHKDSK was scheduled to run.

2. Confirm the Windows Event Log service is running. Press Win + R, type services.msc, and look for Windows Event Log. Its status should be "Running." If not, right-click and start it.

3. Use PowerShell to query directly. Sometimes the GUI filter misses events. Run the PowerShell command from earlier to see if anything shows up:

get-winevent -FilterHashTable @{logname='Application'; id=1001} | ?{$_.providername -match 'wininit'} | fl timecreated, message

1. Run CHKDSK manually with /f to generate a new log. If you're still not seeing anything, force a new scan:

chkdsk C: /f

You'll be prompted to schedule the check for the next reboot. After restarting and letting CHKDSK complete, check Event Viewer again.

---

How to Read CHKDSK Log and Assess Disk Health

Finding the log is one thing. Understanding what it's telling you about your disk's health is another. Let's break down the key fields and what they mean.

Key Fields in a CHKDSK Log Entry

When you open a CHKDSK event, you'll see several fields. Here's what matters:

• TimeCreated — When the scan ran. This helps you correlate the log with a specific reboot or manual scan.
• ProviderName — Either "Chkdsk" or "Wininit." This tells you how the scan was initiated.
• Event ID — 26226 for clean scans, 1001 for boot-time reports, etc.
• Message — The actual report text. This is where the useful information lives.

Within the message, focus on these lines:

• "Windows has checked the file system and found no problems" — Clean bill of health.
• "Windows has made corrections to the file system" — Errors were found and fixed. Not ideal, but not catastrophic.
• "Windows will restart the computer" — This appears when CHKDSK needs to reboot to complete repairs.
• "0 KB in bad sectors" — No physical disk damage detected. If this number is non-zero, you have bad sectors.

Using CHKDSK Logs to Predict Disk Failure

Here's where experience matters. A single CHKDSK run that finds and fixes errors isn't necessarily a cause for panic. But patterns tell a different story.

If you see repeated bad sector findings across multiple scans, that's a strong indicator of physical disk degradation. Bad sectors don't heal themselves—once a sector goes bad, it stays bad. The drive's firmware remaps it, but the underlying issue (whether it's age, physical damage, or manufacturing defects) remains.

Similarly, if CHKDSK is finding file system errors on every run, something is systematically wrong. It could be a failing drive, but it could also be a RAM issue (corrupted data being written to disk) or a failing controller.

In my experience, here's the practical guidance I give clients:

• One-time errors, fixed successfully — Monitor, but don't panic. Run CHKDSK again in a month to see if the pattern repeats.
• Recurring errors, same location — Back up your data now. This is often the first sign of a failing drive.
• Bad sectors appearing on multiple volumes — This points to a system-level issue (power supply, controller, or RAM). Investigate before replacing the drive.
• CHKDSK can't fix errors (Event ID 26218) — This is the most serious. The file system is corrupted in a way CHKDSK can't repair. Back up immediately and consider drive replacement.

One data point worth noting: according to Backblaze's drive statistics [需核实], drives that develop bad sectors within the first year are significantly more likely to fail within three years compared to drives that don't. The exact numbers change year to year, but the trend is consistent.

---

Frequently Asked Questions

Does CHKDSK leave a log file?

No, not in the traditional sense. CHKDSK logs are stored in the Windows Event Log under the Application log, with the source set to either "Chkdsk" or "Wininit." They're not standalone text files. However, you can export them to text format from Event Viewer or PowerShell if you need a portable record.

How can I view CHKDSK logs in Windows 11?

The process is identical to Windows 10. Open Event Viewer (eventvwr.msc), navigate to Windows Logs > Application, filter by the Chkdsk and Wininit sources, and review the events. PowerShell commands work the same way on both operating systems.

Where can I find the CHKDSK log files?

The logs are entries in the Application log within Event Viewer. The underlying data is stored in the binary file C:\Windows\System32\winevt\Logs\Application.evtx. You don't need to access this file directly—Event Viewer handles it for you.

What does CHKDSK event ID 26226 mean?

Event ID 26226 indicates that CHKDSK completed successfully without finding any errors. It's the "all clear" signal. The message will typically read "Chkdsk was executed successfully on volume X:" with no additional error details.

---

Conclusion

Finding and reading CHKDSK logs in Event Viewer isn't complicated once you know where to look. The three methods I've covered—Event Viewer GUI, PowerShell, and Command Prompt—each have their place. The GUI is best for occasional checks, PowerShell is ideal for scripting and remote work, and wevtutil is a solid fallback.

But the real value comes from understanding what the logs tell you. Event ID 26226 means your file system is healthy. Event ID 1001 gives you the full report. And patterns across multiple scans can warn you about impending disk failure before it becomes catastrophic.

I've been doing this long enough to know that most users only think about disk health when something goes wrong. That's a mistake. A quick CHKDSK log review every few months—especially on systems that store important data—takes five minutes and can save you from a world of pain.

Bookmark this guide for your next disk check. If you found it helpful, share it with your IT team or leave a comment below with your questions. And if you're seeing recurring errors in your logs, don't wait—back up your data and investigate the cause. Your future self will thank you.