XPost: alt.comp.microsoft.windows   
   From: V@nguard.LH   
      
   Maria Sophia  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., where  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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)