WSA AV and explorer.exe RAM usage

dont hold your breath

 

Yes - this is being triggered by Explorer detecting WSA's monitoring library loading into it and entering into a mode where they enable a feature of the OS which causes high RAM usage (in the interest of preventing potential crashes). We have not yet found a workaround for this but are still trying.

 

Thanks Joe,

No problem since as far as I can tell it is not causing any problems here. I have 8 gig of ram and with WSA shut down about 19 to 20 % total system usage. With WSA running it jumps about 30 % usage. I see no slow downs or any other issues on my system. It is just weird seeing total system ram usage jumping up by 50 % (majority of increase within explorer.exe). Thanks for the update...

 

I've noticed the same thing happening with NVT ERP memory usage with WSA installed on Win 8.1 x 64. Is it the same issue and do we have an ETA for a fix.

Thanks

 

I haven't heard of NVT ERP having any RAM increase with WSA, but would definitely be interested if you could write into our support inbox and have them collect logs.

The explorer RAM case is still a lower priority at the moment because it has no adverse side effects, but it's still on the list.

 

Ok, thanks, will do. For info it has been reported in the monster NVT ERP thread by guest too.

Cheers

 

I get that it's not killing the computer in most cases, but with the bug WSA goes from the lightest AV to the heaviest. Not great considering being light is one of Webroot's selling points...

 

Please see this post: https://www.wilderssecurity.com/showpost.php?p=2343792&postcount=3

And it's still on the list to be corrected.

TH

 

i have a computer now dropped off by a customer that is having major sporadic slowdowns since i installed webroot for him. mouse freezes for a second or pages taking to long to load or applications locking upon opening for a few seconds then opening like normal. it started about 2 weeks ago he said and webroot has been on there for about 3 months. i assume its from one of the newest updates, the system without webroot runs perfect. and after a reinstall of the newest version we see the same sporadic slowdowns again coming from webroot. when i get to the office tomm ill send you some logs joe i dont have it here at home with me. for me the last few updates are causing some headaches and im holding off for the time being installing on any new clients till i see the things corrected or figured out. but this and the non typing no cursor issue is being a problem of late i had another customer call about the typing issue i posted about a couple weeks ago same exact thing i have to get out there tomm to also check there system.

by the way the typing issues im seeing are all so far windows 7 x64 and the slowdowns im only seeing on windows 8.1 x64 not on windows 7.

 

This wouldn't be related to the explorer RAM usage as it has no impact on performance but I'm definitely happy to look through any logs you have to find the cause.

 

no didnt think it was but wanted to add ive been seeing major hang ups for some reason and i cant figure out why other than its def coming from webroot. ill send you some logs tomm for sure im hoping we can figure it out because everyone loves webroot aside from these few issues ive been having

 

+10

Sorry, but it's been my experience that they will let you burn out a multi-year license before they actually fix a serious problem. Surprised they still claim Windows 8 64-bit compatibility. And no other major AV vendor seems to have this critical issue? Hmm.

 

I've actually had this fixed since .63 build.

 

"seems" to be fixed since v.66 but sometimes it reappeared sporadically ^^

after update to v.66: no more excessive RAM usage; i was happy !
reboot: it comes back ; i was disappointed
10mn ago: normal usage again ; i am on alert

"Webroot SA, we give you emotions"

 

There is zero impact to the system with this issue - it only affects available RAM if not used elsewhere, and does not impact performance. We are fully compatible with Win8 x64. We should be able to implement a workaround for this but we're focused on more important changes at the moment which actually do improve protection and performance.

(Also, to the followup posters saying they're seeing it fixed: we haven't changed anything, but it's very possible that Microsoft put out a patch to fix it)