Visit Website →
← Back to blog

Don't Disable Write Cache Flushing Without These Two Checks

October 3, 2026
Don't Disable Write Cache Flushing Without These Two Checks

Don't disable Windows write-cache buffer flushing unless your storage device or power setup explicitly guarantees durability through a sudden power loss. If you're not certain your drive has a battery-backed cache or your UPS and shutdown sequence have been tested end to end, leave the default setting alone. The performance gain is real but conditional, and the failure mode is silent corruption, not a crash you'll notice right away.

TL;DR:

  • Disabling automatic cache flushing should only be considered if your storage device has a verified battery-backed cache or a tested UPS with an actual shutdown test, not just presence.
  • Applications can enforce data durability more precisely through file-specific flags or direct commands, making the global policy setting unnecessary for many use cases.
  • Changing the setting without proper safeguards risks silent data loss, filesystem corruption, or inconsistent directory structures if power fails before caches are emptied.
  • Always verify storage health, backup data, and test shutdown procedures before attempting to disable cache flushing, and perform controlled tests to measure real performance gains.
  • Most SSDs and Windows configurations are safest with automatic flushing enabled; only disable it if stringent hardware protections are confirmed and the workload can tolerate potential data loss.
Tempered
Optimize Windows With More Control
Tempered identifies real performance constraints and proposes transparent, user-approved changes with clear explanations and a detailed undo path.
Explore Tempered

Table of Contents

What the Windows setting actually does

Windows writes files through a layered buffering system, and the checkbox people are asking about only touches one layer of it. When an application writes data, Windows first holds it in system memory buffers managed by the kernel. Separately, many storage devices maintain their own onboard write cache, a small pool of fast memory that absorbs writes before they land on the actual storage medium. The "Turn off Windows write-cache buffer flushing" option in Device Manager controls whether Windows automatically issues flush commands to force that device-level cache out to stable storage at regular intervals.

Layered Windows and device write caches

According to Microsoft's file caching documentation, disabling that policy reduces the automatic durability barriers Windows normally enforces, but it does not remove an application's ability to request durability on its own terms. A database engine, for instance, can still call FlushFileBuffers to force buffered data to the device at a specific point, guaranteeing that a transaction is actually committed before the application reports success.

Applications have two other tools for this. FILE_FLAG_WRITE_THROUGH tells Windows to write data directly to the device with each write operation instead of caching it in system memory first. FILE_FLAG_NO_BUFFERING skips the system cache entirely for that file handle. Together, these let well-written software enforce its own durability guarantees regardless of what the global flushing policy is set to. The checkbox is a blunt, system-wide instrument. Application-level flags are a scalpel.

Risks, failure modes, and prerequisites before you change the setting

Disabling automatic flush commands means data sitting in a device's write cache can be lost if power drops before that cache empties on its own. That is not just a matter of losing the last few files you were working on. File system metadata, the records that track which blocks belong to which files, gets written in a specific order that assumes flushes happen when the OS expects them to. Interrupt that sequence and you can end up with a file system that thinks a write succeeded when it did not, which is how directories go missing or files show up zero-length after a crash.

Raymond Chen's Old New Thing post on this exact checkbox is blunt about it: don't select it unless the device has a separate power supply. That is a deliberately narrow condition. It means a battery-backed or capacitor-backed controller cache, not just "I have a UPS plugged in."

A UPS protects against one failure mode, mains power loss, and it does that imperfectly. It buys you a window to shut down gracefully, but that window has a time limit, and a UPS does nothing for a driver crash, a firmware bug, a forced hard reset, or a blue screen that halts the system mid-write. Practitioner write-ups on SSD tuning caveats make the same point: a UPS is not a complete guarantee, because the failure that interrupts a write doesn't have to be a power failure at all.

Before you even consider flipping this setting, you need one of two things in place: a verified battery-backed or capacitor-backed cache on the storage controller itself, or a UPS plus a tested, automatic graceful-shutdown sequence that you've actually triggered and watched work, not just assumed.

