The case of the programs that were launched with impossible command line options
Several years ago, a bug was filed automatically due to a spike in failures in the Start menu with a new crash profile. Investigation of this bug was rather complicated, because the crash was “impossible”.
Then again, a lot of failures seem to be “impossible”, but the fact that they’re happening proves that it’s possible, and you just have to do some sleuthing and adopt a more creative mindset to figure them out.
One of the tools for investigating these types of failures is seeing what other programs are running at the time, or what other programs crashed shortly before or after the failure occurred. In this case, whenever the crash occurred, there was one specific third-party program running. This program billed itself as a utility that boosts your system’s gaming performance by terminating all processes it deemed to be non-essential. Its advertising copy calls out useless “productivity apps” as one of those non-essential processes. (Yeah, how dare you let a computer be used for productivity? Can’t you see I’m playing a game?)
Apparently, what happens that when the program detects that you’re playing a game, it runs around and simply terminates all the non-essential processes.
I sure hope you saved your work.
And when the game is over, it relaunches all the programs it terminated, presumably on the assumption either that you didn’t care about your unsaved data, or that the program would go into crash recovery mode and restore its state from the most recent auto-save point.
And one of the programs that this utility decide was not worthy of keeping around was the Start menu, so it terminated it when your game started. And then when the game was over, it relaunched it.
And that’s what was causing the problem.
For you see, the utility relaunched the program as a normal program with no command line arguments. But the Start menu is a UWP program, so it is supposed to be launched a special way, with specific command line arguments, and it is supposed to be run in a low integrity app container. As a result, the Start menu found itself running in an unexpected environment, with an unexpected command line, and it realized that something was messed up and failed fast, leaving a nice corpse for Watson to analyze.
The issue was transferred to the vendor outreach team for them to inform the vendor of the problem and get them to stop terminating the Start menu.¹
Epilogue: It seems that the vendor got the message on their own, because they issued an update that addressed this problem before the vendor outreach team got a hold of them.
¹ More generally, instead of terminating UWP apps, just minimize them, which causes them to save their state and suspend. If the system is placed under memory pressure, the system will terminate suspended UWP apps automatically.
Light
Dark
6 comments
From time to time I find myself needing to run alternate shells (usually cmd.exe — I haven’t put forth the effort to actually make a low-impact GUI shell yet); this is getting really hampered because there’s no published way to launch UWP apps without explorer running, and with more and more stuff being moved from control panel to settings this is become more often needed.
But explorer is still a hog, and still needs half a GB RAM for itself (measured by paging impact with shell = cmd.exe vs shell = explorer.exe).
Right at this moment, in the computer I’m writing this on (running Windows 10 21H2 x64), I have five open Explorer windows (one on a folder with over a thousand files) and a single cmd.exe. Explorer is “wasting” 24,4 MB in the process that hosts the folder windows, and 52 MB in the desktop/taskbar/notifications process, while cmd.exe and conhost.exe are taking 7,1 MB. A 11:1 ratio, yes. But when you take into account that Explorer has five instances open, it’s more like a 2:1 ratio. Not bad at all for a graphical vs. command line comparison, which is unfair in itself. And very far from the half a gigabyte you are spotting on your system. I’d recommend you to run SysInternals’ Autoruns and look for the shell extension(s) which are hogging memory.
For what it’s worth, I recently did what Joshua did and observed the same result. When explorer.exe is the default shell, many additional things are launched – SearchHost, StartMenuExperience, SmartScreen – and when I first did this I observed basically the same number, 500Mb of physical memory used. The sum of the commits is substantially less.
Instead of explorer, I was using yui which provides a trivial start menu and task bar, so it’s still graphical.
Unfortunately it’s not terribly practical due to the amount of things explorer is involved in these days. On Windows 11, doing this means you don’t get round borders anymore, for example.
AKA – “what can we sell schmucks that don’t understand how computers work?”.
Until I read to UWP start menu, I couldn’t imagine it’s something in Windows NT era.
There are some “memory cleaning” applications that uses `SetWorkingSet` to make the memory usage low, but terminating processes is so rude.
I remember Watson from snooping in the Windows folder during the ME era. It’s kinda cute that Watson’s still being used for debugging purposes years later