Programs that were launched with impossible command line options | Hacker News Reader

Programs that were launched with impossible command line options

devblogs.microsoft.com

52 pointsheadalgorithm47 comments

I was a little mystified when I read the following sentence, since the start menu (and taskbar) has in my experience always been part of explorer.exe, and not a separate process (unless he was referring to explorer.exe itself, which I've killed and restarted a few times without issue, so that couldn't be it either):

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 then all became clear shortly after:

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.

Raymond is obviously going to be pro-MS, but I can't decide whether the ultimate blame here is the third-party utility, or MS for the design decision that somehow the start menu needs to be its own process, require commandline arguments and whatever starts it to do something special (unlike explorer.exe, which establishes its own environment appropriately) or indeed the whole shitshow that is UWP.

It seems people have tried replacing the shell with one from an older version of Windows, but it's not a direct drop-in (e.g. https://www.youtube.com/watch?v=RUsbU73Idx4 , warning: audio is useless); with some additional work, I suppose it might be possible.

The fact the start menu lives in its own process is an implementation detail, no official documentation says the start menu is part of explorer.exe, so no one should expect start menu to be part of explorer.exe. Third party utilities should never kill random processes to begin with... that's a non-sense.

Why shouldn’t they kill processes? If the OS didn’t want third party apps to be able to kill random processes it wouldn’t provide APIs for it to do so.

no official documentation says the start menu is part of explorer.exe

I'm pretty sure the older versions of Windows actually had that in the (much more detailed) documentation they came with.

Killing and restarting explorer.exe on Windows 10 is not supported and causes UWP apps to fail to interop with the system afterwards (even apps launched after explorer.exe was terminated).

Go ahead and do it, then try to open a link in the UWP mail app by clicking on it. It doesn’t work for me ever after until I reboot my PC.

This further reinforces why I've fortunately never had to --- and don't ever want to --- use UWP apps. It seems like one horrible design decision after another.

On the other hand, explorer.exe seemingly wants to crash or hang semi-regularly, especially when accessing network drives, and needs to be killed and restarted to regain control.

Can someone explains why explorer crashes when dragging files (unintentionally) over an offline mapped network drive?

I feel like this is a basic thing that should have come up in testing.

Network filesystems seem to be one of those things that's remarkably tricky to get right; my experience with that on Linux hasn't been much better, i.e. mounted drives that have become disconnected can cause anything from tens-of-minutes-long waits to forever hangs. I think it's a tension between giving up too easily (and thus you get errors in applications whenever the network is even slightly intermittent) and trying too hard to reconnect (permanent hangs, in the case of infinite retries.)

>Killing and restarting explorer.exe on Windows 10 is not supported

so what are you supposed to do if explorer hangs or freezes?

That's the question, right? The official answer appears to be "it can't/doesn't happen" ... and when it does, you really do have to reboot.

Unfortunate. That exact situation has happened to me multiple times on win7 and killing and restarting explorer.exe always seemed to work. Really poor systems design from Microsoft here

Seems to be working fine on my machine.

I went to Task Manager, details tab; found explorer.exe (there was exactly 1) and killed it

Hit File -> Run New Task; Entered "explorer"; hit Enter

Switched to Mail and clicked a link in one of the emails - it worked.

It's funny to read this. My system did something similar to me today, since I run a python script that sacrifices (kills) memory hogs that end up contributing to total system lock up in Linux:

https://askubuntu.com/a/1018733

So there I was, working on an illustration in Inkscape, zoomed in a bunch, selected a path, and after a brief lockup, no mouse cursor movement even available, boom. Inkscape was auto-killed and the script sent a notifier that it had intervened in this way for the greater good. Mouse cursor moveable again. And OK, so I was running up against the limit for sure, tons of memory use.

There is supposedly built-in system tooling that handles this in Linux, but it doesn't. In the meantime I'm happy for my little script I found online, because the whole point is to break just one or two things and hand some control back to me, instead of breaking _everything_.

https://askubuntu.com/questions/1258371/oom-killer-never-run...

In case you haven't already seen it, there's a relatively widely packaged program called earlyoom to do this. Especially helpful because it lets you tell it what to try and kill first, and what to try and spare.

Oh that's cool. Yeah I'd much rather it kill Firefox or all my VLC windows than my artwork. Thank you.

Happy to help:) Yeah, I set it to kill Firefox since that's "safe" and that's usually the memory hog in the first place:)

Linux's OOM killer always seems to run too late (once it's already locked up meaning it takes like half an hour for it to free up the memory. It's been like this for years, so I hope someone eventually fixes it.

For sure, it seems like a really strange problem. However I've noticed it's not consistently an issue across various Linux systems I run here. So I wonder if this variance due to different configurations (or whatever it is) has led to a lack of a louder "please fix ASAP" sentiment.

I wonder if they could implemented some sort of logging where people could submit cases where it's failed for them.

Add some swap to your system, drastically reduces OOM killer frequency.

I'm sure this would help, but I have 64GB of RAM. Linux should be able to figure out how to save some of that massive amount of memory so that it can save itself.

When the system runs out of memory the OOM killer is actually invoked right away. The problem is that systems with modern fast storage can run for hours with little to no memory left without really going OOM. If you're interested in this, I've explained how this happens in this thread: https://news.ycombinator.com/item?id=28771003

