To ask Windows to write cached data for a disk file, an application must open the file with write access and call the Win32 FlushFileBuffers function on that handle. This is a per-file application request—not a Windows setting that forces every program to persist its data.
Windows normally uses write-back caching: writes can remain in the system file cache while the cache manager writes them later through lazy writing. Microsoft’s file-caching documentation describes this default behavior.
What FlushFileBuffers does
Microsoft documents FlushFileBuffers as flushing the buffers of a specified file and causing buffered data to be written to the file. The function works on an open file handle, and that handle must have GENERIC_WRITE access.
A nonzero return value indicates success. A zero return indicates failure; call GetLastError() immediately afterward to obtain extended error information. The API also has documented behavior for communication devices and named pipes, but the guidance here is scoped to ordinary disk files.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →#1 Best Overall
A successful call is the documented Windows mechanism for requesting that buffered file data be flushed through the storage stack. The API documentation does not establish a universal guarantee against every storage-device cache, power loss, firmware behavior, or hardware failure, so do not treat it as an absolute durability guarantee in all circumstances.
See the Microsoft Learn reference for FlushFileBuffers for the complete contract.
Rank #2
Minimal C example
#include <windows.h>
BOOL WriteAndFlush(HANDLE hFile, const void *data, DWORD bytes)
{
DWORD written;
if (!WriteFile(hFile, data, bytes, &written, NULL) || written != bytes)
return FALSE;
if (!FlushFileBuffers(hFile)) {
DWORD error = GetLastError();
/* Record or handle error here. */
(void)error;
return FALSE;
}
return TRUE;
}The handle passed to this function should have been created with write access, for example by using CreateFile with GENERIC_WRITE. Check both the write result and the flush result; flushing cannot make a failed or partial write successful.
When to use it
- Use it at a durability boundary, such as after writing a transaction record, journal entry, or other state that must be handed off before the program continues.
- Use it when your application needs to request a flush for one already-open file while retaining normal cached I/O for the rest of its work.
- Do not call it automatically after every small write unless that policy is justified. Microsoft warns that flushing after each separate write can be inefficient.
For many critical writes, consider a design that batches ordinary writes and flushes at meaningful commit points, or evaluate unbuffered I/O where its implementation costs are acceptable. Microsoft’s flushing guidance discusses these choices.
FlushFileBuffers compared with file-opening flags
FlushFileBuffers is called after a handle is open. The other mechanisms below change how Windows handles I/O when the file is opened.
| Mechanism | How it is selected | What it addresses | Important costs or limits |
|---|---|---|---|
FlushFileBuffers |
Call the function on an open handle | Requests that buffered information for that specified file be flushed | Requires GENERIC_WRITE; repeated flushes can reduce performance |
FILE_FLAG_WRITE_THROUGH |
Pass the flag to CreateFile |
With system caching enabled, causes writes to be written to the cache and flushed without delay according to the documented configuration | Changes behavior for the handle; exact results still depend on the storage stack |
FILE_FLAG_NO_BUFFERING |
Pass the flag to CreateFile |
Bypasses the system file cache for data reads and writes | Requires sector-aligned buffer addresses, offsets, and transfer lengths; metadata may still be cached |
These flags are not interchangeable. FILE_FLAG_NO_BUFFERING is not the same as write-through. Microsoft notes that unbuffered I/O can make operations take longer because data is not retained in the system cache, and metadata may still require FlushFileBuffers.
Read the File Caching overview and the CreateFile flags documentation before selecting a flag.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choosing an approach
Keep ordinary cached I/O and flush at commit points
This is usually the simplest design. Write normally, then call FlushFileBuffers when the application reaches a point at which the data must be pushed onward. It avoids sector-alignment code and preserves the cache manager’s normal behavior.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Best Value
Open with write-through
Use FILE_FLAG_WRITE_THROUGH when the handle should request immediate flushing behavior as part of its write policy rather than relying on separate flush calls. Verify that this policy fits the application’s performance requirements.
Use unbuffered I/O
Use FILE_FLAG_NO_BUFFERING only when the application can satisfy the alignment rules and handle the added complexity. Buffer addresses, file offsets, and transfer lengths must meet the device’s sector-alignment requirements. Because metadata can remain cached, unbuffered data writes do not remove the need to consider FlushFileBuffers.
Quick Recap
Troubleshooting a failed flush
- Check that the handle is valid and refers to the intended disk file.
- Confirm that the handle was opened with
GENERIC_WRITE. - Check the Boolean return value from
FlushFileBuffers. - If it returns zero, call
GetLastError()immediately and handle the reported error rather than assuming the data is durable. - When using
FILE_FLAG_NO_BUFFERING, verify buffer address, offset, and transfer-length alignment in addition to checking the flush result.
What FFB cannot do
- It cannot force unrelated applications to flush their files; each application controls its own handles and I/O policy.
- It is not a registry tweak, command-line switch, or universal system-wide “flush everything” setting.
- It does not make a partial or failed write valid.
- It does not prove that every layer of every storage device will survive an extreme hardware or power-loss scenario.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
