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

netsh hangs when run from PowerShell 7.1.3 in Windows Terminal, cannot repro with new tabs #13096

New Issue
Closed
opened 2026-01-31 03:33:47 +00:00 by claunia · 12 comments
claunia commented 2026-01-31 03:33:47 +00:00
Owner
Copy Link

Originally created by @sba923 on GitHub (Mar 19, 2021).

Environment

Windows build number: 10.0.18363.1377
Windows Terminal version (if applicable): 1.7.572.0 Preview

PowerShell 7.1.3

C:\WINDOWS\system32\netsh.exe, product version 10.0.18362.1

Steps to reproduce

Run C:\WINDOWS\system32\netsh.exe

Expected behavior

Input should be possible at the following prompt

netsh>

Actual behavior

No input is possible, the netsh.exe process needs to be terminated.

This behavior cannot be reproduced:

  1. in PowerShell 7.1.3 not running within Windows Terminal
  2. in other / new Windows Terminal tabs running PowerShell 7.1.3
  3. in Windows PowerShell 5.1 running within Windows Terminal
  4. on another machine running Windows 10 build 19042.867

So there is something special about this particular instance of PowerShell 7.1.3 running in that particular Windows Terminal tab.

I can keep that tab open as long as needed in order to diagnose the issue.

Originally created by @sba923 on GitHub (Mar 19, 2021). # Environment ```none Windows build number: 10.0.18363.1377 Windows Terminal version (if applicable): 1.7.572.0 Preview PowerShell 7.1.3 C:\WINDOWS\system32\netsh.exe, product version 10.0.18362.1 ``` # Steps to reproduce Run `C:\WINDOWS\system32\netsh.exe` # Expected behavior Input should be possible at the following prompt `netsh>` # Actual behavior No input is possible, the `netsh.exe` process needs to be terminated. This behavior cannot be reproduced: 1. in PowerShell 7.1.3 not running within Windows Terminal 2. in other / new Windows Terminal tabs running PowerShell 7.1.3 3. in Windows PowerShell 5.1 running within Windows Terminal 4. on another machine running Windows 10 build 19042.867 So there is something special about this particular instance of PowerShell 7.1.3 running in that particular Windows Terminal tab. I can keep that tab open as long as needed in order to diagnose the issue.
claunia added the Needs-TriageNeeds-Tag-FixResolution-No-Repro labels 2026-01-31 03:33:48 +00:00
claunia commented 2026-01-31 03:33:49 +00:00
Author
Owner
Copy Link

@sba923 commented on GitHub (Mar 19, 2021):

Trying to get a call stack on the "hung" netsh.exe process, but this is all I see:

image

@sba923 commented on GitHub (Mar 19, 2021): Trying to get a call stack on the "hung" `netsh.exe` process, but this is all I see: ![image](https://user-images.githubusercontent.com/12860484/111782194-0807fa80-88b9-11eb-9c2d-9422cfead113.png)
claunia commented 2026-01-31 03:33:49 +00:00
Author
Owner
Copy Link

@sba923 commented on GitHub (Mar 19, 2021):

I was forced to restart the machine, so the blocked tab is gone. Sorry.

I have a dump of the hung netsh.exe process, if that can help.

@sba923 commented on GitHub (Mar 19, 2021): I was forced to restart the machine, so the blocked tab is gone. Sorry. I have a dump of the hung `netsh.exe` process, if that can help.
claunia commented 2026-01-31 03:33:50 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 19, 2021):

I mean it might be helpful, but we're not really the owners of netsh.exe, so I'm not sure having me poke around in a dump of that executable is going to lead to anything particularly informative. Not really sure where their bugs live though...

@zadjii-msft commented on GitHub (Mar 19, 2021): I mean it might be helpful, but we're not really the owners of `netsh.exe`, so I'm not sure having me poke around in a dump of that executable is going to lead to anything particularly informative. Not really sure where their bugs live though...
claunia commented 2026-01-31 03:33:50 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 19, 2021):

Dump might help -- though I bet it just uses 'ulib' or whatever internal console reading library all those old tools use. I wonder what they have in common...

