Solved

Explorer.exe using up to 300mb RAM.



Show first post

365 replies

Userlevel 5
Badge +16
the DLL is multifunctional, and this isn't a discussion of that. The only reason I mentioned the DLL is is to explain the proceedure that explorer undergoes when this behavior is detected.
 
running a replacement shell has it's own risks and benefits. I won't go into the security discussion here at the risk of derailing the topic. 
Userlevel 6
Badge +24
@ wrote:
 
With this said, WSA loads a DLL into the Explorer process. This isn't uncommon, and is a fairly frequent occurrence for system utilities. Because of this 'injection' it makes sense for Explorer to create a buffer to improve stability. Particularly during the early release stages of the OS as many of the hardening functions haven't been written to solidify the process in question.
 
This is EXACTLY what is taking place in this instance. Explorer is detecting our DLL load and is insolating it against crashing. It's a fault protection, and as I mentioned in my original discussion, is actually a GOOD THING to do. 
 

@
Does this mean using an Explorer alternative like Total Commander or Directory Opus makes WRSA's security functions less reliable? Where WRSA doesnt loads a DLL into their process ? What is the function of the said DLL ?
Ram instant. Pagefile on non SSD hard drive you have to wait for reads and writes even if it is available space that it's using.
Userlevel 5
Badge +16
@ wrote:
Thanks for the expectation, but if it's a pagefile problem it's worse then if was just a ram problem. If it was just a ram problem and you have plenty of ram on your computer it' s not going to really affect your computers performance. If it's a pagefile problem and you have a regular Hard Drive and not a SSD your going to have to wait for your hard drive to respond which will slow up your system. So any system resource advantage to using Webroot over other antivirus software is nullified while this problem exist.
This would be true, if the allocation were more dynamic. And that is the reason I pointed out that there are more types of memory that reside in the page file that what you are seeing in this case.
The allocation unit for the page size for this function is private set, this isn't a frequently resized section of memory, in that those pages aren't being constantly accessed. You can verify this by reviewing the Disk IO related to Explorer. There will be some, because nearly everything uses page file resources, so Disk IO will never stay static, but if a performance hit related to page file utilization were to impact the system you'd be seeing writes in excess to 400MB per second, essentially flooding the bus. When looking at resource monitor, while the numbers appear huge, it's important to remember conversions of Bytes to Megabytes, and so on. With this in mind, the SATA II specification indicates a max throughput of 3Gb/s (3072 bytes per second) or around 300 Megabytes per second.
 
I just looked at this here on my test machine, and had to actually launch a file inside of explorer to see any disk IO from the process.
 
With this in mind, if you are using a system using a processor manufactured at any time in the last 7 or 8 years, this won't be an issue. This would hardly be an issue on the older Ultra ATA drives, which run between 66 and 100Mb/s over the channel. I do understand that the drives themselves do not actually read and write at the maximum allowable through the channel, but the reality is that's not what is taking place in this scenario. The allocation is made, and it isn't 'remade' on each access, it's only written in the event of a process restart, and is really read upon rare occasions.
 
And again, if this were an issue, would the system be as 'speedy' as it is? Are you experiencing slow downs as a result of this behavior? I suspect that isn't the case. 
 
