11

Update: Moving the following folders off drive then symlinking them eliminated the constant writing to C:.

  • %LocalAppData%\Google\Chrome - Easily the biggest consumer.
  • %LocalAppData%\Microsoft\Windows\FileHistory

I moved them to a freshly formatted drive. After 3 hours there has already been 10.5GB of reads and 10.3GB of writes. In that same time, Drive C:\ has only seen 3.5GB of reads and 1.3GB of writes.

This has been bugging me for a while. Windows 10 Education seems to constantly write data to the C:\ drive for no apparent reason, even when the PC goes unused for days at a time. I can't find the source of the writes or the data it writes.

In just 9 months 10% of the 500GB Samsung 850Evo's drive life has been consumed. Is this because Windows is doing a lot of logging and tracking in the background? If that's the reason, I'd like advice on how to disable it. I feel there's nothing else left that I could move off the C:\ drive (more on this in the breakdown)

HWInfo64 has been running the past 12.75 days(w/14-days uptime) to track drive stats. During this time the PC was not touched from July 1st to July 5th or July 8th. I figure the max possible time in use is about 5 days because during the weekdays it's sitting untouched for at least 18hrs.

Here's a breakdown of most of the drives:

  • 500GB Samsung 850Evo(Age: 0.7yr | HostWrites: 13.3TB(~50GB/day))
  • C:\ In past 2 weeks: Nothing new installed, but 900GB(64GB/day) was written. That's 180GB/day for 5 usage days. ShadowCopy(System Restore) is set to 10% and there is no FileHistory for this drive.
  • 500GB Samsung 850Evo(Age: 1.7yr | HostWrites: 8.6TB)
  • A:\ Important data and UserProfile folders are mapped here. This is the only drive with FileHistory enabled. ShadowCopy(System Restore) is set to 15%.
    This was once a Windows 7 C: drive for about a year.
  • 250GB Samsung 840Evo(Age: 3.7yr | HostWrites: 10.5TB) & 256GB Crucial m4(Age: 4.8yr | HostWrites: 25TB)
  • D:\ Drives are pooled to create a Stripped StorageSpace(raid0). The PageFile, TEMP folders, SoftwareDistribution, NodeJS/npm, Origin, Steam, and Recorded TV are stored here. There is no ShadowCopy(System Restore) or FileHistory for this drive.
  • Under Windows 7 each drive was a system drive at one time, the 840Evo for a year and the m4 for 3yrs. The m4 has just started failing in the last 30 days and will often drop offline during heavy writes. The HWInfo stats even show its not pulling it's weight. StorageSpaces manages the drive well enough that I haven't got around to removing the drive yet. This is after only 25TB of HostWrites in a 5yr period, the 850Evo is already half way there. This is the motivating factor behind this question.
  • 4TB HGST Deskstar(Age: 2.6yr | HostWrites: 17TB) & 4TB HGST Deskstar(Age: 0.75yr | HostWrites: 7TB)
  • B:\ & M:\ Drives are pooled to create a 2TB Stripped and a 3TB Mirrored StorageSpace respectively. Neither volume has FileHistory or ShadowCopy protection. Movies, Music, and etc. are stored on B:\n. M:\ is the backing store for all FileHistory with changed files being versioned and backed up to it every 10 minutes.

As you can see, Windows 7 wrote nowhere near as much data. Here's a screenshot of HWInfo64.

HWInfo64 screenshot

Improve this question
1

3 Answers 3

Reset to default
4

You can use Task Manager to see what processes are writing the most data to disk.

Open Task Manager, select the Details tab, right-click on the table header, and click Select columns. Then check I/O read bytes, I/O write bytes, and I/O other bytes and click OK.

That said, I think File History is to blame here.

In my experience, the File History databases (Catalog1.edb and Catalog2.edb) can grow very large over time. To make matters worse, they are rewritten in their entirety every time the history is updated (every 10 minutes as configured on your system), and Windows will decompress them if you use NTFS compression. This can cause large amounts of writes to the disk over time.

Regardless of which drives are covered by File History, these databases are stored in your user profile at C:\Users\<username>\AppData\Local\Microsoft\Windows\FileHistory\Configuration. With a pair of 100 MB databases, nearly 30 GB a day will be written to the system volume at 10 minutes per update, assuming it writes both files every time.

My solution was to use a junction point. Stop the File History service, move the Configuration folder to another location where write endurance is not an issue, create a junction point that points to the new location in place of the original location of the folder, and restart the File History service. That should fix the problem.

Improve this answer
3
  • 2
    As an addendum, Resource Monitor gives far more detailed information and is less likely to leave out processes that might not show in task manager. It can be accessed from the Task Manager > Performance > Resource Monitor > Disk. As Resource Monitor is exactly intended for tracking down such problems it has filtering features and details that Task Manager leaves out.
    – Cliff Armstrong
    Jul 14, 2017 at 2:37
  • I think you're on to something and might be right. Each Catalog#.edb file on C: is 576MB and 588MB on M: The thing with ResourceMonitor is that it only shows instantaneous writes, not total writes. It appears the writes (in order) seem to be to $Logfile, system32\winevt\logs, system32\LogFiles, $Mft, $BitMap, ntuser.dat, and SystemVolumeInformation
    – Derek Ziemba
    Jul 14, 2017 at 5:06
  • Is there a way to easily clean up certain FileHistory folders? It goes back to last December and iincludes unnecessary things like Downloads and the entire AppData\Roaming folder.... which is apparently where all my space was going 1kb file at a time. I figure if there's less files to keep track of it would decrease the Catalog#.edb file sizes? There's some things I like having go back to forever like My Document and Dropbox though. I figure there's a be a better way to remove them than just deleting the corresponding file history folders right? And that's a shotgun approach.
    – Derek Ziemba
    Jul 14, 2017 at 5:25
1

You can potentially save a few more GB per day by disabling/redirecting WFP and NetCore logs :

(Info was found here: How to disable Windows 10 system log)

1. C:\Windows\System32\LogFiles\WMI\NetCore.etl get constantly written, especially when multiple apps are open. You can redirect it to another drive with the following command:

logman update trace NetCore -ets -o X:\Some_dir\NetCore.etl

If you reboot you will need to launch the command again. So i created a (elevated) scheduled task on session start.

2. C:\ProgramData\Microsoft\Windows\wfp\wfpdiag.etl get constant writes too. You can simply disable the log :

netsh wfp set options netevents = off

3. I also disabled the NFTS last access (disabled in Vista/7 and reintroduced in 10) but i think it is negligible :

fsutil behavior set disablelastaccess 3

(default is 2)

Improve this answer
0

Windows has built in update sharing system make sure you have that turned off.

Settings > Update & Security > Windows Update > Advanced options > Choose how updates are derived.

Update sharing

Also make sure you don't have windows backup system turned on.

Settings > Update & Security > Backup.

Improve this answer
3
  • 1
    They're both enabled but I don't think they'd affect host Writes to C:\. Nevertheless I disabled the Software Distribution feature. I've also updated my main post for better clarity.
    – Derek Ziemba
    Jul 14, 2017 at 0:28
  • 1
    distribution would only affect reads not writes, and that's still comparable (probably less) to just having a torrent application open
    – Blaine
    Jul 14, 2017 at 0:55
  • In Windows 11 this is present in Windows Updates > Advance options > Delivery Optimization
    – Uttkarsh Patel
    Feb 5, 2023 at 10:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .