Terminal: Windows 10 1809 - breaking change in cmd.exe "start" command behavior.

[aggieNick02]

In 1809, the way the start command (from cmd.exe) behaves has changed. You can work around it by adding /max or /min after start.

Two concrete examples:

1) Running something off a network share from a command prompt like:
start z:\myapp.exe
will now throw up a security warning dialog, when it did not in 1803 and earlier.

2) A powershell script like this:
$script={& cmd.exe /c start notepad.exe}
$job = start-job -scriptblock $script
would give you a job with state Running in 1803, until you closed notepad. In 1809, the job state is Completed before notepad is closed.

Adding /max or /min after start restores old behavior for both of these! That is crazy...

Both of these behavior changes are going to break tools/code that rely on the old behaviors of no security prompt and the powershell job not being Complete until the started program exits.

You can see how dramatically start has changed if you run procmon and filter to only cmd.exe process events. In Win10 1803, open a command prompt and do
start notepad.exe
It results in <100 events. Run in 1809 and get >1000. Add /max and it drops back to <100.

[zadjii-msft]

@miniksa Do you think this might be related to the other start issue we were seeing last week?

[miniksa]

@DHowett-MSFT, @zadjii-msft, let's discuss this at triage.

[miniksa]

OK we had a pow-wow and I'm restoring the old behavior as a part of MSFT: 19238630.

[aggieNick02]

Are there any details you can share about what had changed and why? When can the end user expect to see the behavior change back? An 1809 update or a later windows version? Thanks in advance.

[miniksa]

We changed to use ShellExecuteEx down the default start route instead of CreateProcess.

This was to help enable the "Sets" feature. The shell had to be aware of process launches in order to "glom" the tabs correctly.

We had been working out differences in behavior with the shell team to get it so ShellExecuteEx would behave the same as CreateProcess for cmd.exe's purposes and made many fixes. But "Sets" is gone for 1809 and I don't have a timeline for when/if it will return and in what form.

As such, it looks like the lowest cost solution for now is to revert to CreateProcess rather than trying to drive improvements in ShellExecuteEx that really only served the 1809 Sets implementation.

The fix will go into Insiders first for the next version of Windows, but I'm crafting it in a small, targeted way so it could be serviced should it gain enough attention and meet management thresholds for bringing back to 1809.

[aggieNick02]

Thanks for all the details and the quick turnaround.

Is there a good way for end-users to communicate if this is important enough to bring back into 1809? I had a couple reddit threads discovering/exploring before I was directed here.

There were a decent number of folks there concerned about the breaks that would arise given the two reproductions. I can direct them to thumbs-up but only if you'd like. If not, here are the threads in case they are helpful.

https://www.reddit.com/r/PowerShell/comments/9lcrmk/breaking_change_with_powershell_jobs_and_the/
https://www.reddit.com/r/sysadmin/comments/9lndas/windows_10_1809_breaking_change_in_cmdexe_start/

[miniksa]

@DHowett-MSFT and @bitcrazed could probably help figure that out.

[miniksa]

This reached Insiders as of 18272+.

[bitcrazed]

Following up on @ASwisstone's tweet: https://twitter.com/ASwisstone/status/1110429221250363392

Did you manage to verify that the behavior has been returned to normal using Win10 insider builds 18272+?

If it has, you'll see this fix appear in the up-coming Win10 release.

[Ssiws]

Yes, it works in this build, however I wanted to know if it's possible to backport the fix to 1809 with Windows Update ? (re-testing our LOB applications with a new build involves more resources than deploying a cumulative update on 1809 that has had a lot of testing already done on our side)

[bitcrazed]

Sorry, no - we generally only backport critical (e.g. data-loss) fixes back-platform. This issue doesn't meet that bar.

We encourage you to adopt the next release once its available - other than this fix, we've not made many changes to Console that'll likely affect you.

Closing issue since there are no further steps to take at this time.

[Ssiws]

Ok, thanks for answering and for the clarification !

[chrishibler]

fwiw, I'm using start to run an exe from a nuget package as a pre-build event (with /MIN /d) and it no longer works. However using "/min" instead of "/MIN" _does_ work.

[DHowett-MSFT]

Good news! This bug has been selected for servicing. Timeline TBD.

[DHowett-MSFT]

Even better news! The fix for this bug was released with cumulative update KB4501371!