Two prerequisites for safer cache flushing

When it makes sense to disable automatic write-cache flushing

There is a narrow band of situations where this setting is defensible, and it comes down to whether your hardware and workload can tolerate the risk you're taking on.

  • Your storage controller has a confirmed battery-backed or capacitor-backed cache, verified through a device property query rather than a guess.
  • You have a UPS with a tested, automatic shutdown sequence that has actually been triggered and observed working, not just installed and left alone.
  • The workload is non-critical: benchmark runs, temporary performance testing, or scratch data you can afford to lose.
  • You have a maintenance window and a rollback plan if something goes wrong.

If any of those boxes are unchecked, the setting isn't worth it. For transactional workloads, databases, or any machine holding data you can't recreate, the safer move is to test the change in an isolated environment, a spare machine or a virtual machine, before you touch anything that matters. The Server Fault discussion on this exact question reports real speed gains on some SSDs alongside documented corruption incidents when the change was made without those protections in place. Both outcomes are plausible, and which one you get depends entirely on the hardware underneath you.

How to check your current setting and query device write-cache properties

Before changing anything, find out what you're actually working with.

  1. Open Device Manager, expand Disk drives, right-click your drive, choose Properties, and open the Policies tab. The "Turn off Windows write-cache buffer flushing" checkbox lives here, alongside the general write-caching toggle.
  2. For a device-level answer instead of a GUI guess, developers and administrators can query IOCTL_STORAGE_QUERY_PROPERTY with StorageDeviceWriteCacheProperty, documented in Microsoft's guide to querying the write cache property. This returns the device's cache type, whether it supports the sync-cache command, and whether a battery backup flag is present.
  3. Interpret the result against two distinctions: write-back caching (data is acknowledged before it reaches the medium) versus write-through (acknowledged only after it reaches the medium), and whether the battery-backed flag is actually set, which is the detail that matters most for your decision.

Safe step by step: how to disable or re-enable the setting

Treat this as a controlled change, not a quick toggle. Work through the prechecks first.

  1. Back up anything on the machine you can't recreate, and confirm the backup is readable before you proceed.
  2. If possible, run this test on a spare machine or a virtual machine rather than your primary system.
  3. Confirm UPS status if you're relying on one, and close any application performing critical writes, including databases, sync tools, or editors with unsaved work.
  4. Open Device Manager, expand Disk drives, right-click the target drive, select Properties, open the Policies tab, and check or uncheck "Turn off Windows write-cache buffer flushing" as needed.
  5. Click OK and restart the application or, for a full test, restart the machine to confirm the setting persisted.
  6. To re-enable later, repeat the same path and uncheck the box, restoring the default flushing behavior.

Pro Tip: Screenshot the Policies tab before you change anything, so you have a clear record of the original state to restore if the test goes sideways.

After the change, don't just assume it worked. Run a handful of sample writes to a test file, watch Event Viewer for any new disk or file system warnings, and if you have access to a checking tool like chkdsk, run it in read-only mode afterward to confirm the file system is still internally consistent. If anything looks off, including unexpected errors, slow boot behavior, or signs of disk strain covered in guides on fixing 100% disk usage, revert immediately using the same Policies tab path.

Safer alternatives and complements to changing the global setting

Flipping the global checkbox affects every write on that device, which is exactly the problem. Most of the time, what you actually want is durability control over specific writes, not a blanket policy change, and Windows gives applications that option directly.

For a single durability checkpoint, an application can call FlushFileBuffers, which forces buffered data for that file out to the device, as documented in Microsoft's guidance on flushing system-buffered I/O data to disk. The catch is that calling it repeatedly, for every write in a tight loop, is inefficient because each call is a synchronization point that blocks until the device confirms the data landed.

