Subject: Re: PSA - check if your crash logs are eating up your spare C: disk space
Maria Sophia <
mariasophia@comprehension.com> wrote:
If you're still seeing unexplained space loss, these are worth checking:
C:\Windows\LiveKernelReports
Kernel dumps can be hundreds of MB each, especially if a driver is
misbehaving.
C:\Windows\Minidump
Traditional BSOD dumps. Usually small, but they add up.
The dump files are datestamped in their filenames, so multiple minidump
log files could reside there.
C:\Windows\Memory.dmp
A full memory dump can be several gigabytes on its own.
In this case, it's the same filename, so the file, if it exists, gets overwritten. If present, it will be the size of your RAM, so disk
consumption depends on how much RAM you have. If, for example, you have
64GB of RAM, likely you also have 1TB, or lots more, for drive capacity,
so the loss for the memory.dmp file is likely trivial.
%LOCALAPPDATA%\Temp
Some apps leave behind enormous temp files that never auto-clean.
Same as %temp%. Any cleanup tool should wipe those files, except those
are currently inuse at the time of cleanup. Windows comes with
cleanmgr.exe. It even has its own scheduled task: Task Scheduler ->
Task Scheduler Library -> Microsoft -> Windows -> DiskCleanup. That is
only for %systemdrive%, but that is where is %temp%. It is a specially
coded scheduled task, so you can't see it triggers (what fires the
event). I forget how, but there is a way too look at such specially
coded scheduled events, but then you have to learn the syntax for the
code. I haven't done that in many years.
Be careful about blindly deleting files in %temp%. I've seen installers
that put some files there which are accessed after a reboot to replace
inuse files. They add to the PendingFileRenameOperations registry key
which Windows checks on startup to see if files are to get renamed,
moved, or deleted. On a move, obviously the file needs to exist
somewhere, so some installers put them in %temp%. After the move, the
file is no longer in %temp%. If you do the install, and then a cleanup,
the replacement file(s) may be missing on the Windows restart, so the
install is incomplete.
The cleaners should NOT delete any inuse files. Programs may create "temporary" files which they expect to be present while the program is
running. The file is temporary only in as long as the process still
exists and maintains a lock on the file. The program may not delete the
temp file on its exit, and why you need a cleaner.
Disk Cleanup (cleanmgr.exe) might catch temp files when not inuse. It
is a scheduled cleanup (but I don't know what are its triggers). I also
have CCleaner scheduled to run every night since I have control over its triggers; i.e., when it runs, or what event(s) triggers it. By default, temporary files are included in the cleanup.
CCleaner is configured to included deletion of dump files, but I don't
know if that is the default, or I enabled that option.
If you even run chkdsk (and there are scheduled events, too), there can
be chkdsk file fragments left behind (found.<nnn>, where <nnn> is a
3-digit number). I have CCleaner delete those, too, as well as an error reporting files (although I have that disabled, anyway). If my file
system gets corrupt, and chkdsk tries to rescue parts of files, I'd
rather have the full good-copy of files from my backups (scheduled to
run every day). Usually chkdsk file fragments aren't useful except for
plain text files, and that filetype is typically not critical.
It isn't just dump or temp files that can consume a drive. For example,
I've used SysInternals Process Monitor to log what process is accessing
or creating a file. That is just a filter for what to *view* in the
log. The entire log of ALL events is still getting recorded, so PM's
log can get huge. Eventually it will eat up all the drive. Use it,
generate the events you're suspicious of or watch for a short time,
disable event logging, do your analysis, and then delete the log. Don't
leave PM running when you're not diagnosing file operations.
Because you may not know some process is generating huge-sized files, or
lots of files accumulating to lots of drive consumption, or where are
those drive-consuming files, a tool that shows where is the largest
consumption helps to track down the culprits. I currently use WizTree,
but have used TreeSize. Some have used WinDirStat which I only briefly reviewed, and discarded (don't remember why). Another is SequoiaView
whose cushioned bubble view representing size for each bubble is also
seen in WizTree, and WinDirStat. It isn't just %temp%, or other
standard locations where programs can amass huge-sized files. Some
folks forget how large is their video library, or keep storing
little-used files on their C: drive under Documents instead of moving
off to some other storage, like another internal or external drive.
--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)