none
PE 16.22 consumes 800+ MB of virtual memory! RRS feed

  • Question

  • After upgrading Process Explorer from 16.12 to 16.22, I've noticed that PE memory consumption increased from typical ~50-80 MB in the old version to 800+ MB (!!!)

    Nice "improvement"! :)

    Tuesday, May 28, 2019 2:43 PM

Answers

  • I will be avoiding that then also.
    The solution seems to be; 

     v16.20
    https://web.archive.org/web/20170514152306/https://technet.microsoft.com/en-us/sysinternals/processexplorer

    or v16.21
    https://web.archive.org/web/20170726092819/https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

    • Marked as answer by andy_1618 Monday, June 24, 2019 8:21 AM
    Saturday, June 15, 2019 7:09 PM

All replies

  • I upgraded from v16.20 and lost half a gig of RAM, because this once lean and resource friendly tool that I run permanently is now the biggest thing in its own list.

    Bloaty McBloatface edition ? No thanks.

    Looks like I need to download an older copy and stay with that, or move over to the mitec alternative.


    • Edited by Dr.Flay Sunday, June 2, 2019 5:53 PM
    Sunday, June 2, 2019 5:49 PM
  • This is a problem I can confirm. It might have something to do with Win 10 1903 (mine is a fresh, clean install). I don't think this has happened in the past. Seen this using anywhere between 600-800MB of RAM, which puts it on par with a browser with few tabs open and active. Not OK.




    • Edited by Random1ze Sunday, June 2, 2019 7:29 PM
    Sunday, June 2, 2019 7:28 PM
  • I am seeing a little over 500MB Private and 360MB Working set used on my Win 10 laptop, and a little under that on my Win 7 laptop, so it is across the board but may depend on how much RAM you have.
    Both my laptops have 4GB RAM.

    I used the volume shadow service to pull the last version (16.20) back into service.

    Now it uses the more sensible 69MB Private and 38MB Working set.


    • Edited by Dr.Flay Tuesday, June 4, 2019 3:12 AM
    Tuesday, June 4, 2019 3:11 AM
  • I'm in the Preview Program, so I receive weekly build of Windows and on my machine I have no problem so far..

    Monday, June 10, 2019 12:22 PM
  • New procexp, still 700-800MB usage...





    • Edited by Random1ze Saturday, June 15, 2019 7:10 PM
    Friday, June 14, 2019 6:43 PM
  • I will be avoiding that then also.
    The solution seems to be; 

     v16.20
    https://web.archive.org/web/20170514152306/https://technet.microsoft.com/en-us/sysinternals/processexplorer

    or v16.21
    https://web.archive.org/web/20170726092819/https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

    • Marked as answer by andy_1618 Monday, June 24, 2019 8:21 AM
    Saturday, June 15, 2019 7:09 PM
  • If anybody would be willing to assist us with diagnosing this issue and provide me with a process dump file could you contact me offline at syssite@microsoft.com and I will be happy to assist.

    MarkC (MSFT)

    Monday, June 17, 2019 8:19 AM
  • Sorry, but it must be a Windows issue.. I'm on Microsoft Windows [Versione 10.0.18912.1001] and have no trouble at all..

    Monday, June 17, 2019 9:57 AM
  • If anybody would be willing to assist us with diagnosing this issue and provide me with a process dump file could you contact me offline at syssite@microsoft.com and I will be happy to assist.

    MarkC (MSFT)

    Thanks for looking into this, I shared with this email address a zip containing a full dump of the procexp64 process. Now using 930MB of RAM here.



    • Edited by Random1ze Monday, June 17, 2019 3:42 PM
    Monday, June 17, 2019 3:42 PM
  • Updated to 16.25. The problem is still here. It consumes 433MiB in my case at this moment.

    Friday, June 21, 2019 4:31 PM
  • Yep. After Windows 10 update to version 1903, same issue:
    PE 16.12: 60-90 MB of virtual memory
    PE 16.21: 60-90 MB
    PE 16.22: 800-900 MB
    PE 16.25: 800-900 MB


    Monday, June 24, 2019 8:14 AM
  • Can anyone with the problem save a text file with the export of the following information: 

    Name, file version, WS Total, WS Private, WS SHareable, WS Shared.

    

    Select Process Explorer, show load dll, select the necessary columns, and then press the save Button..

    Thanks
    -mario

    • Edited by mariora_ Monday, June 24, 2019 1:23 PM
    Monday, June 24, 2019 1:22 PM
  • Can anyone with the problem save a text file with the export of the following information: 

    Name, file version, WS Total, WS Private, WS SHareable, WS Shared.

    

    Select Process Explorer, show load dll, select the necessary columns, and then press the save Button..

    Thanks
    -mario

    Here you go:

    https://1drv.ms/t/s!AlyBPrVBi3Pnq16EY0SsWRcV3h02?e=YwKJwM

    • Edited by Random1ze Monday, June 24, 2019 1:43 PM
    Monday, June 24, 2019 1:42 PM
  • looks fine..

    Is it possible that you have an old procmon driver in memory?
    Can you check?

    Monday, June 24, 2019 2:00 PM
  • looks fine..

    Is it possible that you have an old procmon driver in memory?
    Can you check?

    This is mine:



    • Edited by Random1ze Monday, June 24, 2019 2:05 PM
    Monday, June 24, 2019 2:04 PM
  • Ok, I don't have many more suggestions in this case.. last thing to try RamMap..

    I just started it and saw lot of memory in use, then moved to the Process Tab, and noticed I've lot of zombies around..

    My active session is 5 but I've a lot of handle open in other sessions which are in size 32k.. those are all zombies, but this is another problem..

    Please, have a look at RamMap in the Process tab and look at your Process Explorer numbers.
    Then try to clean and refresh each time the memory, and see what happen.

    From the menu Empty, start from the top, Empty Working Sets, and exec all the empty command from working sets to Priority 0 Stand by list, and each time press refresh and look at your Process Explorer memory occupation..

    Let me know if somehow the memory occupation change.

    Thanks
    -mario

    Monday, June 24, 2019 2:24 PM
  • I just noticed that your machine is a VMWare virtual machine..

    Does this problem repro also on a physical machine or just inside this VM?

    Thanks
    -mario

    Monday, June 24, 2019 2:35 PM
  • I put it on video. Better to see what's happening. RAMMAP also seems to use lots of RAM.

    https://youtu.be/WF24GKMQgdk

    Oh, and it's not a VM. It's just a PC with VMware installed on it. VMWare is not active/started. Those must be some services running at boot you've noticed. All of these pics are without any VM running. Always used VM to test unsafe apps or just run things that I don't want to clutter my PC, this didn't happen in the past.
    • Edited by Random1ze Monday, June 24, 2019 2:56 PM
    Monday, June 24, 2019 2:51 PM
  • so, if you empty the working set then memory allocation goes down to normal..

    Is it possible this has to do with the VMWare feature of dynamic memory??

    Unless for some reason, memory is allocated in the process and never released as part of the normal behavior of a windows application.. just like it is locked/referenced by something and so only rammap can release it.

    On a non virtual machine do you have the same problem??

    Thanks!
    -mario

    Monday, June 24, 2019 3:00 PM
  • so, if you empty the working set then memory allocation goes down to normal..

    Is it possible this has to do with the VMWare feature of dynamic memory??

    Unless for some reason, memory is allocated in the process and never released as part of the normal behavior of a windows application.. just like it is locked/referenced by something and so only rammap can release it.

    On a non virtual machine do you have the same problem??

    Thanks!
    -mario

    I don't think it has anything to do with VMware being installed, because this is a new issue that only appears in .22 and .25. This is proceXP 16.21 running normally on the exact same PC, with the same VMware installed.

    • Edited by Random1ze Monday, June 24, 2019 3:05 PM
    Monday, June 24, 2019 3:03 PM
  • In my experience, when a process uses and never releases memory it is because something holds a reference to it. Generally, when a dll is loaded into a process, it will uses private bytes as in your case, then when it gets released, the private bytes are returned to the system.

    When this doesn't happen? When a driver or a malfunctioning application is not releasing a handle to those dlls.

    If you using Ram Map are able to restore the normal functioning it means that the dlls have been marked to be released correctly but at the first tentative the OS was unable to release them. Trying again with RamMap worked successfully..

    So, I would look for malfunctioning antivirus or injected dlls not working correctly.

    Looking at your text file I see that ou only have three components injected in the process:

    C:\Program Files\Common Files\microsoft shared\ink\en-US\TipTsf.dll.mui
    C:\Program Files\Common Files\microsoft shared\ink\tiptsf.dll

    C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.1905.4-0\MpOAV.dll

    All microsfot DLLs, so I wouldn't expect them to be a problem, but who knows...

    Try disabling the ink feature and the antivirus and see what happen..

    Then try to update the VMWare tools if they are not already the latest version..

    Monday, June 24, 2019 3:17 PM
  • VMWare is up to date. Previous versions of procexp do fine. Ink settings are at their default. Obviously I'd prefer using an old version/Task Manager instead disabling the AV and Ink.


    • Edited by Random1ze Monday, June 24, 2019 3:59 PM
    Monday, June 24, 2019 3:59 PM
  • Because this happens to a few people, please, post the loaded device drivers list as you have made for the dlls, so we can try to spot common loaded driver which may be the culprit here..

    More people will share they loaded drivers more chance we will have to solve this problem.. Hopefully.. 

    Thanks 

    -mario

    Monday, June 24, 2019 6:17 PM
  • Drivers. 

    https://1drv.ms/t/s!AlyBPrVBi3Pnq19WzXt6_FdK0jFN?e=puq5XW


    • Edited by Random1ze Monday, June 24, 2019 6:22 PM
    Monday, June 24, 2019 6:22 PM
  • I would start uninstalling these drivers if possible:

    HWiNFO64A.SYS C:\Users\razie\AppData\Local\Temp\HWiNFO64A.SYS

    ssdevfactory.sys C:\Windows\System32\drivers\ssdevfactory.sys

    sshid.sys C:\Windows\System32\drivers\sshid.sys

    There is also some problems with your VMWare setup.. drivers are from many different distributions.. Can you pleaseinstall the latest VMWAre tools from https://docs.vmware.com/en/VMware-Tools/10.3/rn/vmware-tools-10310-release-notes.html

    Thanks
    -mario

    Monday, June 24, 2019 8:16 PM
  • I need HWINFO64. I also need the Steelseries drivers, I have a SS mouse/keyboard combo. Windows would get them off the Windows Update even if I uninstall, not to mention I'd lose access to settings like profiles and illumination. HWiNFO is just monitoring the PC components. If I don't run it, the issue still occurs (it's portable, not installed).

    Again, it's important to understand that 16.21 works just fine with these drivers. All the procexp version work normally, besides the last 2. I am running 16.21 at this moment and it is consuming around 80MB. 

    So it is a change introduced in the last 2 versions of procexp that's causing it. Probably in interaction with some PC configs, yes, but I'd welcome a return to the way it worked before, where I don't need to uninstall apps I need and use. 

    VMWare Tools is NOT intended for the Host. It's intended for the VMs themselves. The installation is fine and up to date. Checked just now. 
    • Edited by Random1ze Monday, June 24, 2019 8:24 PM
    Monday, June 24, 2019 8:23 PM
  • Then the only one that can do something for you is MarkRuss.. 

    you may capture a dump of Procexp and send it in for examination..

    The fact that RamMap reduced the memory occupation looks to me like something that get loaded in memory many times and is not released correctly, so it stays there until forcibly unloaded by RamMap..

    In any case I'm pretty sure that you can't repro the problem on another computer, so I bet on something on your system causing the problem more than an issue in ProcExp:-)

    Thanks
    -mario

    Tuesday, June 25, 2019 7:06 AM
  • Thanks to the users who have provided us with memory dumps. We are currently looking at this issue and hope to provide an update soon.

    MarkC (MSFT)

    Wednesday, June 26, 2019 8:26 AM
  • An update this issue...

    Thanks to some exceptional assistance from the community I have been able to isolate this to a specific code path that is only used when certain columns are visible in the main view. In all cases that I have looked at this was due to the CPU history column being enabled but other columns to avoid are Process Timeline, Private Byte History and IO History.  I was able to reproduce the issue by enabling the CPU history column at which point the memory consumption grew quickly to over 1GB.

    The obvious workaround for now is to disable these columns if you have them enabled (and to leave them well alone if you don't). I am working on a solution to this now and will update once we have a full resolution.

    Thanks again to all who helped.

    MarkC (MSFT)



    Thursday, June 27, 2019 9:34 AM
  • Damn, I owe t0yz a beer! :-)
    Thursday, June 27, 2019 10:29 AM
  • Mark has more sophisticated tools and knowledge than us regular users and is process debugging savvy. A vast majority of issues are easily solvable with regular troubleshooting steps, so I still thank you for the help.

    • Edited by Random1ze Thursday, June 27, 2019 10:36 AM
    Thursday, June 27, 2019 10:36 AM
  • 16.26 is available for download:

    https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

    It solved the issue for me. 

    All credit for MarkC, who did an incredible job.

    • Edited by Random1ze Saturday, June 29, 2019 4:09 AM
    Saturday, June 29, 2019 4:08 AM
  • Was just about to post about this myself. But yes to confirm 16.26 contains the fix. Please let me know if you experience any further issues and thanks to everybody who reported this issue and helped us to resolve it. 

    MarkC (MSFT)

    Saturday, June 29, 2019 7:33 AM
  • Seems like the new versions introduced high CPU consumption also. I have created a separate topic about it:

    https://social.technet.microsoft.com/Forums/en-US/924ebc6d-363c-49a4-9b5b-8da0fafd089b/high-cpu-consumption-on-start-after-upgrade-from-1621-to-1626-one-cpu-core-is-loaded-for-100-up?forum=procexplorer

    Sunday, June 30, 2019 8:28 AM