Fast Startup gets blamed for a surprising amount of SSD wear, mostly because it hiberfil.sys is sitting right there taking up several gigabytes. During shutdown, Windows signs you out, saves the kernel session and loaded drivers to that file, then restores them on the next boot.

The useful bit is what Windows leaves behind. Your open apps and full user session aren’t part of the Fast Startup snapshot, which is why Microsoft can shrink hiberfil.sys with Windows’ reduced hiberfile mode. If SSD writes are what you’re worried about, there are several Windows workloads I’d start monitoring before I bothered to switch Fast Startup off.

Full hibernation saves a lot more state

Fast Startup and Hibernate get lumped together because both use hiberfil.sys, but Hibernate gives Windows a much bigger job. Fast Startup signs you out first, then saves the kernel session and loaded drivers. If you’re curious about what Windows actually stores when it hibernates, the full mode must preserve enough system state to restore your applications, documents, windows, and user session to where you left them.

You can see the difference in how Windows sizes the hibernation file. Microsoft’s current default for a reduced hiberfile, the type used for Fast Startup, is 20 percent of physical memory. A full hiberfile defaults to 40 percent. I wouldn’t read those percentages as “Windows writes exactly this much every time,” because they’re file-size defaults rather than a measurement of each individual write. They do make the difference between the two modes pretty obvious.

Frequency is where full hibernation really starts pulling away. Fast Startup kicks in when you shut down the PC. If your laptop is set to hibernate when you close the lid, Hibernate might run three or four times during the same working day. If that happens regularly, those hibernation writes can pile up pretty quickly. A laptop that keeps hibernating throughout the day has far more opportunities to save the full system state than Fast Startup does from the occasional shutdown.

Windows Search can hammer the drive during a large indexing job

Every file wants its turn

Windows Search keeps its index database under C:ProgramDataMicrosoftSearchDataApplicationsWindows. Windows 11 calls the database Windows.db, while Windows 10 uses Windows.edb.

That database holds considerably more than a list of filenames. Windows Search indexing can include file properties and searchable content, so Start and File Explorer don’t have to dig through every location from scratch each time you search.

Most of the time, you won’t have much reason to care. Give Search a massive batch of new files, rebuild the index, or point it at a library containing hundreds of thousands of items, and it suddenly has plenty to do. Windows has to crawl through those locations, pull out whatever metadata and searchable content applies, then keep updating the index database as it goes.

Microsoft warns that Windows Search can struggle once its index grows past 400,000 items, and the database grows considerably as that number climbs. Photo archives are an obvious example, but source-code repositories, email stores, document collections, and folders full of tiny files can all make the indexer work much harder.

Windows Update involves much more disk work than downloading a patch

The restart is only the visible part

Windows Update looks simple from the outside. A percentage climbs to 100, Windows asks for a restart at the worst possible time, and eventually you get your desktop back.

There’s quite a bit of disk work buried underneath that process. As I said earlier, Windows has to store and stage downloaded Windows Update files, install new component versions, update servicing metadata, and maintain the component store under C:WindowsWinSxS. Previous component versions also stick around for a while because Windows still needs them for servicing.

You shouldn’t use the size File Explorer reports for WinSxS as proof of anything, though. The component store relies heavily on hard links, so Explorer can make the folder appear much larger than the storage it actually occupies. Microsoft recommends using DISM’s component-store analysis if you actually want to know how much space it’s using.

The WinSxS number isn’t really what I’m interested in here anyway. The servicing work is. Windows has to stage and install the new components first, then it comes back later to handle the versions it’s replaced. The automatic StartComponentCleanup task normally waits at least 30 days before removing an updated component’s previous version, and some superseded components can be compressed during cleanup. So one update can touch the drive in several rounds. There’s the download and staging work, the installation itself, then maintenance that may happen weeks later.

You probably won’t notice much if your PC stays current and the updates are relatively small. Bring an old laptop back online after a few months, install a large cumulative update, or let servicing pile up for a while and the SSD can stay busy for a lot longer than the restart screen suggests.

OneDrive can turn cloud files into gigabytes of local writes

The cloud has to land somewhere

OneDrive Files On-Demand can keep files off your SSD until you need them. You can still see them sitting in File Explorer without keeping all of their contents locally. If you open an online-only file, OneDrive downloads it locally. A few Word documents won’t move the needle much. A big project folder, photo archive, or video library absolutely can.

If 40GB of files are currently online-only and you mark them to remain available offline, OneDrive now has roughly 40GB of data to pull down to local storage. Restoring a large synced library to a new PC can be the same sort of workload on a much larger scale.

OneDrive sync conflicts can create duplicate copies, which can add extra writes. When it can’t safely reconcile competing versions, it may create an additional copy instead of discarding one. That’s easy to shrug off when we’re talking about a couple of spreadsheets. It’s much less funny when the files are videos, archives, project assets, or giant folders containing thousands of items.

I’ve always found this a much more useful thing to watch than hiberfil.sys if OneDrive suddenly starts looking busy. A cloud library can come pouring back onto the SSD while the only obvious clue is that little sync icon in the taskbar refusing to settle down.

The page file can get very busy when RAM runs short

Your SSD becomes the overflow room

Windows also keeps a paging file, usually pagefile.sys, and uses it as part of virtual memory when RAM runs short. Having one doesn’t mean Windows spends the whole day dumping RAM onto your SSD. If you’ve got plenty of memory and your workload stays comfortably below the limit, page-file writes might barely register.

Things change once memory pressure starts building. Windows can write memory pages out to disk, so physical RAM can be reused elsewhere. Microsoft even exposes counters such as Pages Output/sec specifically for tracking pages being written during that process.

This can get pretty active on machines with limited RAM. An 8GB laptop juggling dozens of browser tabs, Photoshop, Teams, a couple of Electron apps, and whatever else you’ve forgotten to close can spend a lot more time paging than a 32GB machine running the same workload. Virtual machines, large creative projects, memory-hungry games, and software with leaks can push it even harder.

What I’d pay attention to here is how long that activity can keep going. Fast Startup gets its chance when you shut down. Page-file activity can keep going for hours if the machine spends the afternoon short on RAM. I wouldn’t buy more memory purely to save your SSD from writes. If you’re trying to figure out why disk activity stays high while you’re working, though, sustained paging deserves a much closer look than Fast Startup usually gets.

Fast Startup is pretty far down my suspect list

hiberfil.sys makes Fast Startup look guilty because it’s large, easy to find, and obviously tied to something Windows writes during shutdown. I can see why people land on it first.

Once you look at what the rest of Windows actually writes to disk, you’ll find that Fast Startup is one of the less interesting things going on. A laptop can hibernate several times in one day. Search can take hours to rebuild an index. Windows Update installs new components and comes back weeks later to clean up old ones. OneDrive can pull an entire cloud library onto local storage. A machine running short on RAM can keep writing pages out for hours.

The exact mix will be different on every PC. A desktop with 64GB of RAM might barely bother its page file, while an 8GB laptop could lean on it constantly. Someone indexing a few thousand documents won’t see anything close to the workload of a system chewing through half a million files.