Windows 8.1 Professional.
http://s020.radikal.ru/i710/1310/58/6460089d2a94.jpg
http://i031.radikal.ru/1310/d4/ecd121410c70.jpg
Page 1 / 15
Yes I do have an update!
Working through the current issues, I have raised this to my TOP ISSUES report and given it a medium severity with high priority.
There is a current build in QA being tested against a number of bug fixes but I will see when we can this fix into a build and update this thread once I know more.
Thanks all, stay tuned!
Working through the current issues, I have raised this to my TOP ISSUES report and given it a medium severity with high priority.
There is a current build in QA being tested against a number of bug fixes but I will see when we can this fix into a build and update this thread once I know more.
Thanks all, stay tuned!
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
So, I did some digging into this. And, like most things the answer is more complicated than it looks. When Windows reports 'MEMORY' this is an aggregate of the ENTIRE memory pool. This includes several different types of memory, what I mean by that is the term 'MEMORY' is more than just RAM. Things that are calculated into this factor are as follows:
RAM
Working Set
Commit Memory
Paged Pool
Non-Paged Pool
To get the overall idea hear, is that while Explorer is running (on my Windows 8.1 box) at 284.1 MB of 'MEMORY' it breaks down further like this
RAM usage:
Private - 2,384 K
Page - 276 K
Total - 2,660 K (2.59 MB)
SWAP usage:
Commit - 56,852 K
Working Set - 361,072 K
Sharable - 64,480 K
Private - 296,580 K
Total - 778,984 K (760.72 MB)
When calculating the above SWAP usage this includes DLL's, drivers, and other files that Explorer calls as the system shell. UI elements such as your wallpaper, icons, clock, system tray etc are all factored into items that are loaded into SWAP space.
In layman’s terms SWAP space is a location on your hardrive that is reserved for offloading certain low priority tasks to the HDD in order for higher priority functions (such as programs) to address into RAM.
NOTE: Edited to correct details regarding WSA's role in this explanation:
WSA reserves a fair amount of SWAP space in the Explorer process in order to provide certain functions such as monitoring read/write activity on the HDD, and Journaling and Monitoring of unknown processes.
Explorer MEMORY is being used because of Microsoft identifying our DLL and increasing the page protection in case it were to try to crash Explorer. This is a fault protection built into Explorer on Windows 8, and not the result of WSA.
I provide all of the above information, to provide a detailed explanation that if followed to its conclusion means that what you see in the Task Manager isn't really true from a certain perspective, and includes more than one would normally think. Ultimately however, the 'issue' is one of perception, not one with the software itself near as I can tell. There should be no actual performance hit here unless you are running on very very old hard drives, and or, do not have enough hard drive space to support the size of the SWAP file.
I hope this helps explain what you are seeing. Some tools that can be used to navigate this information can be found on Microsoft's SysInternals site (http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx) and include RAMMap, and VMMap, as well as the Windows Resource Monitor found at the lower portion of the Window when on the Performance tab of the Task Manager.
Thanks,
Lucas
AKA - TechToc
Webroot Sr. Escalation Engineer
RAM
Working Set
Commit Memory
Paged Pool
Non-Paged Pool
To get the overall idea hear, is that while Explorer is running (on my Windows 8.1 box) at 284.1 MB of 'MEMORY' it breaks down further like this
RAM usage:
Private - 2,384 K
Page - 276 K
Total - 2,660 K (2.59 MB)
SWAP usage:
Commit - 56,852 K
Working Set - 361,072 K
Sharable - 64,480 K
Private - 296,580 K
Total - 778,984 K (760.72 MB)
When calculating the above SWAP usage this includes DLL's, drivers, and other files that Explorer calls as the system shell. UI elements such as your wallpaper, icons, clock, system tray etc are all factored into items that are loaded into SWAP space.
In layman’s terms SWAP space is a location on your hardrive that is reserved for offloading certain low priority tasks to the HDD in order for higher priority functions (such as programs) to address into RAM.
NOTE: Edited to correct details regarding WSA's role in this explanation:
WSA reserves a fair amount of SWAP space in the Explorer process in order to provide certain functions such as monitoring read/write activity on the HDD, and Journaling and Monitoring of unknown processes.
Explorer MEMORY is being used because of Microsoft identifying our DLL and increasing the page protection in case it were to try to crash Explorer. This is a fault protection built into Explorer on Windows 8, and not the result of WSA.
I provide all of the above information, to provide a detailed explanation that if followed to its conclusion means that what you see in the Task Manager isn't really true from a certain perspective, and includes more than one would normally think. Ultimately however, the 'issue' is one of perception, not one with the software itself near as I can tell. There should be no actual performance hit here unless you are running on very very old hard drives, and or, do not have enough hard drive space to support the size of the SWAP file.
I hope this helps explain what you are seeing. Some tools that can be used to navigate this information can be found on Microsoft's SysInternals site (http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx) and include RAMMap, and VMMap, as well as the Windows Resource Monitor found at the lower portion of the Window when on the Performance tab of the Task Manager.
Thanks,
Lucas
AKA - TechToc
Webroot Sr. Escalation Engineer
Howdy folks,
We are definitely aware of this but unfortunately there are bigger fish to fry out there and this issue has received a low priority. It is not terribly wide spread as Win 8 is not a big hit (c'mon Win 9) and really only you power users who like to stare at their resources have noticed this. Yes I am definitely guilty of this as well...;)
It is on the radar and I am sure that development will get this resolved in an upcoming build.
Thanks all and stay tuned!
We are definitely aware of this but unfortunately there are bigger fish to fry out there and this issue has received a low priority. It is not terribly wide spread as Win 8 is not a big hit (c'mon Win 9) and really only you power users who like to stare at their resources have noticed this. Yes I am definitely guilty of this as well...;)
It is on the radar and I am sure that development will get this resolved in an upcoming build.
Thanks all and stay tuned!
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.
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.
Well sorry to hear your not using WSA. You must be really struggling with system issues if you cant spare 300mb of paged memory however.
Hey TH,
I updated the original post a bit to reflect a beter explanation of why we are seeing an increase in memory usage on Windows 8. I wasn't aware of the difference on 32 bit machines. But I'll get to that in a minute. I've included my update below:
NOTE: Edited to correct details regarding WSA's role in this explanation:
WSA reserves a fair amount of SWAP space in the Explorer process in order to provide certain functions such as monitoring read/write activity on the HDD, and Journaling and Monitoring of unknown processes.
Explorer MEMORY is being used because of Microsoft identifying our DLL and increasing the page protection in case it were to try to crash Explorer. This is a fault protection built into Explorer on Windows 8, and not the result of WSA.
Now, to get to the reason we aren't seeing it on 32-bit systems.
I suspect this is because a 64-bit protected process requires a bit more memory. Because Explorer runs as 64-bit on these systems it would make sense to me to consider that any fault prevention would require additional resources in order to ensure the integrity of the process. I do not have a 32 bit Windows 8 machine with me at the moment, but I can run a test, with the idea that while on my system (64 bit) Explorer was running in about 2.5 MB of RAM, I hypothize that a similar configuration on 32 bit would be less than that. RAMMap should provide that detail if you want to beat me to the punch. I do want to state for the record that this is just what makes sense to me without seeing any further details.
Thanks,
Lucas
I updated the original post a bit to reflect a beter explanation of why we are seeing an increase in memory usage on Windows 8. I wasn't aware of the difference on 32 bit machines. But I'll get to that in a minute. I've included my update below:
NOTE: Edited to correct details regarding WSA's role in this explanation:
WSA reserves a fair amount of SWAP space in the Explorer process in order to provide certain functions such as monitoring read/write activity on the HDD, and Journaling and Monitoring of unknown processes.
Explorer MEMORY is being used because of Microsoft identifying our DLL and increasing the page protection in case it were to try to crash Explorer. This is a fault protection built into Explorer on Windows 8, and not the result of WSA.
Now, to get to the reason we aren't seeing it on 32-bit systems.
I suspect this is because a 64-bit protected process requires a bit more memory. Because Explorer runs as 64-bit on these systems it would make sense to me to consider that any fault prevention would require additional resources in order to ensure the integrity of the process. I do not have a 32 bit Windows 8 machine with me at the moment, but I can run a test, with the idea that while on my system (64 bit) Explorer was running in about 2.5 MB of RAM, I hypothize that a similar configuration on 32 bit would be less than that. RAMMap should provide that detail if you want to beat me to the punch. I do want to state for the record that this is just what makes sense to me without seeing any further details.
Thanks,
Lucas
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.@ 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.
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.
Please don't try to scare other users as there is no instability at this time and it's being worked on.
Thanks,
Daniel
Thanks,
Daniel
Just a quick note on this topic. The behavior of Explorer is a result of Microsoft building fault tolerance into their software to prevent against crashes. This IS a good thing. It increases the overall stability of the operating system.
While we can control what we do, we have no control over what Microsoft chooses to do as a result. The Explorer process detects the inclusion of a non-Microsoft injected DLL and adds some additional buffers in place in the event that DLL causes a shell crash.
I hope that helps add another side to the coin when considering this behavior.
Thanks,
Lucas
While we can control what we do, we have no control over what Microsoft chooses to do as a result. The Explorer process detects the inclusion of a non-Microsoft injected DLL and adds some additional buffers in place in the event that DLL causes a shell crash.
I hope that helps add another side to the coin when considering this behavior.
Thanks,
Lucas
Hi Beeblebrox
No problem...that is what the Community is here for. :D
Yes, the issue is peculiar to Win 8/8.1/U1 64bit...I also have a tablet running Win 8 8.1U1 32bit and do not have the issue...so all in all very strange.
Of course, this is not good for those 64bit users and it has been going on a while but as has been stated before...it in no way affects the efficacity & protection provided by WSA...one is well protected regardless...and hopefully the Development Team will get to the bottom of this at some point soon.
Enjoy the trial, and please feel free to post back here with further questions on the topic or open a new thread if you have questions on a different topic. ;)
Hope to see you around in the future.
Regards
Baldrick
No problem...that is what the Community is here for. :D
Yes, the issue is peculiar to Win 8/8.1/U1 64bit...I also have a tablet running Win 8 8.1U1 32bit and do not have the issue...so all in all very strange.
Of course, this is not good for those 64bit users and it has been going on a while but as has been stated before...it in no way affects the efficacity & protection provided by WSA...one is well protected regardless...and hopefully the Development Team will get to the bottom of this at some point soon.
Enjoy the trial, and please feel free to post back here with further questions on the topic or open a new thread if you have questions on a different topic. ;)
Hope to see you around in the future.
Regards
Baldrick
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.
Thanks Explanoit!
I have completed testing and found no workaround. luckily it is not brining systems to a hault just yet...
I have passed along process dumps, logs, etc to development and they should be looking into this shortly, or as Explanoit stated, they may already be working on this.
Thanks again all, stay tuned.
I have completed testing and found no workaround. luckily it is not brining systems to a hault just yet...
I have passed along process dumps, logs, etc to development and they should be looking into this shortly, or as Explanoit stated, they may already be working on this.
Thanks again all, stay tuned.
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
Your very Welcome! I think @ has allot on his plate ATM till the end of the year maybe he will stop by and say hello!
Thanks,
Daniel 😉
Thanks,
Daniel 😉
I reported it to the Microsoft Community Support Forums and it seams this KB3000850 has broken Avast but fixed it for us: http://answers.microsoft.com/en-us/windows/forum/windows8_1-windows_update/major-issues-with-kb3000850/5cb4cddd-52da-44af-9fd5-3ae1a72b0b1a?page=5&tm=1417020252172#LastReply
Cheers,
Daniel 😉
Cheers,
Daniel 😉
Hello Muddy and TH,
I'm fairly confident that there isn't any cause for concern, unless the OP is reporting performance issues in addition to what was observed.
To further assist with some understanding here, 'MEMORY' is not 'RAM.' RAM is a very specific type of MEMORY. It's a temporary very fast location that allows your system to load files and programs quickly.
'MEMORY' as it is refered to in the OP (from my perspective) is actually a collection of different types of MEMORY and when viewing the report in Task Manager it's all added together to determine the actual memory footprint on the system.
The reality is such that Explorer isn't using 300mb of RAM, but 300mb of MEMORY which is broken down to several layers. It is really only using between 2 and 4mb of RAM while the rest of it is various other types of memory, other than RAM.
Memory management is a very difficult thing to explain because there are so many different types of memory. I spent a good month or so looking into it so that I could provide some insight to another customer who had asked similar questions regarding memory usage on the system.
I'm fairly confident that there isn't any cause for concern, unless the OP is reporting performance issues in addition to what was observed.
To further assist with some understanding here, 'MEMORY' is not 'RAM.' RAM is a very specific type of MEMORY. It's a temporary very fast location that allows your system to load files and programs quickly.
'MEMORY' as it is refered to in the OP (from my perspective) is actually a collection of different types of MEMORY and when viewing the report in Task Manager it's all added together to determine the actual memory footprint on the system.
The reality is such that Explorer isn't using 300mb of RAM, but 300mb of MEMORY which is broken down to several layers. It is really only using between 2 and 4mb of RAM while the rest of it is various other types of memory, other than RAM.
Memory management is a very difficult thing to explain because there are so many different types of memory. I spent a good month or so looking into it so that I could provide some insight to another customer who had asked similar questions regarding memory usage on the system.
Excellent it's been said since Win 8.1 x64 came out it was never WSA's fault now Microsoft have to add this fix to the new Win 10 Preview x64 hopefully by the release of it!@ wrote:
I also, updated that window update, and I notice my Explorer is using around 48 MB
Thanks
Thanks,
Daniel 😉
The issue of 'C:Program' is related to Webroot, but unrelated to the 300MB Memory issue in this thread.
The issue of C:Program is a truncated WRSA install, that while running, isn't quite running correctly. To resolve it:
If WRSA is running from Program files, uninstall it, and reboot
Rename the file to C:Program.exe
From a CMD line run: C:Program.exe -showgui
You'll see the WRSA UI
From a CMD line run C:Program.exe -uninstall
Follow the uninstall prompts, and reboot
If this doesn't work, please let me know via a PM your email address via so that I can track your case down and we can setup a remote session.
Thanks,
Lucas Moore
The issue of C:Program is a truncated WRSA install, that while running, isn't quite running correctly. To resolve it:
If WRSA is running from Program files, uninstall it, and reboot
Rename the file to C:Program.exe
From a CMD line run: C:Program.exe -showgui
You'll see the WRSA UI
From a CMD line run C:Program.exe -uninstall
Follow the uninstall prompts, and reboot
If this doesn't work, please let me know via a PM your email address via so that I can track your case down and we can setup a remote session.
Thanks,
Lucas Moore
Greetings community.
I think since the release of the KB3000850 update this infamous bug seems to be resolved, or at least in my case. It looks like something on Microsoft's end has changed. I have not been able to reproduce this bug since. Explorer is back to normal and other 64-bit applications, which are injected with wrusr.dll, are no longer affected as well.
Great news.
I think since the release of the KB3000850 update this infamous bug seems to be resolved, or at least in my case. It looks like something on Microsoft's end has changed. I have not been able to reproduce this bug since. Explorer is back to normal and other 64-bit applications, which are injected with wrusr.dll, are no longer affected as well.
Great news.
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.
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 just noticed the optional update in windows update and did it. And yes it seems to have reduced the memory used.
I would take the advice of Rakanisheu as he is very correct on the newer OS's like Win 7, Win 8.1.1 and being 64bit 16GB of RAM Windows doesn't set to 24GB of PageFile and if you use SSD's then there is no Bottle Neck so the reason your seeing Windows saying no Memory left and I see Roy has post and the article he posted is correct IMO.
Daniel 😉
Daniel 😉
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
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.