Mbag3rd

Any luck yet? I still have Ransomware disabled, and it has still been stable for more than a week. It's just that the dashboard balks at me for not being "fully protected." ?

It would seem that the "Ransomware" component is the primary issue. I have had much better performance since I had it disabled. It's been much better for at least 1.5 days. Thank you.

Update: It does appear that disabling ransomware protection has had a positive effect on the issue. But I will give it more time and let you know.

OK, will give that a try.

Update: I regret to advise that the original problem has reoccured. This using the following updates: Version Info: Malwarebytes Ver. 3.5.1.2522 Components Pkg v. 1.0.374 Update Pkg: v 1.0.5486 All other parameters remain the same. Here is the dump file: Download Dump File Here...

But, at some point, once you delete the last of the hard links (all of them, not just the ones you created), will it free the physical space the files occupy (at least in the directory listings)? If not, then I think the OS has a garbage collection problem. I don't think I've had much trouble with hard linked files when it comes to freeing up space. I'm guessing that most times when hard links are at issue, they are associated with hidden or system files that I can't delete anyway (like those in WinSxS). I'm only after the "low hanging fruit..." things that are reasonably safe to delete without any adverse effects on the system... logs, and the like. But things that utilities like Windows Cleanup seem to overlook. I suppose if I were to encounter a hard linked file where deleting the link would not free the space (i.e. there might still be another hard link pointing to it), I'd search for that link and delete it as well, until I were able to free the space, if possible.

That really doesn't matter. The physical files have to be there somewhere, regardless of where they reside or how many hard links point to them. And, however it is happening, my utility reports a certain amount of space being tallied under the WinSxS directory. I guess if a hard link is present under WinSxS, it's counting that file size in its tally under that directory. And that tally changes regularly as Windows Updates or other installs happen. It's the only thing by which I can judge how much space is being utilized. But, again, I seriously doubt I'll ever attempt to delete anything under the WinSxS directory. I think the only way I can reclaim space there is a complete rebuild of my machine (where I only install the latest version of the apps I'm running). Unfortunately, with the advent of Microsoft "activation services" for their apps, it becomes even more difficult, as they no longer provide those services for some of their older product versions. This, I guess to force you to by the "subscription" version of their products. Not going to happen in my case. I think when Windows 7 reaches EOL, my next builds will be Linux in nature...

OK Thanks! I'll do the update and see what happens.

It sees it only as one single physical file, wherever it is located, taking up only the space of one single file. The hard links just point to wherever that physical location is, be it inside the WinSxS directory or not. If the physical file is not under the WinSxS directory, it won't report it there. I guess whatever space the hard links use under the WinSxS directory might be reported there.

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

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).

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.

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.

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.

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 $$$.

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.

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.

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

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.

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.

Scan files attached. mbst-grab-results.zip

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.