Best answer by Rakanisheu RetiredView original
Best answer by Rakanisheu RetiredView original
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
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.
So when WRSA services are running File Explorer somehow takes more memory. As
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.
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.
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.
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.
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 ?
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.
My system is Windows 10 fully update as of now!
Looks like its back to 60 MB.
On WRSA 188.8.131.52
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