From Newsgroup: alt.comp.os.windows-10

PSA - check if your crash logs are eating up your spare C: disk space

For whatever reason... I had "something" eating up disk space.
a. The moment I clear all files, C: filled up to zero spare bytes.
b. Time and again, for weeks on end this happened to varying degrees.
c. So I bit the bullet and dug into how to find the culprit.

Long story short:
The Windows Crash Log directory was filled with browser crash dumps.
<https://www.supportyourtech.com/articles/how-to-view-crash-logs-in-windows-10-a-step-by-step-guide/>

Many apps (including browsers) write dumps to:
A. %LOCALAPPDATA%\CrashDumps
B. %LOCALAPPDATA%\Microsoft\Windows\WER
C. %PROGRAMDATA%\Microsoft\Windows\WER

If desired, you can turn off crash dumps with this admin command:
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting" /v Disabled /t REG_DWORD /d 1 /f
--
Just one person paying it forward with clear lessons for a better PC.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Maria Sophia wrote on 1/2/2026 6:37 PM:

PSA - check if your crash logs are eating up your spare C: disk space

For whatever reason... I had "something" eating up disk space.
a. The moment I clear all files, C: filled up to zero spare bytes.
b. Time and again, for weeks on end this happened to varying degrees.
c. So I bit the bullet and dug into how to find the culprit.

Long story short:
The Windows Crash Log directory was filled with browser crash dumps.
<https://www.supportyourtech.com/articles/how-to-view-crash-logs-in-windows-10-a-step-by-step-guide/>

Many apps (including browsers) write dumps to:
A. %LOCALAPPDATA%\CrashDumps
B. %LOCALAPPDATA%\Microsoft\Windows\WER
C. %PROGRAMDATA%\Microsoft\Windows\WER

If desired, you can turn off crash dumps with this admin command:
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting" /v Disabled /t REG_DWORD /d 1 /f

Will you be writing a detailed tutorial?


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Maria Sophia <mariasophia@comprehension.com> wrote:

PSA - check if your crash logs are eating up your spare C: disk space

For whatever reason... I had "something" eating up disk space.
a. The moment I clear all files, C: filled up to zero spare bytes.
b. Time and again, for weeks on end this happened to varying degrees.
c. So I bit the bullet and dug into how to find the culprit.

Long story short:
The Windows Crash Log directory was filled with browser crash dumps.
<https://www.supportyourtech.com/articles/how-to-view-crash-logs-in-windows-10-a-step-by-step-guide/>

Many apps (including browsers) write dumps to:
A. %LOCALAPPDATA%\CrashDumps
B. %LOCALAPPDATA%\Microsoft\Windows\WER
C. %PROGRAMDATA%\Microsoft\Windows\WER

For me, the first folder was empty, the second folder did not exist, and
the third folder had subfolder, but no files.

If desired, you can turn off crash dumps with this admin command:
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting" /v Disabled /t REG_DWORD /d 1 /f