As for my original posts on this topic, I'm not sure how to link im, but you can see them back aways round page 30 or so.
Userlevel 7
@ wrote:
Thanks for the expectation, but if it's a pagefile problem it's worse then if was just a ram problem. If it was just a ram problem and you have plenty of ram on your computer it' s not going to really affect your computers performance. If it's a pagefile problem and you have a regular Hard Drive and not a SSD your going to have to wait for your hard drive to respond which will slow up your system. So any system resource advantage to using Webroot over other antivirus software is nullified while this problem exist.
I am not sure what you have been smoking but where did you manage to dig up such an outlandish hypothesis?
@ wrote:
...your going to have to wait for your hard drive to respond which will slow up your system. So any system resource advantage to using Webroot over other antivirus software is nullified while this problem exist.
Reserving empty space on your hard drive? I'm not the best placed to comment but personally I'd be surprised if the above was true.
@dtouch wrote:
...could anyone link to @ 's previous post explaining this before. I missed it.
I think perhaps these two postsare the ones that @ is referring to:
https://community.webroot.com/t5/Webroot-SecureAnywhere-Antivirus/Explorer-exe-using-up-to-300mb-RAM/m-p/117664/highlight/true#M7014
https://community.webroot.com/t5/Webroot-SecureAnywhere-Antivirus/Explorer-exe-using-up-to-300mb-RAM/m-p/121332/highlight/true#M7117
Userlevel 7
Badge +56
So what are you trying to say? Please don't make it a mountain when it's only an ant hill.
 
Daniel 😠
Thanks for the expectation, but if it's a pagefile problem it's worse then if was just a ram problem. If it was just a ram problem and you have plenty of ram on your computer it' s not going to really affect your computers performance. If it's a pagefile problem and you have a regular Hard Drive and not a SSD your going to have to wait for your hard drive to respond which will slow up your system. So any system resource advantage to using Webroot over other antivirus software is nullified while this problem exist.
Userlevel 7
Badge +56
? Thanks so much Lucas for your great Comment it's much appreciated! Again we await to see if and when Microsoft will send out a fix for this issue and I have reported it on my end.
 
Daniel 😉
Userlevel 6
Badge +24
? Now we got the answer we are looking for rather than vague statements.
Thanks a lot for taking time to explain.
And yes WRSA is special and thats why most of us are fanatically sticking to it :)
 
Also could anyone link to ? 's previous post explaining this before. I missed it.
Userlevel 5
Badge +16
 I addressed this specific issue when it occurred with Windows 8.1. I'm not sure (it has been awhile) if I addressed the reason 'fix' and what it accomplished.
 
The name of this thread is also a huge point of contention as it isn't using RAM. It's using page file, and the distinction is massive. 
 
Microsoft describes what this thread describes as the following:
Memory - Private Working Set
Subset of working set that specifically describes the amount of memory a process is using that can't be shared by other processes
 
This is only one chunk of memory out the 7 types described in Task Manager. Memory, allocation, and how it is shuffled around is one of the most complex items to grasp in modern operating systems. This is because there are so many types, and subsets of those types. It's also dynamic and ever changing, so getting a precise counter is nearly impossible, the best you'll get is a snap shot. Additionally, Task Manager doesn't actually display the amount of RAM consumption as it has its own sets of memory and subsets. It's also much faster, so it's difficult to get an accurate picture.
 
With this said, WSA loads a DLL into the Explorer process. This isn't uncommon, and is a fairly frequent occurrence for system utilities. Because of this 'injection' it makes sense for Explorer to create a buffer to improve stability. Particularly during the early release stages of the OS as many of the hardening functions haven't been written to solidify the process in question.
 
This is EXACTLY what is taking place in this instance. Explorer is detecting our DLL load and is insolating it against crashing. It's a fault protection, and as I mentioned in my original discussion, is actually a GOOD THING to do. 
 
I also have no doubts that this issue will be resolved by Microsoft (the issue isn't something that we can fix, as it's a function of the Explorer Shell itself).
 
So for the 'why' other security products do not exhibit this phenomena, WSA is a unique application that functions in unique ways within the Windows Operating system. One would be hard pressed to find another solution that performs at the speed we do, and offers the functions, and features at the same size. So the comparison is a bit like apples to elephants.
 
The implication of this thread is that our software is using computer resources (that we aren't) and causing a problem as a result (whitch isn't the case). The reality is that Windows 10 recommends a Hard Drive size of 20GB (which is a bit laughable for everything but tablets) and out of that 20GB (or 20,480 MB) only 300MB or 0.0145 of that disk space is being reserved for the Explorer shell with WSA installed. 
 
