If Explorer is killed and then restarted from an elevated process, the final explorer.exe process gets a wrong (low) memory priority about windows-dev-performance HOT 5 CLOSED

To give some extra context, I first ran into this scheduled task issue (or perhaps a restart manager issue, but probably the same root cause) in 2009 or 2010 while working at Microsoft. I then hit it again at my next job. And it's still around.

It can be an extremely painful bug because low memory priority means that a process' working set will be drained and then can easily end up being swapped out to disk. Any programs that are launched from explorer.exe will inherit the low memory priority which can easily end up being most processes the user is running.

When I first encountered it the low memory priority would propagate from explorer.exe to Visual Studio (when I launched it from explorer.exe with a lowered memory priority) and if I didn't use VS for a while it's working set would be drained, and if I left it alone for longer its memory would be written to the page file. This meant that when I went to go use VS it would have to read in hundreds of MB of data from the page file. This was on an old-style spinning disk so this was extraordinarily painful.

A lot has changed since then (memory compression, SSDs) which may change the impact of this bug, but it is still a bug. Thank you for finding a particularly simple way to reproduce it. I hope it gets fixed.

from windows-dev-performance.

The bug (well, some form of it at least) dates back far before Windows Server 2016. I first saw it in 2009 when working on Internet Explorer at Microsoft. We were experimenting with updating IE without restarting the computer, and that required restarting explorer. Explorer would start with low memory priority, so would anything that was launched from explorer, and pretty soon Visual Studio's working set would be drained away to the page file on a slow spinning disk.

The only change since then is that now when the bug hits the trimmed pages are more likely to be compressed or stored on an SSD, so the consequences are less severe.

But, it's still a bug.

from windows-dev-performance.

The bug mentioned above by Chris has been fixed and in a GA release since 22H2 (22621+).

from windows-dev-performance.

For MS people follow along on the bug here.

from windows-dev-performance.

Caught by this unexpected/undocumented behavior apparently introduced in Windows Server 2016 (I'm on Windows Server 2019):

• Already using <Priority>5</Priority> to overcome the Below Normal (<Priority>7</Priority>) assigned by default
• Noticed the unexpected Below Normal memory priority (using Process Hacker, where it's labelled Page priority)
• Setup two scheduled tasks to assert the behavior:
  • the one with <Priority>5</Priority> got Normal process priority and Below normal memory priority
  • the one with <Priority>4</Priority> got Normal for both process and memory priorities

At a minimum, this means that documentation for Priority (settingsType) Element is incomplete; furthermore, pairs of numbers - such as 4 and 5 - are presented in a way they look equivalent, which is deceiving.

from windows-dev-performance.