For workloads with many writes that each need a durability guarantee, Microsoft recommends unbuffered I/O instead: opening the file with FILE_FLAG_NO_BUFFERING combined with FILE_FLAG_WRITE_THROUGH. This writes data directly to the device on every operation without relying on repeated explicit flush calls, giving you per-write guarantees without the global trade-off of disabling flushing system-wide.

It's also worth checking whether your device supports the SCSI SYNCHRONIZE CACHE command or an equivalent write-through mode, since the same write-cache property query used to check for battery backup also reports this. Where it's supported, software can request write-through behavior selectively instead of leaving the whole device in write-back mode.

The trade-off is the same at any granularity: more durability guarantees cost performance, because each one is a synchronization point. The difference is that per-write or per-application controls let you pay that cost only where it matters, instead of either paying it everywhere or nowhere.

Testing and verification plan after you change the setting

Don't trust a "feels faster" impression. Measure before and after, and test failure, not just speed.

  • Run a repeatable benchmark, sequential and random writes of a known size, before the change and again after, on the same test machine.
  • On a test machine only, simulate a power interruption after a batch of writes (a forced shutdown, not a graceful one) and then check file system integrity afterward.
  • Compare write latency and throughput numbers against your pre-change baseline to confirm the performance gain is actually meaningful for your workload.
  • Treat any corruption, missing file, or chkdsk error found during the simulated failure as an automatic rollback trigger, regardless of how good the speed numbers looked.

If the test machine survives several forced-shutdown cycles cleanly and the performance gain is measurable, you have a reasonable basis for applying the change more broadly. If it doesn't survive cleanly even once, that's your answer, and no amount of speed improvement should override it.

Tempered and Ian's practical diagnostics and undo-first checklist

Before touching a system-level setting like this, it's worth confirming the basics that often get skipped: drive health, background load, and power policy. Checking SSD health and SMART status first tells you whether the drive itself is a reliable candidate for any caching change, and reviewing background processes rules out the possibility that sluggish performance has nothing to do with caching at all.

Some performance optimization tools are built around this same instinct: diagnose before you touch anything, and never apply a change the user hasn't explicitly approved. That mirrors the checklist in this guide: verify what you're dealing with first, change one thing at a time, and keep a way back.

Author perspective: a cautious, practical closing recommendation

My default position is to leave automatic flushing enabled, full stop, unless you can point to a specific hardware feature or tested procedure that justifies disabling it. Most machines don't have a battery-backed cache, and most UPS setups have never actually been tested through a real outage.

If you want to experiment anyway, do it on a machine you can afford to lose, simulate a real power failure, and check the file system afterward before you trust the result on anything that matters. A sensible workflow for a power user: verify the device property, test in isolation, measure the actual gain, and keep the rollback step ready before you ever touch a production machine.

— Ian

Sources

FAQ

Should I enable or disable write cache on my SSD?

Leave write caching enabled for normal use since most SSDs and Windows are designed to work safely with it on. Only disable the automatic flushing policy specifically if you've confirmed a battery-backed cache or a tested UPS and shutdown sequence, as described in Microsoft's removal policy guidance.

What does flushing cache do?

Flushing forces data sitting in a buffer, either in system memory or on the device itself, out to stable storage so it's actually durable rather than just acknowledged. The Win32 file caching documentation explains that FlushFileBuffers is the mechanism applications use to force this at a specific point rather than waiting for Windows to do it automatically.

What happens if I disable the cache?

Disabling the automatic flush policy means data can sit in the device's write cache longer before it's committed, which improves performance but risks loss or file system inconsistency if power is interrupted before that cache empties. Raymond Chen's Old New Thing warning advises against this unless the device has a separate power supply.

How do I turn off write caching in Windows 11?

Open Device Manager, expand Disk drives, right-click your drive, select Properties, and open the Policies tab, where you can toggle write caching and the write-cache buffer flushing checkbox. Confirm your backup and power protections are in place first, then verify the result with sample writes before trusting the change on a production machine.