Malwarebytes 3.5.1 suddenly slowing down my system!

[Mbag3rd]

Up until the last few days, things have been going well. However, in the last several days, I find that Malwarebytes has been slowing down my system. I find that CPU utilization on the main service module (MBAMService.exe) has been at 25-30% constantly, causing delays in the graphics processing and screen repainting, and delays in URLs being processed by my browser (Firefox 60.0.1 (64-bit)).   This, without any manual scanning in progress.

The following are the particulars:

Malwarebytes Version: 3.5.1.2522

Component Pkg Ver:  1.0.365

Update Pkg. 1.0.5188

 

System:  Windows 7 Ultimate 64 bit with latest service packs on an Intel CoreI5  processor, 8gig of RAM,

I will try rebooting, but if this is part of a recent automatic update, we need to have you take a look at it.

Thanks.
 

[Malwarebytes]

***This is an automated reply***

Hi,

Thanks for posting in the Malwarebytes 3 Help forum.

 

If you are having technical issues with our Windows product, please do the following: 

Spoiler

If you haven’t already done so, please run the Malwarebytes Support Tool and then attach the logs in your next reply:

NOTE: The tools and the information obtained is safe and not harmful to your privacy or your computer, please allow the programs to run if blocked by your system.

• Download Malwarebytes Support Tool
• Once the file is downloaded, open your Downloads folder/location of the downloaded file
• Double-click mb-support-X.X.X.XXXX.exe to run the program
  • You may be prompted by User Account Control (UAC) to allow changes to be made to your computer. Click Yes to consent.
• Place a checkmark next to Accept License Agreement and click Next
• You will be presented with a page stating, "Welcome to the Malwarebytes Support Tool!"
• Click the Advanced Options link
  
• Click the Gather Logs button
  
• A progress bar will appear and the program will proceed to gather troubleshooting information from your computer
• Upon completion, click OK
• A file named mbst-grab-results.zip will be saved to your Desktop
• Please attach the file in your next reply. Before submitting your reply, be sure to enable "Notify me of replies" like so:
     
  
  Click "Reveal Hidden Contents" below for details on how to attach a file:
  Spoiler

  To save attachments, please click the link as shown below. You can click and drag the files to this bar or you can click the choose files, then browse to where your files are located, select them and click the Open button.

  

One of our experts will be able to assist you shortly.

 

If you are having licensing issues, please do the following: 

Spoiler

For any of these issues:

• Renewals
• Refunds (including double billing)
• Cancellations
• Update Billing Info
• Multiple Transactions
• Consumer Purchases
• Transaction Receipt

Please contact our support team at https://support.malwarebytes.com/community/consumer/pages/contact-us to get help

If you need help looking up your license details, please head here: https://support.malwarebytes.com/docs/DOC-1264 

 

Thanks in advance for your patience.

-The Malwarebytes Forum Team

[Mbag3rd]

Scan files attached.

mbst-grab-results.zip

[vbarytskyy]

Hello @Mbag3rd,

Could you do the following for me:

1. When the computer is using a lot of CPU, open Task Manager
2. Go to the Processes tab and find mbamservice (you may have to click "show processes from all users)
3. Right click mbamservice and choose Create dump file
4. This could take a little while, but once it's done, it should give you a path to a .dmp file
5. Zip up this .dmp file and upload it to wetransfer.com, and generate a download link

 

Also--I noticed that your Malwarebytes installation in not in the default directory (C:\Program Files\*). 

[exile360]

In addition to the default, can you also try disabling just the Ransomware Protection component (right-click the Malwarebytes tray icon and click Ransomware Protection: On then click Yes to the User Account Control prompt) to see if that eliminates the issue?  I'm tracking issues with this component and want to see if this case is related.

Thanks

[Mbag3rd]

On 5/22/2018 at 10:21 AM, vbarytskyy said:

Hello @Mbag3rd,

Could you do the following for me:

1. When the computer is using a lot of CPU, open Task Manager
2. Go to the Processes tab and find mbamservice (you may have to click "show processes from all users)
3. Right click mbamservice and choose Create dump file
4. This could take a little while, but once it's done, it should give you a path to a .dmp file
5. Zip up this .dmp file and upload it to wetransfer.com, and generate a download link

 

Also--I noticed that your Malwarebytes installation in not in the default directory (C:\Program Files\*). 

A status update - Rebooting my system seems to have resolved the problem, as I suspected. It's been running fine, ever since (i.e. as it ran before) without changing any settings or options.  But, should it happen again, I'll create a .dmp file and attach it. And, I suspect it will.  This wasn't the first time, and it won't be the last.

As for my "installation directory," I don't believe that's a factor in this issue, at all.  I, for one, am not a huge fan of "default directories" especially on Drive C:\.  I prefer to keep C:\ only for WIndows system components (or related modules) and install apps on a different drive. To be honest, I'm a little frustrated with software/app manufacturers that force the install onto Drive C:\ and don't give me a choice. I know why mfgrs like it (for support reasons), but I can't recall the last time the install directory location was ever a factor therein.  Forcing things onto C:\ conflicts with my backup & security strategies. Drive C:\ will always be a "system image" backup for obvious reasons, where the other drives (including the one on which the other apps are installed) need not necessarily be.  The smaller I can keep Drive C:\. the smaller the system image file and the quicker the time it takes to backup/restore.  Also, C:\ drive is the drive most likely to be "corrupted" by malware or even a physical hardware corruption/failure. From a Malware standpoint, Drive C:\ is a much easier and more well known target because of all those "default" directories. I'd rather do something different. It certainly won't be fool proof, but it might help defeat any amateur malware attempts.  If I could, I'd move the "C:\Users" directory to a different drive as well, (and I know there's a way to do it), but that would be too risky in re: keeping things working. By separating Windows system components, from installable apps from data, I lessen the risk of damage and data loss from a HD physical corruption or, perhaps from malware attacks, and my system image backups take far less time. 

Thank you for your assistance. I'll keep you posted on the original issue.

Edited May 24, 2018 by Mbag3rd

[Mbag3rd]

On 5/22/2018 at 10:21 AM, vbarytskyy said:

Hello @Mbag3rd,

Could you do the following for me:

1. When the computer is using a lot of CPU, open Task Manager
2. Go to the Processes tab and find mbamservice (you may have to click "show processes from all users)
3. Right click mbamservice and choose Create dump file
4. This could take a little while, but once it's done, it should give you a path to a .dmp file
5. Zip up this .dmp file and upload it to wetransfer.com, and generate a download link

 

Also--I noticed that your Malwarebytes installation in not in the default directory (C:\Program Files\*). 

The problem returned today. I would send you the DMP file, but it came out to be 108KB (even with "enhanced deflate" compression), which exceeds your file transfer limit. If there's another way I can send it (by email, perhaps), please let me know and I'll do that.

 

[exile360]

You can use wetransfer.com, they allow files up to 2GB in size.  Just upload it there with the Send as option set to Link and once it's uploaded post the link here in your reply (to get to the options you must click I Agree then click the ... button).

[bdg2]

On 5/24/2018 at 4:41 AM, Mbag3rd said:

A status update - Rebooting my system seems to have resolved the problem, as I suspected. It's been running fine, ever since (i.e. as it ran before) without changing any settings or options.  But, should it happen again, I'll create a .dmp file and attach it. And, I suspect it will.  This wasn't the first time, and it won't be the last.

As for my "installation directory," I don't believe that's a factor in this issue, at all.  I, for one, am not a huge fan of "default directories" especially on Drive C:\.  I prefer to keep C:\ only for WIndows system components (or related modules) and install apps on a different drive. To be honest, I'm a little frustrated with software/app manufacturers that force the install onto Drive C:\ and don't give me a choice. I know why mfgrs like it (for support reasons), but I can't recall the last time the install directory location was ever a factor therein.  Forcing things onto C:\ conflicts with my backup & security strategies. Drive C:\ will always be a "system image" backup for obvious reasons, where the other drives (including the one on which the other apps are installed) need not necessarily be.  The smaller I can keep Drive C:\. the smaller the system image file and the quicker the time it takes to backup/restore.  Also, C:\ drive is the drive most likely to be "corrupted" by malware or even a physical hardware corruption/failure. From a Malware standpoint, Drive C:\ is a much easier and more well known target because of all those "default" directories. I'd rather do something different. It certainly won't be fool proof, but it might help defeat any amateur malware attempts.  If I could, I'd move the "C:\Users" directory to a different drive as well, (and I know there's a way to do it), but that would be too risky in re: keeping things working. By separating Windows system components, from installable apps from data, I lessen the risk of damage and data loss from a HD physical corruption or, perhaps from malware attacks, and my system image backups take far less time. 

Thank you for your assistance. I'll keep you posted on the original issue.

The "Program Files" directories exist because they have permissions set so that malware is less able to meddle with and infect your programs.

For that reason I take the opposite view to you and get annoyed with people who write Windows programs that won't work right if installed in "Program Files".

I need to be given a very good reason before I will consider installing software anywhere else.

[Mbag3rd]

4 hours ago, exile360 said:

You can use wetransfer.com, they allow files up to 2GB in size.  Just upload it there with the Send as option set to Link and once it's uploaded post the link here in your reply (to get to the options you must click I Agree then click the ... button).

Thanks..   Link as follows:  ---->   https://we.tl/OzUaPHAjVu

[Mbag3rd]

54 minutes ago, bdg2 said:

The "Program Files" directories exist because they have permissions set so that malware is less able to meddle with and infect your programs.

For that reason I take the opposite view to you and get annoyed with people who write Windows programs that won't work right if installed in "Program Files".

I need to be given a very good reason before I will consider installing software anywhere else.

I tend to think it was setup more to facilitate support calls than any other reason. It's a lot easier to resolve support issues if everything is installed where the mfgr expects it to be. From a "permissions" perspective, it really shouldn't matter where a program is installed. Those permissions can be replicated in any install directory if it's that important. Still, any malware worth their salt would be able to install a rootkit and become the highest security user and bypass those permissions.  I've been working with PC's  even before the advent of  the original IBM PC.  And I've never had a malware issue that involved an attack based on where a program was installed.  Never. 

My "very good reason" is to facilitate a more streamlined backup strategy as well as have some protection against Drive C:\ suffering a corruption failure (either physical/hardware or by malware infection).  Drive  C:\ has to be backed up differently than the other drives (must use a "system image:" on C:\). The other drives can be backed up via other means. I want to keep the size of the C:\ system image file as low as possible.  So I put my programs (that I can) and my data files elsewhere. Additionally, since Drive C:\ is the drive most utilized, it's more likely to suffer hardware failure/corruption or other issue. I'd much rather mitigate any data loss by keeping data and programs files elsewhere.  

I understand that it's a preference for both of us and we have different preferences. That's OK.  All I ask is to be allowed a choice as to where to install. Don't force the install on a directory the mfgr chooses.  Let the PC owner make that choice for themselves.

Edited June 3, 2018 by Mbag3rd

[exile360]

There are a few different issues with your approach, but with that said, there's absolutely no reason at all that Malwarebytes shouldn't work perfectly fine installed in a different folder, or even on a different drive from Windows.  In the past, with many 1.x builds of Malwarebytes Anti-Malware this was a problem, but today, with the current version of the product, it absolutely should not cause any issues at all, and if it does, then it is a bug and should be reported so that our Dev and QA teams can investigate.

Now, with all of that said, there are a few issues with your approach of installing software on a separate drive, especially certain specific types of software like security software that make it more likely that if you ever do have to restore from an image, things won't be as pristine as you might think or might desire (I know this from personal experience having long used similar techniques myself, and preferring portable applications installed on a separate partition from Windows when possible).  First is the registry.  Most applications, including Malwarebytes, store at least some configuration settings in the registry, and whenever you create an image backup of your system drive you have no choice but to back up the registry hives with it (refer to this for more info).  Also, specifically with regards to security software, and this is just as true of Malwarebytes, several drivers are often stored in the System32\drivers folder and these files cannot be moved/installed to a different location, so they will always reside on the same drive as the active Windows installation.  Also, because Malwarebytes stores a few of its settings in the registry but stores the vast majority within config files within the ProgramData folder (also located on the same drive as Windows, at least by default), if one were to perform an image restore or even just a more standard System Restore, it is very likely that you'd end up having to reinstall Malwarebytes due to the synchronization issues that would occur due to differences in the current date/time information and other factors.

You also must consider that, if it really comes down to it, would you have a reason not to have Malwarebytes installed following an image restore, especially when Malwarebytes has a fairly clean uninstallation as it is and even provides a clean uninstall utility specifically for that purpose, and it works even if the Malwarebytes uninstaller is broken or missing.  You also should consider that if it is a function of attempting to save space on your primary drive for some reason (like attempting to keep boot times fast etc.), the files stored in Malwarebytes program directory are currently around 150MB, at least on my system with the latest version, yet its data folder is around the same size, so moving the program folder still leaves an equal amount of space on the system drive, not including the drivers in System32\drivers.  Also, with regards to drive activity, the data folders are modified far more frequently than the program directory since that is where the signatures, logs, settings and quarantine are stored, so if drive wear is a concern you'd be better off leaving Malwarebytes installed on C: and moving the ProgramData folder elsewhere (and this is true of most other apps as well).

Now, with all of that said, again, there is absolutely no reason that you shouldn't be able to have Malwarebytes installed on a separate drive/partition, I just wanted to make sure that you have the entire picture because while one might think that changing the primary installation directory for a program ensures that it won't occupy much (or any) space on their system drive, it is unfortunately the case that this is often not true due to additional files and data which are stored elsewhere, especially with applications like AV/AM products which tend to store a lot of data, including logs, signatures, drivers, quarantined threats and other data in other locations on the system drive so installing it elsewhere is nowhere near the same as using a portable application, which I'm guessing is sort of the goal here, where you're basically trying to keep the Windows drive as clean of third party content as possible, which is perfectly understandable as it's something I strive for myself (not to mention that it's a lot quicker and easier to wipe/restore a system when most of my apps are portable and thus require no re-installation/re-configuring following a system format).  I just know from experience that, at least with Malwarebytes due to the sync issues, it can often be more trouble than it's worth, though you may not find this to be the case.

As for theories about why programs install by default to the Program Files directories, that's quite simple, and it has nothing to do with attempting to generate any support calls: it is because it is Microsoft's recommendation to developers that they store their files there, just as they recommend specific locations in the registry be used for an application's settings, and while not all applications necessarily follow these recommendations, most do, however as I said, you may install Malwarebytes in a different location if you wish, though the majority of activity actually takes place in its data folder as I mentioned previously.

Apologies for the massive "wall-o-text", but I figured I'd be thorough just to explain why it is the way it is and hopefully inform you about a few more details you may not have been privy to which might prove helpful, especially if you do want to minimize activity on your C: drive.

[Mbag3rd]

10 hours ago, exile360 said:

There are a few different issues with your approach, but with that said, there's absolutely no reason at all that Malwarebytes shouldn't work perfectly fine installed in a different folder, or even on a different drive from Windows.  In the past, with many 1.x builds of Malwarebytes Anti-Malware this was a problem, but today, with the current version of the product, it absolutely should not cause any issues at all, and if it does, then it is a bug and should be reported so that our Dev and QA teams can investigate.

...

Apologies for the massive "wall-o-text", but I figured I'd be thorough just to explain why it is the way it is and hopefully inform you about a few more details you may not have been privy to which might prove helpful, especially if you do want to minimize activity on your ? drive.

Not at all, and I appreciate your taking the time to provide that explanation. 

I get the role that the registry plays and why it's important for that to be in sync with whatever programs are installed (and wherever they're installed). I also get that some files are always installed on the C:\ Drive (DLLs, common files used among multiple apps, etc.), no matter where the main app modules are installed. And, for those reasons, I also system image the app drive as well as C:\, so that both are always in sync with the other. Both will always be backed up and restored together, if needed. Still, I'll continue to maintain the separation of apps modules vs. system modules wherever possible (especially for apps where the registry isn't a significant factor). I'm just trying to be very careful about how big the C:\ drive gets, and I'm frustrated that some apps mfgrs feel it's OK to let it "bloat" at my expense (i.e. size and time costs of backups, etc.).  For example, it seems that some app mgrs always want their own copy of the JRE to be present, so they install it without any regard to whether or not there's a master JRE version installed, anyway. That's like 1/5th a gig of space wasted because the install module didn't want to bother to see what version of JRE might be installed.  And, when I mentioned "support calls," I was thinking of Microsoft, who wants everything where they want it in order to facilitate them resolving support calls they receive. Hence the direction to their MVPs and partners to force installs onto C:\.

Where I really see the benefit of my approach is with data and data files. That absolutely needs to be off the C:\ drive. And that's much larger in size for me than the app directory. It also requires a different backup strategy.  So I use a separate drive for that (both logically and physically) from the C:\ drive.   This way, if there is a corruption on C:\ I haven't necessarily lost any data as well as the system, which I can restore from the system image. Just trying to mitigate damages, is all.

 

 

Edited June 3, 2018 by Mbag3rd

[exile360]

Yeah, I'm not a fan of it when apps force dependencies on you like that, be it JRE, .NET, MS Visual C++ versions etc. because you end up with a lot of additional components installed, and when you remove the applications that installed them they do not remove those other components with them, so if you don't keep track of what installed/required what, you can end up with tons of stuff on your system that you don't really need.  The reason they don't remove it is because it's always possible for you to install some other program later on which also requires that version, and if they removed it during uninstall that would break the other application(s) that depend on it.  I get the logic, but it's still quite frustrating and I'd prefer that MS manage it better than they do.  For example, if it would list which currently installed applications actually depend on a specific version of .NET/Visual C++ runtime files etc. that would be very helpful and make it manageable instead of just having to leave everything on there the way it is now.  Something like the way they handle most services where it shows you the dependencies for each service so that you know which other services are required for it to run.  Something like that for these runtime files and other components would be very useful.

Edited June 3, 2018 by exile360

[Mbag3rd]

23 hours ago, exile360 said:

Yeah, I'm not a fan of it when apps force dependencies on you like that, be it JRE, .NET, MS Visual C++ versions etc. because you end up with a lot of additional components installed, and when you remove the applications that installed them they do not remove those other components with them, so if you don't keep track of what installed/required what, you can end up with tons of stuff on your system that you don't really need.  The reason they don't remove it is because it's always possible for you to install some other program later on which also requires that version, and if they removed it during uninstall that would break the other application(s) that depend on it.  I get the logic, but it's still quite frustrating and I'd prefer that MS manage it better than they do.  For example, if it would list which currently installed applications actually depend on a specific version of .NET/Visual C++ runtime files etc. that would be very helpful and make it manageable instead of just having to leave everything on there the way it is now.  Something like the way they handle most services where it shows you the dependencies for each service so that you know which other services are required for it to run.  Something like that for these runtime files and other components would be very useful.

Another reason why I prefer to install away from the C:\Drive. It becomes easier to remove any remanents of the install directory when needed. Yes, it may not remove those modules that were forced onto Drive C:\ (DLLs, etc.), but I can live with that. And, with the advent of WinSxS, the C:\ Drive is really going to get bloated.  Anyone who could write a utility that can purge that directory without loss of function (based on what is currently installed/active) could make a lot of $$$.

[bdg2]

15 minutes ago, Mbag3rd said:

Another reason why I prefer to install away from the C:\Drive. It becomes easier to remove any remanents of the install directory when needed. Yes, it may not remove those modules that were forced onto Drive C:\ (DLLs, etc.), but I can live with that. And, with the advent of WinSxS, the C:\ Drive is really going to get bloated.  Anyone who could write a utility that can purge that directory without loss of function (based on what is currently installed/active) could make a lot of $$$.

Isn't disk ckeanup or:

Dism.exe /online /Cleanup-Image /StartComponentCleanup

enough?

Also don't forget that while WinSxS looks big much of it is just hard links to files that also exist elsewhere in the directory structure.

[Mbag3rd]

15 hours ago, bdg2 said:

Isn't disk ckeanup or:

Dism.exe /online /Cleanup-Image /StartComponentCleanup

enough?

Also don't forget that while WinSxS looks big much of it is just hard links to files that also exist elsewhere in the directory structure.

I find that disk cleanup doesn't really clean very much at all. It may help with some of the temporary files and storage, but not much else. And it certainly doesn't clean up the very large and accumulating files that make the C:\ drive bloated.  I have to go through manually and do those, where I can.  It also doesn't clean things like all the "sqlite" data bases that just keep accumulating data. I'd love to have a utility that helps me do that, as those DB's can get very large.  I'll check out this dism.exe program and see what it can do. Thanks!

I don't judge WinSxS by what/where it stores things, but by how much space it uses. And it's using a lot. It's very point, per my understanding, is that it will preserve multiple copies of critical system modules that get replaced by either Windows Updates or other installs so that the older versions are still available to older apps that need them. Whether it stores the physical module under it's directory structure or points to it elsewhere, doesn't really matter. All the module versions are still on the disk, somewhere. Although my gut tells me that most of what it preserves is under its directory structure.  Otherwise, it wouldn't have control over the modules  it's attempting to preserve, thus increasing the risk of deletion elsewhere by other processes. I can see where it would have pointers to the most currently active version of a module in its appropriate install location, but I think the older versions go underneath the WinSxS directory structure.

 

[bdg2]

12 hours ago, Mbag3rd said:

I find that disk cleanup doesn't really clean very much at all. It may help with some of the temporary files and storage, but not much else. And it certainly doesn't clean up the very large and accumulating files that make the C:\ drive bloated.  I have to go through manually and do those, where I can.  It also doesn't clean things like all the "sqlite" data bases that just keep accumulating data. I'd love to have a utility that helps me do that, as those DB's can get very large.  I'll check out this dism.exe program and see what it can do. Thanks!

I don't judge WinSxS by what/where it stores things, but by how much space it uses. And it's using a lot. It's very point, per my understanding, is that it will preserve multiple copies of critical system modules that get replaced by either Windows Updates or other installs so that the older versions are still available to older apps that need them. Whether it stores the physical module under it's directory structure or points to it elsewhere, doesn't really matter. All the module versions are still on the disk, somewhere. Although my gut tells me that most of what it preserves is under its directory structure.  Otherwise, it wouldn't have control over the modules  it's attempting to preserve, thus increasing the risk of deletion elsewhere by other processes. I can see where it would have pointers to the most currently active version of a module in its appropriate install location, but I think the older versions go underneath the WinSxS directory structure.

 

What I'm saying is a lot of what's in WinSxS that remains after cleaning up is hard links to files that are also elsewhere, probably in places where you'd never consider deleting them and expect things to still work. Since they're hard links you can't gain any space at all without deleting all instances of each of those files.

Edited June 6, 2018 by bdg2

[Mbag3rd]

4 hours ago, bdg2 said:

What I'm saying is a lot of what's in WinSxS that remains after cleaning up is hard links to files that are also elsewhere, probably in places where you'd never consider deleting them and expect things to still work. Since they're hard links you can't gain any space at all without deleting all instances of each of those files.

Well, I'm not touching anything in WinSxS at all. I'm just resigned to it growing and bloating all along. I'm not going to delete anything I think might compromise the system.  And when I do delete something risky, I copy it to archive storage off the C:\drive so I can restore it quickly if something does go haywire.

  

[exile360]

You can also clear out the backup files from the previously installed Windows OS Service Pack if you haven't already via this command in an administrative command prompt:

dism /online /cleanup-image /spsuperseded

You can also clear out Windows Update backup files and other temp files as mentioned via the Disk Cleanup tool (cleanmgr.exe) and of course you can clear out a lot more of the temporary files created by the system and various programs via a third party cleanup tool like CCleaner or ATF Cleaner or TFC (Temporary File Cleaner), all of which are free (though I recommend not using any registry cleaners like that found in CCleaner's Registry tab as cleaning the registry doesn't provide any extra disk space and can often do more harm than good).

[bdg2]

4 hours ago, Mbag3rd said:

Well, I'm not touching anything in WinSxS at all. I'm just resigned to it growing and bloating all along. I'm not going to delete anything I think might compromise the system.  And when I do delete something risky, I copy it to archive storage off the C:\drive so I can restore it quickly if something does go haywire.

  

How do you assess how much space WinSxS is taking? It looks huge if you right click it and choose properties but that figure will probably be quite a bit bigger than it really is, some files will have multiple hard links to them from within WinSxS.

[Mbag3rd]

4 hours ago, bdg2 said:

How do you assess how much space WinSxS is taking? It looks huge if you right click it and choose properties but that figure will probably be quite a bit bigger than it really is, some files will have multiple hard links to them from within WinSxS.

I have a utility that tallies space in all directories and sub-directories... both "actual" and "allocated" space.  When I do a Windows Update or install something that updates some system modules or DLLs, I'll see the directory size under WInSxS change (go up) or not.  I also keep tabs on the overall size of C:\ so that if I see it rising but WinSxS is not, I know to look elsewhere for the increases.  I take screen shots of the sub-directory sizes the utility reports to me  and compare current to previous. I can tell when and where something increased and check it out, accordingly. Most of the time, the increases are legitimate and appropriate.   But where temp files remain, or other things happen that I can delete, I'll consider those.

[Mbag3rd]

7 hours ago, exile360 said:

You can also clear out the backup files from the previously installed Windows OS Service Pack if you haven't already via this command in an administrative command prompt:

dism /online /cleanup-image /spsuperseded

You can also clear out Windows Update backup files and other temp files as mentioned via the Disk Cleanup tool (cleanmgr.exe) and of course you can clear out a lot more of the temporary files created by the system and various programs via a third party cleanup tool like CCleaner or ATF Cleaner or TFC (Temporary File Cleaner), all of which are free (though I recommend not using any registry cleaners like that found in CCleaner's Registry tab as cleaning the registry doesn't provide any extra disk space and can often do more harm than good).

I don't touch the registry unless it's absolutely necessary and I know specifically, what I need to touch (and the consequences of doing so). 

[Mbag3rd]

All, are there any updates on the original problem I submitted for this thread?  Any word in re: the Dump file I submitted?

[bdg2]

2 hours ago, Mbag3rd said:

I have a utility that tallies space in all directories and sub-directories... both "actual" and "allocated" space.  When I do a Windows Update or install something that updates some system modules or DLLs, I'll see the directory size under WInSxS change (go up) or not.  I also keep tabs on the overall size of C:\ so that if I see it rising but WinSxS is not, I know to look elsewhere for the increases.  I take screen shots of the sub-directory sizes the utility reports to me  and compare current to previous. I can tell when and where something increased and check it out, accordingly. Most of the time, the increases are legitimate and appropriate.   But where temp files remain, or other things happen that I can delete, I'll consider those.

How does this utility deal with a single file that is hardlinked from multiple places in the directory tree?