@DHowett commented on GitHub (Mar 19, 2021): Dump might help -- though I bet it just uses 'ulib' or whatever internal console reading library all those old tools use. I wonder what they have in common...
claunia commented 2026-01-31 03:33:50 +00:00
Author
Owner
Copy Link

@sba923 commented on GitHub (Mar 19, 2021):

How do you want to get the dump?

@sba923 commented on GitHub (Mar 19, 2021): How do you want to get the dump?
claunia commented 2026-01-31 03:33:50 +00:00
Author
Owner
Copy Link

@sba923 commented on GitHub (Mar 19, 2021):

I mean it might be helpful, but we're not really the owners of netsh.exe, so I'm not sure having me poke around in a dump of that executable is going to lead to anything particularly informative. Not really sure where their bugs live though...

I understand. But that's the second executable that hangs when run within Windows Terminal...

@sba923 commented on GitHub (Mar 19, 2021): > I mean it might be helpful, but we're not really the owners of `netsh.exe`, so I'm not sure having me poke around in a dump of that executable is going to lead to anything particularly informative. Not really sure where their bugs live though... I understand. But that's the second executable that hangs when run within Windows Terminal...
claunia commented 2026-01-31 03:33:51 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 19, 2021):

E-mail would be fine. Thanks!

@DHowett commented on GitHub (Mar 19, 2021): E-mail would be fine. Thanks!
claunia commented 2026-01-31 03:33:51 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 19, 2021):

That is- using the e-mail address on my GitHub profile!

@DHowett commented on GitHub (Mar 19, 2021): That is- using the e-mail address on my GitHub profile!
claunia commented 2026-01-31 03:33:51 +00:00
Author
Owner
Copy Link

@sba923 commented on GitHub (Mar 19, 2021):

Sent!

@sba923 commented on GitHub (Mar 19, 2021): Sent!
claunia commented 2026-01-31 03:33:51 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 19, 2021):

Yup. This netsh is just waiting in the CRT read function on stdin.

Next time this happens, can you grab a dump of the OpenConsole.exe servicing the tab that's not working? It'll shed more light on the situation.

(Please reopen/open anew if you do repro this again!)

@DHowett commented on GitHub (Mar 19, 2021): Yup. This netsh is just waiting in the CRT read function on stdin. Next time this happens, can you grab a dump of the OpenConsole.exe servicing the tab that's not working? It'll shed more light on the situation. (Please reopen/open anew if you do repro this again!)
claunia commented 2026-01-31 03:33:52 +00:00
Author
Owner
Copy Link

@sba923 commented on GitHub (Mar 19, 2021):

Yup. This netsh is just waiting in the CRT read function on stdin.

Next time this happens, can you grab a dump of the OpenConsole.exe servicing the tab that's not working? It'll shed more light on the situation.

(Please reopen/open anew if you do repro this again!)

Sure will do!

@sba923 commented on GitHub (Mar 19, 2021): > Yup. This netsh is just waiting in the CRT read function on stdin. > > Next time this happens, can you grab a dump of the OpenConsole.exe servicing the tab that's not working? It'll shed more light on the situation. > > (Please reopen/open anew if you do repro this again!) Sure will do!
claunia commented 2026-01-31 03:33:52 +00:00
Author
Owner
Copy Link

@eryksun commented on GitHub (Mar 19, 2021):

I don't know if it's the case for this particular hung process. But in general, with the addition of ConDrv in Windows 8.1, some operations are handled in the kernel I/O manager and device stack that used to fail immediately in user mode with ERROR_INVALID_HANDLE. Whether the operations are supported or not, the I/O manager attempts to acquire the file lock for synchronous I/O, which will block if the file is already acquired for another operation on another thread, possibly in another process. This is vulnerable to scenarios that behave like a deadlock, depending on the interaction of two or more threads. A lot of code is defensive against deadlocks and indefinite blocking when working with FILE_TYPE_PIPE, because of numerous warnings about pipes in the documentation, but not FILE_TYPE_CHAR such as console handles.

