starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Windows 10 1809 - breaking change in cmd.exe "start" command behavior. #399

New Issue
Closed
opened 2026-01-30 21:50:53 +00:00 by claunia · 15 comments
claunia commented 2026-01-30 21:50:53 +00:00
Owner
Copy Link

Originally created by @aggieNick02 on GitHub (Oct 5, 2018).

Originally assigned to: @miniksa on GitHub.

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.

Originally created by @aggieNick02 on GitHub (Oct 5, 2018). Originally assigned to: @miniksa on GitHub. 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.
claunia added the Resolution-Fix-AvailableWork-ItemProduct-Cmd.exe labels 2026-01-30 21:50:54 +00:00
claunia commented 2026-01-30 21:50:55 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 8, 2018):

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

@zadjii-msft commented on GitHub (Oct 8, 2018): @miniksa Do you think this might be related to the other `start` issue we were seeing last week?
claunia commented 2026-01-30 21:50:55 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Oct 8, 2018):

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

@miniksa commented on GitHub (Oct 8, 2018): @DHowett-MSFT, @zadjii-msft, let's discuss this at triage.
claunia commented 2026-01-30 21:50:55 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Oct 9, 2018):

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

@miniksa commented on GitHub (Oct 9, 2018): OK we had a pow-wow and I'm restoring the old behavior as a part of MSFT: 19238630.
claunia commented 2026-01-30 21:50:55 +00:00
Author
Owner
Copy Link

@aggieNick02 commented on GitHub (Oct 9, 2018):

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.

@aggieNick02 commented on GitHub (Oct 9, 2018): 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.
claunia commented 2026-01-30 21:50:55 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Oct 9, 2018):

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.

@miniksa commented on GitHub (Oct 9, 2018): 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.
claunia commented 2026-01-30 21:50:56 +00:00
Author
Owner
Copy Link

@aggieNick02 commented on GitHub (Oct 9, 2018):

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/

@aggieNick02 commented on GitHub (Oct 9, 2018): 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/
claunia commented 2026-01-30 21:50:56 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Oct 9, 2018):

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

@miniksa commented on GitHub (Oct 9, 2018): @DHowett-MSFT and @bitcrazed could probably help figure that out.
claunia commented 2026-01-30 21:50:56 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jan 18, 2019):

This reached Insiders as of 18272+.

@miniksa commented on GitHub (Jan 18, 2019): This reached Insiders as of 18272+.
claunia commented 2026-01-30 21:50:57 +00:00
Author
Owner
Copy Link

@bitcrazed commented on GitHub (Mar 28, 2019):

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.

@bitcrazed commented on GitHub (Mar 28, 2019): 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.
claunia commented 2026-01-30 21:50:57 +00:00
Author
Owner
Copy Link

@Ssiws commented on GitHub (Mar 28, 2019):

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)

@Ssiws commented on GitHub (Mar 28, 2019): 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)
claunia commented 2026-01-30 21:50:57 +00:00
Author
Owner
Copy Link

@bitcrazed commented on GitHub (Mar 28, 2019):

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.

@bitcrazed commented on GitHub (Mar 28, 2019): 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.
claunia commented 2026-01-30 21:50:58 +00:00
Author
Owner
Copy Link

@Ssiws commented on GitHub (Mar 28, 2019):

Ok, thanks for answering and for the clarification !

@Ssiws commented on GitHub (Mar 28, 2019): Ok, thanks for answering and for the clarification !
claunia commented 2026-01-30 21:50:58 +00:00
Author
Owner
Copy Link

@chrishibler commented on GitHub (May 10, 2019):

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.

@chrishibler commented on GitHub (May 10, 2019): 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.
claunia commented 2026-01-30 21:50:58 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 10, 2019):

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

@DHowett-MSFT commented on GitHub (May 10, 2019): Good news! This bug has been selected for servicing. Timeline TBD.
claunia commented 2026-01-30 21:50:58 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jun 24, 2019):

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

@DHowett-MSFT commented on GitHub (Jun 24, 2019): Even better news! The fix for this bug was released with cumulative update [KB4501371](https://support.microsoft.com/en-us/help/4501371/windows-10-update-kb4501371)!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Product-Cmd.exe Resolution-Fix-Available Work-Item
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#399
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?