Skip to main content
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 

 

 
@ 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
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
@ 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.
 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.
? 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.
? 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 😉
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.
So what are you trying to say? Please don't make it a mountain when it's only an ant hill.

 

Daniel 😠
@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
@ 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.
@ 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:

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.
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.
@ 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 ?
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. 
@ wrote:

@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

Thank you.
I guess you no what your talking about because I  haven't seen much of any wild disk usage by explorer when it's using all that memory. I have plenty of memory now. When I started using Webroot I didn't. That's one big reason  why I went with the program and explorer doing the momory thing posed a problem when I only had 4GB ram. Not as much as other software and windows process's that use to constantly use the disk in window 8.1. I've noticed some of those programs now use more memory instead of using the disk in Windows 10 making it more stable and responsive. It use to drive me crazy waiting for the system to do it's thing without regards to what I wanted to do with computer.
Guess the fix is back?

My system is Windows 10 fully update as of now!

Looks like its back to 60 MB.

:)

 

On WRSA 9.0.2.22

 



 

 
?  ? Yes your right it has to be one of these 2 updates that fixed it!

 

https://support.microsoft.com/en-us/kb/3081444

 

No info on this one? KB3081441 here is some from Reddit: https://www.reddit.com/r/Windows10/comments/3hhwzg/update_new_cumulative_update/ and more info on KB3081424: http://www.infoworld.com/article/2960528/patch-management/windows-10-patch-kb-3081424-can-crash-fail-to-install.html

 

Also from Microsoft Answers: http://answers.microsoft.com/en-us/windows/forum/windows_10-update/update-for-windows-10-for-x64-based-systems/06d5231d-113f-4f4b-ad4f-affda1e6cc6e?auth=1

 

Awesome!

 

Daniel ;)

 


Finally a solution to the most enigmatic and controversial topic in the forum. Hope this is permanent.

😃
Yes for Win 10 x64 but it took allot longer for Win 8.1 x64: https://community.webroot.com/t5/Webroot-SecureAnywhere-Antivirus/Explorer-exe-using-up-to-300mb-RAM/m-p/198377#M15753

 

Daniel 😉
Can you verify if the update that fixed 8.1 is similar to the update that fixed 10?
No I can't and wouldn't know where to look? Here was the fix for Win 8.1 x64: https://support.microsoft.com/en-us/kb/3000850 and you can see my reply here on page 5: http://answers.microsoft.com/en-us/windows/forum/windows8_1-update/major-issues-with-kb3000850/5cb4cddd-52da-44af-9fd5-3ae1a72b0b1a?page=5

 

Daniel 😉
At a first glance they look like they talk about something else but fixed it. 😛

Reply