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 couldbe a variance of 20 or 30 MB, but for most stable un-modified systems, this isn't going to be the case.
Webroot Sr. Escalation Engineer
Grashocki on the WildersForums