Also want to clarify the idea of a 'memory bleed' or 'leak.' This isn't what is being experienced by this occurrence. If this was true, the amount used would be significantly higher after use, than boot. A memory leak will see an INCREASE is usage indicating that more and more memory is being consumed by the service in question continuing to balloon until the system locks. This isn't the case. While Explorer's functions will raise and lower the memory usage depending on the tasks it performs, simply closing windows and applications will return it back to the same state (generally) that it was running in when the machine booted. There could be a variance of 20 or 30 MB, but for most stable un-modified systems, this isn't going to be the case.
Userlevel 6
Badge +24
@ wrote:
It's definitely a memory bleed and not because of Webroot and explorer.exe preparing to sync files. I was hoping for best but now irritated again.https://youtu.be/uTe5VsKaPAk
Definitely there is a memory leak.. because more memory is used. What actually causes is the issue here. One of the leading alternatives to Windows Explorer (aka File Manager) , Directory Opus handle the memory pretty well with WRSA running even if we set it as default file manager for windows - it takes just 20 MB.
 
So when WRSA services are running File Explorer somehow takes more memory. As @ previously mentioned a fix , the fixed issues doesnt actually address our particular issue. The fix happened to solve our issue serendipituosly??
 
Anyways for explorer to take memory either Microsoft has to bring back that magical fix or WRSA has to totally figure out why it causes explorer to take more memory and why no other security software does.
 
I feel we are all just beating around the bush here imho.
It's definitely a memory bleed and not because of Webroot and explorer.exe preparing to sync files. I was hoping for best but now irritated again.https://youtu.be/uTe5VsKaPAk
Userlevel 7
Badge +56
@ wrote:
I'm having the same problem again. How is it Microsofts fault? It's their fault for certifying the Webroot program as compatible with Windows 10 when it isn't. Webroot knew about this from the windows 8.1 version and you have posted that the problem was on the windows 10 preview versions. So Webroot should have fixed by the Windows 10 release date. It's not just that explorer uses more memory. Explorer doesn't function properly either all the thumbnails have to regenerate every time you open up a folder wasting system resources. I set all my junk file cleaning programs so that they don't delete the thumbnail cache because I can't stand waiting for them to regenerate, but because of this problem I have this happens all the time. I'm sure it causes other problems too! Before I just installed the windows 8.1 update that corrected this now I have to disable Webroot and install Bitdefender until there's a fix. I am highly irritated and last time I had this problem Webroot Support was no help at all! I also remember asking if Webroot was going to have a version that works right with Windows 10 when it was ready! I'm going report this to Microsoft just for the hell of it and ask them why they certified a program than causes Windows 10 to not work right?
Please see here as I explained about Win 8.1 x64 and the fix from Microsoft and now the issue has reappeared in Windows 10 x64 it never happened with Win 8 x64 and it's not Webroot's fault we just have to wait for a fix from Microsoft again: https://community.webroot.com/t5/Webroot-SecureAnywhere-Antivirus/Explorer-exe-using-up-to-300mb-RAM/m-p/198377#M15753
 
Thanks,
 
Daniel
Userlevel 7
Hi MikeWB
 
I think that it was noted earlier in the thread that the Webroot Development Team are looking into the issue, one similar to which has been plaguing some users running Windows 8/8.1 but not Windows 7 users.
 
The best thing to do is to await feedback from the Development Team re. their investigation but I suspect that it will once again be a Microsoft issue related to how File Explorer (as I believe it is now called) works.
 
Regards, Baldrick 
 
 
 Are you sure it's a memory bleed? Or was it because Webroot and explorer where preparing to sync files for backup for Webroot backup and sync service because even though the problem diapered and reappeared after shutting down Webroot and restarting explorer I noticed that right after this happened to me Webroot started uploading files for backup and sync and explorer memory went back to normal after that and I don't see the problem anymore. So hopefully for me at least it's not the memory bleed problem. I'll wait and see.