For example, say that the same file object for "\Device\ConDrv\Input" is inherited by multiple processes, and one thread has the file acquired for a blocking read in line-input mode. Another thread in another process might hang in SetFilePointerEx (i.e. query/set the NT FilePositionInformation) for a seek on the file from the beginning or current position. (In legacy standard I/O mode, Python's startup code is currently vulnerable to this.) Prior to ConDrv, calling SetFilePointerEx on a console handle would fail immediately with ERROR_INVALID_HANDLE. In Windows 8.1 and later, with the ConDrv device, once the file lock for synchronous I/O is acquired, it trivially succeeds since the I/O manager just updates the position information in the file object without even calling the driver.

I think that most I/O system calls on console files that were formerly caught in user mode and failed with ERROR_INVALID_HANDLE (check the old source tree in Windows 7) -- such as GetFileInformationByHandle (i.e. NtQueryVolumeInformationFile: FileFsVolumeInformation, NtQueryInformationFile : FileAllInformation) and GetFileTime (i.e. NtQueryInformationFile : FileBasicInformation) to name two more -- should be failed early in the I/O manager by checking whether the file device type is FILE_DEVICE_CONSOLE before attempting to acquire the synchronous file lock. It can fail with STATUS_INVALID_HANDLE to be compatible with the old implementation. Or use a more appropriate status such as STATUS_INVALID_INFO_CLASS (i.e. ERROR_INVALID_PARAMETER) or STATUS_INVALID_DEVICE_REQUEST (i.e. ERROR_INVALID_FUNCTION).

@eryksun commented on GitHub (Mar 19, 2021): I don't know if it's the case for this particular hung process. But in general, with the addition of ConDrv in Windows 8.1, some operations are handled in the kernel I/O manager and device stack that used to fail immediately in user mode with `ERROR_INVALID_HANDLE`. Whether the operations are supported or not, the I/O manager attempts to acquire the file lock for synchronous I/O, which will block if the file is already acquired for another operation on another thread, possibly in another process. This is vulnerable to scenarios that behave like a deadlock, depending on the interaction of two or more threads. A lot of code is defensive against deadlocks and indefinite blocking when working with `FILE_TYPE_PIPE`, because of numerous warnings about pipes in the documentation, but not `FILE_TYPE_CHAR` such as console handles. For example, say that the same file object for "\\Device\\ConDrv\\Input" is inherited by multiple processes, and one thread has the file acquired for a blocking read in line-input mode. Another thread in another process might hang in `SetFilePointerEx` (i.e. query/set the NT `FilePositionInformation`) for a `seek` on the file from the beginning or current position. (In legacy standard I/O mode, Python's startup code is currently vulnerable to this.) Prior to ConDrv, calling `SetFilePointerEx` on a console handle would fail immediately with `ERROR_INVALID_HANDLE`. In Windows 8.1 and later, with the ConDrv device, once the file lock for synchronous I/O is acquired, it trivially succeeds since the I/O manager just updates the position information in the file object without even calling the driver. I think that most I/O system calls on console files that were formerly caught in user mode and failed with `ERROR_INVALID_HANDLE` (check the old source tree in Windows 7) -- such as `GetFileInformationByHandle` (i.e. `NtQueryVolumeInformationFile`: `FileFsVolumeInformation`, `NtQueryInformationFile` : `FileAllInformation`) and `GetFileTime` (i.e. `NtQueryInformationFile` : `FileBasicInformation`) to name two more -- should be failed early in the I/O manager by checking whether the file device type is `FILE_DEVICE_CONSOLE` *before* attempting to acquire the synchronous file lock. It can fail with `STATUS_INVALID_HANDLE` to be compatible with the old implementation. Or use a more appropriate status such as `STATUS_INVALID_INFO_CLASS` (i.e. `ERROR_INVALID_PARAMETER`) or `STATUS_INVALID_DEVICE_REQUEST` (i.e. `ERROR_INVALID_FUNCTION`).
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 Needs-Tag-Fix Needs-Triage Resolution-No-Repro
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#13096
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?