How to save your SSD in Windows.
When Windows Starts, it saves a lot of files on the hard disk, including log files. Windows is not a savvy operating system.
Windows writes those log files in the next folder:
%SystemRoot%\System32\Winevt\Logs
Most of those files weigh 1KB, so it does not affect and impact the performance of the hard disk. Windows simply writes a part of the code. However, we are not using a hard disk anymore but SSD.
When we use a hard disk, then the Log Event does the next job:
It reads the file.
And it adds the next log registry in the last disk block of the log file
If the block is full, then it creates a new block.
When we use an SSD, the Log Event does the next job:
It reads the file
And it modifies the last disk block. SSD has its own blocks that are also modified. Every modification wears out the block. The SSD drive could also trim the block by moving to another part of the disk and wearing the SSD but avoiding wearing the same block many times.
If the block is full, then it creates a new block. If the SSD block is also full, then it creates a new block.
Size
Now, let's say the size of the log is 1kb. That is the logical size, not the physical size. The partition system works in blocks of 4kb, so every time we write a file less or equal to 4k, we use 4kb. I.e. our log is 4kb or more.
You can check the size using PowerShell
Get-CimInstance -ClassName Win32_Volume | Select-Object Label, BlockSize | Format-Table -AutoSize
But the SSD has its own blocks. The common size is 512KB. So, if our log is 1k, then we are impacting the whole 512KB SSD block.
Even if the log does not change in size, then every modification will still impact this 512KB block.
Event Log
Windows uses over 300 event log files. However, not all logs are written every day. However, at least 80 logs are written every day.
So, in the worse case, we are writing 80 SSD blocks every day, and sometimes it is hitting it constantly. The event log is an SSD killer, no matter if you are using it or not the computer, it is constantly writing files in the log files.
But What I can do?
It is not possible to disable the service of the event log. However, we could limit its usage.
If you open the Event Viewer, then you will see that there are 5 log files. In fact, there are many more hidden in Application and Services Log.
The main log files can't be disabled but we can limit it
If you go to the property, then we could limit its size. The size makes sense for a conventional hard disk but not for an SSD. So, we don't want to limit the size but to limit any writing. So, we should use the option "Do not overwrite event". This does the next job: if the log file is filled, then it stops writing.
Another alternative is to send the log to "nul" file. I have not tested it but in theory, it should work.
Now, if you open Application And Services Log -> Microsoft, you will see that there are MANY log files used by different programs and services. We could disable each file separately but it will take a lot of time.
EventLogChannelsVIew is a free program and it works to disable the rest of the logs.
This program is unable to disable all logs but it works with most of them.
Select all the channels enabled.
Right button -> Disable. It could show many "error 87" but it will work with most channels.
Security
But, is it safe to disable the event log? The event log gives security if anybody reads and analyzes the log.
Question: How many times have you read the log files?
If you work in a managed infrastructure (Domain), then the system administrator will read the file. However, in this case, the sysadmin will not allow you to edit the event log.
Let's say you usually don't read the log file but you have some trouble with a program or service and you need to read the log file. It is not a problem. In case you need to read the log, then you can enable it back.
End note:
It works with a simple exception: Security.evtx
I tried to limit the writing in security.evtx (Security)
Limiting the size: No, it doesn't work
Changing the file: Not, it doesn't work.
Disabling it: Unable to disable it.
While the security log hasn't added a new entry, the file somehow has been edited. I think Microsoft is doing something "undocumented" again.