I'm having the same problem again. How is it Microsofts fault? It's their fault for certifying the Webroot program as compatible with Windows 10 when it isn't. Webroot knew about this from the windows 8.1 version and you have posted that the problem was on the windows 10 preview versions. So Webroot should have fixed by the Windows 10 release date. It's not just that explorer uses more memory. Explorer doesn't function properly either all the thumbnails have to regenerate every time you open up a folder wasting system resources. I set all my junk file cleaning programs so that they don't delete the thumbnail cache because I can't stand waiting for them to regenerate, but because of this problem I have this happens all the time. I'm sure it causes other problems too! Before I just installed the windows 8.1 update that corrected this now I have to disable Webroot and install Bitdefender until there's a fix. I am highly irritated and last time I had this problem Webroot Support was no help at all! I also remember asking if Webroot was going to have a version that works right with Windows 10 when it was ready! I'm going report this to Microsoft just for the hell of it and ask them why they certified a program than causes Windows 10 to not work right?
Userlevel 7
Badge +56
@dtouch wrote:
The memeory leak returns with Windows 10 x64?
Running Windows 10 Pro x64 with WRSA 9.0.1.36


Yes it does but it's not WSA's fault as I said here: https://community.webroot.com/t5/Webroot-SecureAnywhere-Antivirus/Explorer-exe-using-up-to-300mb-RAM/m-p/198377#M15753 we just have to wait till Microsoft fixes it again.
 
Thanks,
 
Daniel 😉
Userlevel 6
Badge +24
The memeory leak returns with Windows 10 x64?
Running Windows 10 Pro x64 with WRSA 9.0.1.36

Userlevel 7
It works fine in Windows 8.1. 
Seems to be fine now, but I don't understand why exploer.exe does it without the updates shuoldn't te antivirus program work on any version of windows 8.1?
Userlevel 7
Badge +56
@ so how did your updates turn out did Explorer.exe go back to normal?
 
Thanks,
 
Daniel
Userlevel 7
Badge +56
Hello Mike and Welcome to the Webroot Community!
 
As said before it was never an issue with WSA but Windows 8.1 x64 and that KB3000850 fixed the issue also I see on  Win 10 Preview x64 has the same issue and I have told them about it and hopefully before release they will fix that issue as well!
 
Thanks,
 
Daniel ;)
 


 

Secure Anywhere causing explorer.exe to use 310 MB of memory! Way to much! When it's not running it's at 30 MB by luck I found where other people are having the same problem on the Webroot message board. After hours of trouble shooting doing clean boots and looking on the web. It never occurred to me to turn off secure anywhere. I have a 2 day old Dell Interspersion 5749 running windows 8.1 64 bit. I have a paid subscription for Bitdefender Internet security 2015. I just received a replacement computer for a Dell 5748 that never worked right and have been researching anti viruses and saw that Webroot secure anywhere uses the least memory and it worked fine for a day but today when I started up my computer I noticed explorer.exe using lots of memory. I am trying your anti virus because Bitdefender uses 200-300MB of memory to much in my book and use to much disk writing. I liked Webroot and it was catching viruses in downloads when Bitdefender wasn't the day I ran it at the same time on my old computer. I know they tell you not to run 2 anti viruses at a time but with the small footprint of this anti virus I figures whats the harm, since I knew my replacement computer was coming in a few days I kept downloading programs I knew had viruses on them. Anyways if secure anywhere causes explorer.exe to use 300MB of memory your anti virus program is using as much or more memory than Bitdefender. Why should I buy it? Anyways is their a fix for this?
 
I just put in this support request, but after seeing this last post I checked my new computer and no windows updates have been installed so I am going to install them all including KB3000850 hopefully this will fix the problem for me too! I will update to board when done.

Reply