Or run the Power shell cmdlet "Disable-WindowsErrorReporting" (see https://learn.microsoft.com/en-us/powershell/module/windowserrorreporting/disable-windowserrorreporting).

As you mention, edit the registry to disable error reporting. 0 (zero)
is the default if the Disabled data item is not defined. Define and set
to 1 to enable the disable.

Mine was already set to 1, but I don't remember doing it via regedit.
Probably set it long ago since I see no value to sending Microsoft
information they likely would not review, and even more so after they discontinued Windows 10.

Likely I used WinAero Tweaker under Behavior -> Error Reporting. Their
tweaks usually have a help article, and this one has an info page at:

https://winaero.com/disable-error-reporting-windows-10/

Under Control Panel\All Control Panel Items\Security and Maintenance,
you can check for a list of app crashes. After the above registry edit,
the "Check for solutions to problems reports" is "Off". Click on "View reliability history" to see the critical app crashes (which get rather
lost in all the other errors in Event Viewer).

There is also the "Windows Error Reporting Service" service you could
disable in services.msc, but unneeded if you do the registry edit.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

VanguardLH wrote:

Maria Sophia <mariasophia@comprehension.com> wrote:

PSA - check if your crash logs are eating up your spare C: disk space

For whatever reason... I had "something" eating up disk space.
a. The moment I clear all files, C: filled up to zero spare bytes.
b. Time and again, for weeks on end this happened to varying degrees.
c. So I bit the bullet and dug into how to find the culprit.

Long story short:
The Windows Crash Log directory was filled with browser crash dumps.
<https://www.supportyourtech.com/articles/how-to-view-crash-logs-in-windows-10-a-step-by-step-guide/>

Many apps (including browsers) write dumps to:
A. %LOCALAPPDATA%\CrashDumps
B. %LOCALAPPDATA%\Microsoft\Windows\WER
C. %PROGRAMDATA%\Microsoft\Windows\WER

For me, the first folder was empty, the second folder did not exist, and
the third folder had subfolder, but no files.

If desired, you can turn off crash dumps with this admin command:
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting" /v Disabled /t REG_DWORD /d 1 /f

Or run the Power shell cmdlet "Disable-WindowsErrorReporting" (see https://learn.microsoft.com/en-us/powershell/module/windowserrorreporting/disable-windowserrorreporting).

As you mention, edit the registry to disable error reporting. 0 (zero)
is the default if the Disabled data item is not defined. Define and set
to 1 to enable the disable.

Mine was already set to 1, but I don't remember doing it via regedit. Probably set it long ago since I see no value to sending Microsoft information they likely would not review, and even more so after they discontinued Windows 10.

Likely I used WinAero Tweaker under Behavior -> Error Reporting. Their tweaks usually have a help article, and this one has an info page at:

https://winaero.com/disable-error-reporting-windows-10/

Under Control Panel\All Control Panel Items\Security and Maintenance,
you can check for a list of app crashes. After the above registry edit,
the "Check for solutions to problems reports" is "Off". Click on "View reliability history" to see the critical app crashes (which get rather
lost in all the other errors in Event Viewer).

There is also the "Windows Error Reporting Service" service you could
disable in services.msc, but unneeded if you do the registry edit.

Thanks to Vanguard for adding useful details about disabling Windows
Error Reporting. His notes on the PowerShell cmdlet, registry values,
and the related Control Panel and services.msc locations give us all a
clearer picture of how WER behaves and how to turn it off cleanly.

One more technical note worth adding for anyone chasing down disappearing
disk space in addition to the WER folders mentioned above, is that Windows
has several other diagnostic locations that can quietly accumulate multi-GB files over time.

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.

C:\Windows\Memory.dmp
A full memory dump can be several gigabytes on its own.

%LOCALAPPDATA%\Temp
Some apps leave behind enormous temp files that never auto-clean.

If we want to keep crash dumps enabled but avoid runaway growth, we can
also limit dump size or restrict Windows to generating only mini-dumps.
That gives us useful diagnostic data without the multi-GB surprises.

For anyone trying to identify *which* app is repeatedly crashing, the Reliability Monitor (Win+R -> perfmon /rel) is another view in addition to Event Viewer. Repeated failures from the same process usually point to a
bad extension, plugin, or driver rather than Windows itself.

Finally, a PowerShell one-liner that helps surface the worst offenders:

Get-ChildItem -Recurse "$env:LOCALAPPDATA\CrashDumps",
"$env:LOCALAPPDATA\Microsoft\Windows\WER",
"$env:PROGRAMDATA\Microsoft\Windows\WER" |
Sort-Object Length -Descending |
Select-Object FullName,
@{Name="SizeMB";Expression={[math]::Round($_.Length/1MB,2)}} |
Format-Table -AutoSize

It's a quick way to see which dumps are consuming the most space and which applications are generating them.

Hopefully this helps someone else avoid the same "mysteriously shrinking
C: drive" rabbit hole.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On 03/01/2026 00:42, Hank Rogers wrote:

Maria Sophia wrote on 1/2/2026 6:37 PM:

PSA - check if your crash logs are eating up your spare C: disk space

For whatever reason... I had "something" eating up disk space.
-a a. The moment I clear all files, C: filled up to zero spare bytes.
-a b. Time and again, for weeks on end this happened to varying degrees.
-a c. So I bit the bullet and dug into how to find the culprit.

Long story short:
-a The Windows Crash Log directory was filled with browser crash dumps.
<https://www.supportyourtech.com/articles/how-to-view-crash-logs-in-windows-10-a-step-by-step-guide/>

Many apps (including browsers) write dumps to:
-a A. %LOCALAPPDATA%\CrashDumps
-a B. %LOCALAPPDATA%\Microsoft\Windows\WER
-a C. %PROGRAMDATA%\Microsoft\Windows\WER

If desired, you can turn off crash dumps with this admin command:
-a reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting"
/v Disabled /t REG_DWORD /d 1 /f

Will you be writing a detailed tutorial?

It's a pro version and for that you have to sit on his laps naked so
that he can park his penis in your ass properly!


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

I scan for *.dmp on the whole PC with Total Commander (display of
"system files" has to be activated).
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On Sat, 3 Jan 2026 10:57:16 -0600, VanguardLH <V@nguard.LH> wrote:

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.

Oh. Thanks, I had a couple of small ones of those from 2014. Trivial
use of space on a 3 TB drive but as they ere old I binned them anyway.

C:\Windows\Minidump
Traditional BSOD dumps. Usually small, but they add up.

I have never had a BSOD on this box but I did have two very small
dumps in this Folder. <Shrug>. As those, too, were from Pre-Cambriam
times, I removed them.

I hope Windows didn't treasure them.

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.

Yeah, well, I had one of those on an old Win-9x box some decades ago
but I've yet to have one on my "new" 2013 machine.

Thank you for prompting me to look.

In this case, it's the same filename, so the file, if it exists, gets >overwritten.

That may or may not be a good idea. It'll save HD space but if your
box is crashing a lot it may not always be the same program doing the
nasties.

Still, is anyone ever going to *read* a 64 GigglyBite memory dump? I
don't think I ever fully read one when they were 8 Meggies. I scanned
the first few lines, yes, but reading the entire dump was not
something I ever looked forwards to. :)

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.

Good stuff, Sir, thank you. :)

Uhhhmmm, it may be a rather good idea *not* to search for "Temp"
(without the quotes, in your chosen file-manager using C:\ as the
target.

Including things like "SystemProfile*" and "Template*", there could
be thousands of the buggers. :)

How do I know? Guess.

J.
--- Synchronet 3.21a-Linux NewsLink 1.2