I understand this, but I want to point out while it's locked up thrashing you can't use sysrq to invoke the OOM so you have to wait anyways.

By too late, I meant that manually invoking (sysrq) the OOM before it starts thrashing prevents it from totally locking up.

> I understand this, but I want to point out while it's locked up thrashing you can't use sysrq to invoke the OOM so you have to wait anyways.

Invoking the OOM killer with sysrq has always worked for me, strange.

Oh that’s a known problem. There are many kernel patches floating around that fix it by triggering the OOM killer when the system is thrashing. Here’s one based on ChromeOS’s solution: https://github.com/hakavlad/le9-patch

I’ve never had this specific problem back when I was daily driving desktop Linux, but I did run into 1000 other ones that needed bandaid solutions just like this. It’s death of a thousand cuts: https://news.ycombinator.com/item?id=28490753

I see that nothing’s changed in the last couple of years.

Just curious, do you believe there's an OS out there right now without this thousand cuts problem?

Oh yes, 4 of them. Windows, macos, android, and ios only have a handful of cuts in my experience. I'm not saying that's entirely linux's fault or anything. It's just that desktop linux has a market share of around 1% (depending on your source) and even that's fragmented across several distros. Hardly anyone tests their software or hardware on linux, let alone the distro you happen to use.

Some of the problems I listed used to be an issue on other OSs. For example Android used to have ridiculous audio latency on the order of 400ms, but a few years ago Google got their shit together and fixed that: https://source.android.com/devices/audio/latency/measurement...

The same can't be said for desktop linux. I don't think any of the distros even have a device farm for end-to-end latency measurements. The other 4 OSs have extensive testing and the devs care about user metrics.

I remember trying to kill everything I could to optimize my gaming on my PC when I played a lot of games.

I soon discovered that outside one or two “bad” programs, I was killing a lot of little programs for no noticeable benefit.

The linux OOM killer should take a lesson. It seems to like killing sshd, when all it really needs to do is grep the process list for "java" (or more often these days, "python")

Or even worse is when it kills your X server taking everything else down with it.

As a linux admin java launch options drive me absolutely crazy. In the process list a lot of normal, easily understood things, and then a 400 char list of -XX -Xms -Xmx overly verbose randomness. Don't get me started on how it's also always the java apps that have mem leaks and eat way more than intended mem. I don't have time to do your heap dumps for you devs!

> But the Start menu is a UWP program,

> 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.

So... Can you minimize the start menu? Will the system automatically terminate it? And how many holes did they have to poke in the sandbox to make that even work?

I think the Start Menu is in fact, mostly always minimized. The taskbar is not the same thing as the Start Menu. And the taskbar often displays correctly even when the Start Menu is broken and won't open.

if the start menu was just a list of programs you may want to launch, it could probably be started and killed as needed...

> 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?)

So, does this guy not realize that 'home gaming' makes them a hell of a lot more money than 'home productivity'?

tldr; the author considers "none" to be "impossible options." save your time.

> But the Start menu is a UWP program, so it is supposed to be launched a special way, with specific command line arguments

Specific arguments aren’t the same as no arguments. The distinction is important here.

From a Windows perspective, launching the start menu without explorer.exe should be impossible (at least for non-wizards), which is why they thought this was impossible. It doesn’t make sense for a user to kill the start menu to relieve memory pressure, unless of course it’s a pig. Which it is in Windows 10+ :(

It’s been a while since I games or windowsed, but don’t you want to kill the start menu anyway so you don’t accidentally hit the windows key and interrupt your game?

I remember that would be kind of an issue like 15-20 years ago -- not sure why, but switching out from a 3D game to the desktop would take forever (I mean I can imagine a bunch of reasons -- ram was expensive, hard drives were slow, swap was more of a thing, processors were single core, graphics cards had terrible drivers, etc etc -- the reasons are too numerous for me to nail it down).

Nowadays on any reasonably performant system, it would just possibly pop the start menu up for a second, and then you'd click on the game -- everything should be fine outside of super competitive situations. Hitting start was always a rare event anyway, but now it's been degraded from a rare catastrophe to a rare minuscule inconvenience.

It used to be a lot more common for games to run a separately set screen resolution than the OS, so transitioning in and out of a game might change your screen size. Windowed mode and "Windowed (Fullscreen) were usually to not do this, and generally were easier if you task switched while gaming (especially for MMOs). I think nowadays it's much less common for games to run at a different resolution than you've already set your display to.

> I think nowadays it's much less common for games to run at a different resolution than you've already set your display to.

I would guess the opposite? 4k monitors are fairly cheap while GFX cards which can run games at that resolution with a decent FPS are expensive. Maybe hardware has gotten cheaper or way more performant in the last years though.

I think more than likely the majority of people have either a 1080p or 4K display, and if they do, they are using that resolution both when on their desktop and when in a game.

But if you remember back in the VGA days, it wasn't uncommon to have a game set an 800x600 resolution even though you had a 1024x768 display, so switching in and out of the game came with some delay to manage that.

A lot of games now have an option to render the UI at native resolution but render the actual game at a lower resolution for performance reasons.

Disabling that doesn't require killing the start menu.

> It doesn’t make sense for a user to...

Famous last words of many a unemployed junior developer...just sayin'.

This seems like partially a failure with how Microsoft launches UWP apps. I honestly can't stand Microsoft's app store. It has to be the worst.

Reply on news.ycombinator.com