Windows 8.1 Professional.
http://s020.radikal.ru/i710/1310/58/6460089d2a94.jpg
http://i031.radikal.ru/1310/d4/ecd121410c70.jpg
Page 11 / 15
(Sorry, I can't post more than one link in each answer because the forum says I have to enter a valid url)
Windows Firewall Control, both service and gui affected:
http://www.wilderssecurity.com/threads/windows-firewall-control-4.347370/page-20#post-2317443
Windows Firewall Control, both service and gui affected:
http://www.wilderssecurity.com/threads/windows-firewall-control-4.347370/page-20#post-2317443
(Sorry, I can't post more than one link in each answer because the forum says I have to enter a valid url)
NVT ERP:
http://www.wilderssecurity.com/threads/new-antiexecutable-novirusthanks-exe-radar-pro.300552/page-127#post-2343744
Softperfect Ramdisk I have witnessed myself. Fact is, it's happening all over the system with 64bit processes. Aside from Explorer, I have not witnessed it with Windows' own processes. Mainly third-party 64bit processes.
NVT ERP:
http://www.wilderssecurity.com/threads/new-antiexecutable-novirusthanks-exe-radar-pro.300552/page-127#post-2343744
Softperfect Ramdisk I have witnessed myself. Fact is, it's happening all over the system with 64bit processes. Aside from Explorer, I have not witnessed it with Windows' own processes. Mainly third-party 64bit processes.
I can atest to this as well. It's not only explorer using 280-300k but also sandboxie service and sandboxie control. Both sandboxie process are 260-280k each. I have to agree that it really shouldn't using that amount of memory. Even if it's paged or not. If I didn't care how much memory or page a program used I would be running trustport or zonealarm extreme. The point is lost that it does elevate and utilizie more than a "light" cloud AV should. Just my two cents. I understand that it's been explained as to why but why bother trying to find a solution if it's not a "problem".
I too have explorer.exe using around 300 mb. I still get the report from system analyzer that there may be a memory leak in explorer.exe. It is my understanding that this is an issue with 64 bit systems and is being worked on.
I am not personally experiencing any performance issues. Also, WSA on my system uses only about 3mb
I am not personally experiencing any performance issues. Also, WSA on my system uses only about 3mb
I think what everyone is seeing is a change in Windows architecture, and the various ways in which Microsoft has gone about isolating and protecting the opearating system.
This is a perceptual issue. That is to say that 'I percieve somthing that I do not think should be, therefore a problem exists.'
The behavior you have seen isn't a response to WSA or any other third party code. Microsoft has developed Windows in such a way that shared resources are common, for example, shared DLL's are common practice in order to perform all kinds of functions. This allows developer's to write code utalizing pre-defined libraries developed by Microsoft. A 'potential' security risk is triggered when a DLL is 'injected' into an application and possible stability issues can occur. Microsoft has been hammered for nearly two decades on stability and I expect that many of the additional requests are in place to ensure the stability of the platform.
Memory (RAM, SWAP etc.) is hardly a concern on most modern machines. Many are configured with 8GB of RAM and unless you run your system without rebooting for 6 month spans, or utalize heavy memory intensive software (MAYA, Photoshop RAW/32bit floating images etc.) you will hardly ever run out of memory. Adding to that the speed of SSD storage for page files, a performance draw shouldn't be occuring at all unless the program in use has issues.
Regarding SSD Read/Writes, this isn't avoidable. Every program you use makes use of page file (SWAP) and doesn't load entirely into RAM, without the use of a RAMDISK type application. Additionally, there isn't a significant difference in modern SSD's than mechaincal drives as it applies to lifetime usage. Most of us will replace these drives, or machines with them before they expire.
Ultimately this issue isn't one with WSA, it is one where Microsoft has coded in a fault tolerance limit for Explorer (or other processes) to prevent crashing. The additional memory usage (mostly reservered and not written by the way) is just a way to ensure your shell doesn't crash when something goes wrong.
I hope that answers many of the concerns regarding this one recently, if not, please let me know and I'll add more to the topic.
Thanks,
Lucas
Webroot Sr. Escalation Engineer
This is a perceptual issue. That is to say that 'I percieve somthing that I do not think should be, therefore a problem exists.'
The behavior you have seen isn't a response to WSA or any other third party code. Microsoft has developed Windows in such a way that shared resources are common, for example, shared DLL's are common practice in order to perform all kinds of functions. This allows developer's to write code utalizing pre-defined libraries developed by Microsoft. A 'potential' security risk is triggered when a DLL is 'injected' into an application and possible stability issues can occur. Microsoft has been hammered for nearly two decades on stability and I expect that many of the additional requests are in place to ensure the stability of the platform.
Memory (RAM, SWAP etc.) is hardly a concern on most modern machines. Many are configured with 8GB of RAM and unless you run your system without rebooting for 6 month spans, or utalize heavy memory intensive software (MAYA, Photoshop RAW/32bit floating images etc.) you will hardly ever run out of memory. Adding to that the speed of SSD storage for page files, a performance draw shouldn't be occuring at all unless the program in use has issues.
Regarding SSD Read/Writes, this isn't avoidable. Every program you use makes use of page file (SWAP) and doesn't load entirely into RAM, without the use of a RAMDISK type application. Additionally, there isn't a significant difference in modern SSD's than mechaincal drives as it applies to lifetime usage. Most of us will replace these drives, or machines with them before they expire.
Ultimately this issue isn't one with WSA, it is one where Microsoft has coded in a fault tolerance limit for Explorer (or other processes) to prevent crashing. The additional memory usage (mostly reservered and not written by the way) is just a way to ensure your shell doesn't crash when something goes wrong.
I hope that answers many of the concerns regarding this one recently, if not, please let me know and I'll add more to the topic.
Thanks,
Lucas
Webroot Sr. Escalation Engineer
Thank you for clarifying and explaining that so well Tech Toc! I have believed it to be a Microsoft issue all along, but I could never have explained it as you did. The 1st time I ran system analyzer and saw the message about a possible memory leak in explorer.exe, I checked here first and then researched online. So far I have not found anything of value from Microsoft.
Yes, of course it's Microsoft's fault, because it only happens with WSA and no other application that inject .dlls. Malwarebytes Anti-Exploit and Emsisoft Anti-Malware inject .dlls as well and it doesn't happen with them. I bet WSA is the only program that causes it. I suspect you have no idea on how to fix this, if you are working on it at all. I just hope Chrome will be affected as well, once x64 hits the stable channel, and every single process will consume ten times the amount of RAM it usually needs. You are just sitting on it because for most people only explorer is affected and that probably doesn't cause any issues. Just say it out loud, you don't care and you don't work on it, instead of giving these lame excuses.
Hi Lucas
How are you doing? Long time no see.
Thanks for stopping by an elucidating this issue further for us. I have to say that running both Win7 & Win8 systems there is a very clear difference between what Explorer does in each case...I suffer crashes on an underpowered Win7 system whilst the Win8 system is solid as a rock.
All that you say makes sense.
Thanks again for taking the time to share...it is much appreciated.
Regards
Baldrick
How are you doing? Long time no see.
Thanks for stopping by an elucidating this issue further for us. I have to say that running both Win7 & Win8 systems there is a very clear difference between what Explorer does in each case...I suffer crashes on an underpowered Win7 system whilst the Win8 system is solid as a rock.
All that you say makes sense.
Thanks again for taking the time to share...it is much appreciated.
Regards
Baldrick
Welcome to the community FleischmannTV!
Sorry you feel this way. Malawarebytes Anti-Exploit is NOT an antivirus protection program. It is meant to be used WITH your AV . I believe the same is for Emsisoft. Also, this issue is not a browser issue be it chrome or otherwise
Lucas, perhaps you can give FleischmannTV more info?
Sorry you feel this way. Malawarebytes Anti-Exploit is NOT an antivirus protection program. It is meant to be used WITH your AV . I believe the same is for Emsisoft. Also, this issue is not a browser issue be it chrome or otherwise
Lucas, perhaps you can give FleischmannTV more info?
Hi FleischmannTV
Whilst you have every right to air your views here it is Community Policy not to do so in a way that "Kills the Mood", and making unsubstantiated accusations and trying to goad replies out of people is certainly not the way that we are used to here. I appreciate that this may not be the way of many other forums but here we pride ourselves on being a Community and respecting/being respectful of each other.
Please, if you have not already, acquaint yourself with the Community Guidelines. ;)
Regards
Baldrick
Whilst you have every right to air your views here it is Community Policy not to do so in a way that "Kills the Mood", and making unsubstantiated accusations and trying to goad replies out of people is certainly not the way that we are used to here. I appreciate that this may not be the way of many other forums but here we pride ourselves on being a Community and respecting/being respectful of each other.
Please, if you have not already, acquaint yourself with the Community Guidelines. ;)
Regards
Baldrick
I am going to request that we keep a civil tone here. While it is PEFECTLY acceptable to have an opinion that something is not working correctly, and report such, it is not OK to be abusive by language or meaning to Webroot in general or Community members.
I understand that there are differences of opinion here, but expressing them must be made in a way that conforms to the Community Guidelines.
In particular, I think we are on the edge here of issues with the following Guidelines:
Use Your Manners.
In order to maintain a positive, productive and dynamic Community, Webroot asks that you avoid using profanity, derogatory statements or making personal attacks toward others. Never post anything that is hateful, threatening, embarrassing, pornographic or harmful. Don’t discuss divisive issues such as religion or politics.
Don’t Kill the Mood.
If you are joining the Webroot Community only to defile it, please move on. Or, if you witness someone attacking the company maliciously, Webroot kindly asks that you report the person so that Webroot can restore the Community balance (i.e. kick them out).
I understand that there are differences of opinion here, but expressing them must be made in a way that conforms to the Community Guidelines.
In particular, I think we are on the edge here of issues with the following Guidelines:
Use Your Manners.
In order to maintain a positive, productive and dynamic Community, Webroot asks that you avoid using profanity, derogatory statements or making personal attacks toward others. Never post anything that is hateful, threatening, embarrassing, pornographic or harmful. Don’t discuss divisive issues such as religion or politics.
Don’t Kill the Mood.
If you are joining the Webroot Community only to defile it, please move on. Or, if you witness someone attacking the company maliciously, Webroot kindly asks that you report the person so that Webroot can restore the Community balance (i.e. kick them out).
I can appreciate your message and view point.
According to some research, MalwareBytes Anti-Exploit doesn't inject explorer, while it might Internet Explorer. I didn't download the full version, but I do not see anything in its feature set to indicate that it has any real need to inject the shell.
I'm also not seeing any DLL injection by Emisoft, or atleast (as with MalwareBytes) no DLL's are running that are signed by these organizations.
I would be happy to provide my logs of loaded DLL's for review, but they are quite large (in length not size), but I'm not sure it would be necessary.
This behavior is very much out of our control, as it is the response of code written by Microsoft. It isn't a situation where we are blaming them, or placing them at fault. (in fact I think the idea is actually pretty smart in that it prevents the shell from crashing, and maintains system stability.)
What we are seeing is development liberties that simply couldn't exist on a 32-bit platform. When an OS has an upper limit of 4GB of RAM address space, certain concessions need to be made to ensure the system doesn't run out of available RAM. This is what created page file usage in the first place. Limits on memory address space. On a 64-bit machine, running a 64-bit application, you can address a theoretical limit of 128 TB of total memory. This means that in an age where 64-bit systems are becoming the norm, application developers can generate more features, and have the same performance as a similar application running in 32-bit space. Micorsoft simply appears to have taken some advantage of these larger spaces to provide stability improvements to the platform.
According to some research, MalwareBytes Anti-Exploit doesn't inject explorer, while it might Internet Explorer. I didn't download the full version, but I do not see anything in its feature set to indicate that it has any real need to inject the shell.
I'm also not seeing any DLL injection by Emisoft, or atleast (as with MalwareBytes) no DLL's are running that are signed by these organizations.
I would be happy to provide my logs of loaded DLL's for review, but they are quite large (in length not size), but I'm not sure it would be necessary.
This behavior is very much out of our control, as it is the response of code written by Microsoft. It isn't a situation where we are blaming them, or placing them at fault. (in fact I think the idea is actually pretty smart in that it prevents the shell from crashing, and maintains system stability.)
What we are seeing is development liberties that simply couldn't exist on a 32-bit platform. When an OS has an upper limit of 4GB of RAM address space, certain concessions need to be made to ensure the system doesn't run out of available RAM. This is what created page file usage in the first place. Limits on memory address space. On a 64-bit machine, running a 64-bit application, you can address a theoretical limit of 128 TB of total memory. This means that in an age where 64-bit systems are becoming the norm, application developers can generate more features, and have the same performance as a similar application running in 32-bit space. Micorsoft simply appears to have taken some advantage of these larger spaces to provide stability improvements to the platform.
Many thanks for the further information Lucas...most useful precisions on the topic.
Regards
Baldrick
Regards
Baldrick
Thanks! A lot of good info there.... and it really helps me as I am not a 64 bit user trying to really get my mind around the behavior.
Thanks again Lucas for the info.
As an x64 user and a user of MBAE premium I can confirm that it injects .dll's into protected applications but not explorer.exe.
Lucas has answered the Question and the issue only showed up on Win 8.1 x64 I didn't see any issues with Win 8 x64 and it continues with Win 8.1 Update 1 x64 so as Lucas said and Joe Microsoft must of added some extra protection with Win 8.1 x64 I will see if I can get any info I can share from my Microsoft MVP channels and hopefully they can point me to an article so wish me luck!
Daniel
Daniel
My experience was the same as you stated, showed up after the Win 8.1 upgrade. Good luck! Looking forward to seeing what you find!@ wrote:
Lucas has answered the Question and the issue only showed up on Win 8.1 x64 I didn't see any issues with Win 8 x64 and it continues with Win 8.1 Update 1 x64 so as Lucas said and Joe Microsoft must of added some extra protection with Win 8.1 x64 I will see if I can get any info I can share from my Microsoft MVP channels and hopefully they can point me to an article so wish me luck!
Daniel
--
Welcome to the community FleischmannTV!
Sorry you feel this way. Malawarebytes Anti-Exploit is NOT an antivirus protection program. It is meant to be used WITH your AV . I believe the same is for Emsisoft. Also, this issue is not a browser issue be it chrome or otherwise
Lucas, perhaps you can give FleischmannTV more info?
--
I know Emisoft Anti-Malware (EAM) and Malwarebytes Anti-Exploit (MBAE) very well. I also know that MBAE is not an antivirus program. EAM by the way is not a companion solution but rather a fully capable complete program.
There seems to be some confusion with my post. Some here said that neither MBAE nor EAM seem to inject into explorer. That may be right but that was not what I was intending to say. WSA causes this memory behavior in many third party 64bit applications. Most people don't see it on Win 8.1 x64 because the only affected program for most is explorer. The other native 64 bit processes of Windows are probably not monitored by Webroot and hence there is no issue with them.
When you look at programs like NoVirusThanks ExeRadarPro, Sandboxie, Softperfect Ramdisk, Windows Firewall Control and so and so forth, you'll see that they are all 64 bit processes and are affected by this memory behavior. When EAM or MBAE inject into 64 bit processes, this memory issue does not seem to happen. Hence my implication that other third-party security programs, which use dll injection, don't cause this behavior.
The reason I mentioned Chrome was not because I was confusing this with a browser issue. I merely mentioned it because the 64 bit version of Chrome is going to hit the stable release channel in a couple of weeks. Since this seems to be an issue with 64 bit processes that are monitored by Webroot, Chrome x64 will probably be affected. Chrome uses a lot of processes. One for the broker process, one for the renderer, and one for each addon and each open tab and each open plugin. So if Chrome is going to be affected, you'll will probably see half a dozen or more chrome.exe's with excess memory consumption. Whether it is going to be affected or not, I cannot say.
Welcome to the community FleischmannTV!
Sorry you feel this way. Malawarebytes Anti-Exploit is NOT an antivirus protection program. It is meant to be used WITH your AV . I believe the same is for Emsisoft. Also, this issue is not a browser issue be it chrome or otherwise
Lucas, perhaps you can give FleischmannTV more info?
--
I know Emisoft Anti-Malware (EAM) and Malwarebytes Anti-Exploit (MBAE) very well. I also know that MBAE is not an antivirus program. EAM by the way is not a companion solution but rather a fully capable complete program.
There seems to be some confusion with my post. Some here said that neither MBAE nor EAM seem to inject into explorer. That may be right but that was not what I was intending to say. WSA causes this memory behavior in many third party 64bit applications. Most people don't see it on Win 8.1 x64 because the only affected program for most is explorer. The other native 64 bit processes of Windows are probably not monitored by Webroot and hence there is no issue with them.
When you look at programs like NoVirusThanks ExeRadarPro, Sandboxie, Softperfect Ramdisk, Windows Firewall Control and so and so forth, you'll see that they are all 64 bit processes and are affected by this memory behavior. When EAM or MBAE inject into 64 bit processes, this memory issue does not seem to happen. Hence my implication that other third-party security programs, which use dll injection, don't cause this behavior.
The reason I mentioned Chrome was not because I was confusing this with a browser issue. I merely mentioned it because the 64 bit version of Chrome is going to hit the stable release channel in a couple of weeks. Since this seems to be an issue with 64 bit processes that are monitored by Webroot, Chrome x64 will probably be affected. Chrome uses a lot of processes. One for the broker process, one for the renderer, and one for each addon and each open tab and each open plugin. So if Chrome is going to be affected, you'll will probably see half a dozen or more chrome.exe's with excess memory consumption. Whether it is going to be affected or not, I cannot say.
Spot on Daniel, the finger points at something changing on the MS front between Win 8 and Win8.1, and if it is something fundemental then of course Webroot will be looking to react but it may not be a simple something to deal with, hence why time is being taken to get to the bottom of this.@ wrote:
Lucas has answered the Question and the issue only showed up on Win 8.1 x64 I didn't see any issues with Win 8 x64 and it continues with Win 8.1 Update 1 x64 so as Lucas said and Joe Microsoft must of added some extra protection with Win 8.1 x64 I will see if I can get any info I can share from my Microsoft MVP channels and hopefully they can point me to an article so wish me luck!
Daniel
I think that we have had the input from Webroot via Lucas, and at this juncture the question is fundementally answered as to why. Now we have to see what transpires next.
Baldrick
I have not seen any other 64 bit processes (non Microsoft) being effected on my 64 bit system. Could you please provide details on these other 64 bit processes?@ wrote:
There seems to be some confusion with my post. Some here said that neither MBAE nor EAM seem to inject into explorer. That may be right but that was not what I was intending to say. WSA causes this memory behavior in many third party 64bit applications. Most people don't see it on Win 8.1 x64 because the only affected program for most is explorer. The other native 64 bit processes of Windows are probably not monitored by Webroot and hence there is no issue with them.
........ this seems to be an issue with 64 bit processes that are monitored by Webroot,
Sorry, but I think Lucas addressed the issue in your post and gave excellent explanations both times. Perhaps you may want to open a support ticket or maybe call Webroot tech support. Here you will find the phone # for tech support, you can also submit a ticket as well: http://www.webroot.com/us/en/support/contact
The Webroot support team is the best tech support around and they are there to assist all of us.
Did anyone with this "problem" also get a message that physical RAM was low?
I've got 16 GB, but still the analyzer reports that physical RAM is low.
I've got 16 GB, but still the analyzer reports that physical RAM is low.
Welcome to the community AndersF!@ wrote:
Did anyone with this "problem" also get a message that physical RAM was low?
I've got 16 GB, but still the analyzer reports that physical RAM is low.
Depending on what programs and processes were running at the time, it could happen.
Please run the system analyzer againand if you get the same message, submit a support ticket.
May I ask what your system is, PC, Mac? 32 bit? 64 bit?
Please do let us know how everything is and come often and share your experiences!
Beth
@ wrote:
Did anyone with this "problem" also get a message that physical RAM was low?
I've got 16 GB, but still the analyzer reports that physical RAM is low.
Welcome AndersF to the Community Forum! 🙂 Hopefully one of our members Volunteers can itllertate this issue further!
Regards.
Hi AndersF
At the risk of being shouted down for saying it...I would not put too much store by the System Analyzer...it is provided as a facility and if I am perfectly honest I put my faith in other tools when it comes to assessing RAM usage on my system. That is not to say that it does not have it uses but in this instance I would rely on something else to give you the relevant information.
Regards
Baldrick
At the risk of being shouted down for saying it...I would not put too much store by the System Analyzer...it is provided as a facility and if I am perfectly honest I put my faith in other tools when it comes to assessing RAM usage on my system. That is not to say that it does not have it uses but in this instance I would rely on something else to give you the relevant information.
Regards
Baldrick
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.