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

Microsoft File Lister (list.exe) in the SDK crashes when run from cmd.exe #16893

New Issue
Closed
opened 2026-01-31 05:26:19 +00:00 by claunia · 19 comments
claunia commented 2026-01-31 05:26:19 +00:00
Owner
Copy Link

Originally created by @HarjitSi on GitHub (Feb 27, 2022).

Windows Terminal version

1.11.3471.0

Windows build number

10.0.22000.527

Other Software

Windows SDK 10.0.22000.194 <- installed with VS2022 Community Edition

List.exe from above SDK. On my machine, it is located at: C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\list.exe

image

Steps to reproduce

Install SDK.
win-r cmd

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\list.exe <SOME_TEXT_FILE>

Expected Behavior

The <SOME_TEXT_FILE> will open in the console application list.exe.

This worked on Win 10 and Win 8.

Actual Behavior

cmd.exe window will close and disappear. A minute later, the processor fan goes to full speed and there is a powershell.exe running and consuming a CPU core.

Originally created by @HarjitSi on GitHub (Feb 27, 2022). ### Windows Terminal version 1.11.3471.0 ### Windows build number 10.0.22000.527 ### Other Software Windows SDK 10.0.22000.194 <- installed with VS2022 Community Edition List.exe from above SDK. On my machine, it is located at: C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\list.exe ![image](https://user-images.githubusercontent.com/45951076/155901622-3a46856c-1d61-4725-a440-ced26a3fde4b.png) ### Steps to reproduce Install SDK. win-r cmd C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\list.exe <SOME_TEXT_FILE> ### Expected Behavior The <SOME_TEXT_FILE> will open in the console application list.exe. This worked on Win 10 and Win 8. ### Actual Behavior cmd.exe window will close and disappear. A minute later, the processor fan goes to full speed and there is a powershell.exe running and consuming a CPU core.
claunia added the Product-ConhostNeeds-TriageIssue-BugNeeds-Tag-Fix labels 2026-01-31 05:26:19 +00:00
claunia commented 2026-01-31 05:26:21 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 28, 2022):

This seems to be working fine for me on both the Terminal and conhost:

image
image

If conhost is crashing, then we might be able to get a dump out of it: /feedback

FWIW I was using the list.exe that came with WinDbgX, since I couldn't seem to find the Debuggers directory in the SDK, nor the checkbox to install it in the VS installer. It should be the same version..._

@zadjii-msft commented on GitHub (Feb 28, 2022): This seems to be working fine for me on both the Terminal and conhost: ![image](https://user-images.githubusercontent.com/18356694/155977542-25f9a4fb-6ee3-44ca-9504-15eabfc590ed.png) ![image](https://user-images.githubusercontent.com/18356694/155977578-67fdd850-3412-4aa3-853e-3373be895df5.png) If conhost is crashing, then we might be able to get a dump out of it: /feedback FWIW I was using the list.exe that came with WinDbgX, since I couldn't seem to find the Debuggers directory in the SDK, nor the checkbox to install it in the VS installer. It _should_ be the same version..._
claunia commented 2026-01-31 05:26:21 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Feb 28, 2022):

Hi there!

Can you please send us feedback with the Feedback Hub with this issue? Make sure to click the "Start recording" button, then reproduce the issue before submitting the feedback. Once it's submitted, paste the link here so we can more easily find your crash information on the back end?

Thanks!

image

image

image

@ghost commented on GitHub (Feb 28, 2022): Hi there!<br><br>Can you please send us feedback with the [Feedback Hub](https://support.microsoft.com/en-us/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332) with this issue? Make sure to click the "Start recording" button, then reproduce the issue before submitting the feedback. Once it's submitted, paste the link here so we can more easily find your crash information on the back end?<br><br>Thanks!<br><br>![image](https://user-images.githubusercontent.com/18356694/140811502-a068f78b-89d2-4587-925a-73e19652b830.png)<br><br>![image](https://user-images.githubusercontent.com/18356694/140811557-cdc22a0f-fa6a-4f6a-953e-73b51f5548a3.png)<br><br>![image](https://user-images.githubusercontent.com/18221333/62478649-6de55400-b760-11e9-806e-5aab7e085a9f.png)
claunia commented 2026-01-31 05:26:21 +00:00
Author
Owner
Copy Link

@malxau commented on GitHub (Feb 28, 2022):

Sorry, I hadn't understood the powershell process pegging a core before. Is there an entry for list.exe in ImageFileExecutionOptions? Running powershell in response to list, or in response to a crash, seems like it has to be a customization or policy of some sort - this isn't what a regular install would do. Is there any more information about the powershell process, like the command line that invoked it?

(Also, I'm a bit confused by the version number, since that's not a Win11 build number. I think what's happening is the most recently installed SDK overwrites the debugger files because the directory is not versioned correctly. In this particular case that doesn't seem problematic though, because list doesn't depend on any non-OS DLLs.)

@malxau commented on GitHub (Feb 28, 2022): Sorry, I hadn't understood the powershell process pegging a core before. Is there an entry for list.exe in ImageFileExecutionOptions? Running powershell in response to list, or in response to a crash, seems like it has to be a customization or policy of some sort - this isn't what a regular install would do. Is there any more information about the powershell process, like the command line that invoked it? (Also, I'm a bit confused by the version number, since that's not a Win11 build number. I think what's happening is the most recently installed SDK overwrites the debugger files because the directory is not versioned correctly. In this particular case that doesn't seem problematic though, because list doesn't depend on any non-OS DLLs.)
claunia commented 2026-01-31 05:26:22 +00:00
Author
Owner
Copy Link

@HarjitSi commented on GitHub (Feb 28, 2022):

Thanks for trying to repro.

Please do win-r and then cmd.exe and in the cmd.exe run list.exe and you must give it an existing file to open. This sequence worked on Windows 10 and 8.

It does not fall within Windows terminal.

On another Microsoftee list I had asked for help with this and they had suggested filling a bug report here because apparently this team owns conhost and Windows terminal.

Apparently, the version number for list.exe wasn't changed in the SDK I previously mentioned.

@HarjitSi commented on GitHub (Feb 28, 2022): Thanks for trying to repro. Please do win-r and then cmd.exe and in the cmd.exe run list.exe and you must give it an existing file to open. This sequence worked on Windows 10 and 8. It does not fall within Windows terminal. On another Microsoftee list I had asked for help with this and they had suggested filling a bug report here because apparently this team owns conhost and Windows terminal. Apparently, the version number for list.exe wasn't changed in the SDK I previously mentioned.
claunia commented 2026-01-31 05:26:22 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 28, 2022):

Like I showed in the screenshots above, this doesn't repro for me. Please try capturing the scenario with the Feedback Hub, so it can try and capture the stack of the crash.

@zadjii-msft commented on GitHub (Feb 28, 2022): Like I showed [in the screenshots above](https://github.com/microsoft/terminal/issues/12593#issuecomment-1054173355), this doesn't repro for me. Please try capturing the scenario with the Feedback Hub, so it can try and capture the stack of the crash.
claunia commented 2026-01-31 05:26:23 +00:00
Author
Owner
Copy Link

@malxau commented on GitHub (Feb 28, 2022):

On another Microsoftee list I had asked for help with this and they had suggested filling a bug report here because apparently this team owns conhost and Windows terminal. Apparently, the version number for list.exe wasn't changed in the SDK I previously mentioned.

I'm the one who suggested that. In my install of the Windows 11 SDK the version of list is 10.0.22000.194, which is the Windows 11 build number. It would be very unexpected if the Windows 11 SDK bundled the Server 2019 version of these tools.

@malxau commented on GitHub (Feb 28, 2022): > On another Microsoftee list I had asked for help with this and they had suggested filling a bug report here because apparently this team owns conhost and Windows terminal. Apparently, the version number for list.exe wasn't changed in the SDK I previously mentioned. I'm the one who suggested that. In my install of the Windows 11 SDK the version of list is 10.0.22000.194, which is the Windows 11 build number. It would be very unexpected if the Windows 11 SDK bundled the Server 2019 version of these tools.
claunia commented 2026-01-31 05:26:23 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Mar 4, 2022):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@ghost commented on GitHub (Mar 4, 2022): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**.
claunia commented 2026-01-31 05:26:24 +00:00
Author
Owner
Copy Link

@HarjitSi commented on GitHub (Mar 5, 2022):

I submitted a problem report using Feedback hub. Just in case, here are some screen shots.

image

image

image

Thanks for working this.

@HarjitSi commented on GitHub (Mar 5, 2022): I submitted a problem report using Feedback hub. Just in case, here are some screen shots. ![image](https://user-images.githubusercontent.com/45951076/156896075-edf78708-8284-490c-931a-70be8e31d4d5.png) ![image](https://user-images.githubusercontent.com/45951076/156896166-2a31643b-838c-4b6c-80a5-a83c808ea912.png) ![image](https://user-images.githubusercontent.com/45951076/156896126-c4d8a22f-0401-49ac-8a41-7e94c57481af.png) Thanks for working this.
claunia commented 2026-01-31 05:26:24 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 7, 2022):

@HarjitSi can you actually share the link from that feedback hub item? Searching the backend on our side is actually notoriously tricky 😕

@zadjii-msft commented on GitHub (Mar 7, 2022): @HarjitSi can you actually share the link from that feedback hub item? Searching the backend on our side is actually notoriously tricky 😕
claunia commented 2026-01-31 05:26:25 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Mar 11, 2022):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@ghost commented on GitHub (Mar 11, 2022): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**.
claunia commented 2026-01-31 05:26:25 +00:00
Author
Owner
Copy Link

@HarjitSi commented on GitHub (Mar 14, 2022):

Not sure why Feedback hub is not working.

So, I did Win-r cmd

In Resource manager, I saw a cmd.exe and a conhost.exe.

I then ran WinDbg and did attach to a process (F6) and used the conhost.exe PID.

I noticed that the cmd.exe was frozen since the attach broke into the process. I went ahead and did a 'g' in WinDbg.

Then in the cmd window ran the command: list c:\bat\dirlist.txt

and it broke into WinDbg. The WinDbg session is in file: ListCrash.txt
ListCrash.TXT

I then did a ".dump /mfh /u" and have the crash dump. Not sure if I should upload it here. It is 38MB in size.

As previously mentioned that after some time, I see an entry in Resource Manager that takes a full core. So, I connected WinDbg to that and the session is also attached: ListExe.txt
ListExe.txt

I have the crash dump for this also and it is 11MB in size. Again not sure if I should upload it here.

If it helps, I can try different debug commands or we can do a call and do a debug session or?

@HarjitSi commented on GitHub (Mar 14, 2022): Not sure why Feedback hub is not working. So, I did Win-r cmd In Resource manager, I saw a cmd.exe and a conhost.exe. I then ran WinDbg and did attach to a process (F6) and used the conhost.exe PID. I noticed that the cmd.exe was frozen since the attach broke into the process. I went ahead and did a 'g' in WinDbg. Then in the cmd window ran the command: list c:\bat\dirlist.txt and it broke into WinDbg. The WinDbg session is in file: ListCrash.txt [ListCrash.TXT](https://github.com/microsoft/terminal/files/8241189/ListCrash.TXT) I then did a ".dump /mfh /u" and have the crash dump. Not sure if I should upload it here. It is 38MB in size. As previously mentioned that after some time, I see an entry in Resource Manager that takes a full core. So, I connected WinDbg to that and the session is also attached: ListExe.txt [ListExe.txt](https://github.com/microsoft/terminal/files/8241198/ListExe.txt) I have the crash dump for this also and it is 11MB in size. Again not sure if I should upload it here. If it helps, I can try different debug commands or we can do a call and do a debug session or?
claunia commented 2026-01-31 05:26:26 +00:00
Author
Owner
Copy Link

@malxau commented on GitHub (Mar 14, 2022):

For the conhost crash, can you get the stack trace on the thread that crashed? In the output here it looks like thread 0 crashed but the stack is from thread 3, which doesn't show the interesting state.

Also, does this have the "legacy console" option selected? I'm a bit surprised to see conhostv1.dll in the loaded modules.

@malxau commented on GitHub (Mar 14, 2022): For the conhost crash, can you get the stack trace on the thread that crashed? In the output here it looks like thread 0 crashed but the stack is from thread 3, which doesn't show the interesting state. Also, does this have the "legacy console" option selected? I'm a bit surprised to see conhostv1.dll in the loaded modules.
claunia commented 2026-01-31 05:26:26 +00:00
Author
Owner
Copy Link

@HarjitSi commented on GitHub (Mar 14, 2022):

Please find attached the thread 0 stack before I did the shenanigans below.
ListThread0Stack.TXT

I checked properties and "Use legacy" is checked. This is my baseline configuration. To be honest, I do not know why "Use legacy" is checked.

I re-ran cmd.exe and cleared the "Use legacy" checkbox. Exited cmd.exe. Reran cmd.exe and this time it opened in a Windows Terminal tab and not the standalone window type I showed in an earlier message.

I used Windows terminal's settings to change the Default terminal application to Windows Console Host. Ran cmd.exe and it opened in the window type shown in an earlier message and list.exe worked fine. I checked the state of "Use legacy" and it was cleared.

I then checked "Use legacy" and exited and reran cmd.exe and now list.exe crashes.

Summary List.exe fails with cmd.exe with Use Legacy checked. Good sleuthing - @malxau!

image

@HarjitSi commented on GitHub (Mar 14, 2022): Please find attached the thread 0 stack before I did the shenanigans below. [ListThread0Stack.TXT](https://github.com/microsoft/terminal/files/8241560/ListThread0Stack.TXT) I checked properties and "Use legacy" is checked. This is my baseline configuration. To be honest, I do not know why "Use legacy" is checked. I re-ran cmd.exe and **cleared** the "Use legacy" checkbox. Exited cmd.exe. Reran cmd.exe and this time it opened in a Windows Terminal tab and not the standalone window type I showed in an earlier message. I used Windows terminal's settings to change the Default terminal application to Windows Console Host. Ran cmd.exe and it opened in the window type shown in an earlier message and list.exe worked fine. I checked the state of "Use legacy" and it was **cleared**. I then checked "Use legacy" and exited and reran cmd.exe and now list.exe crashes. **Summary** List.exe fails with cmd.exe with Use Legacy checked. Good sleuthing - @malxau! ![image](https://user-images.githubusercontent.com/45951076/158102072-5eaf07a0-4c2d-4fab-bb8b-f654e642d4cc.png)
claunia commented 2026-01-31 05:26:27 +00:00
Author
Owner
Copy Link

@malxau commented on GitHub (Mar 14, 2022):

Okay, this is why nobody else could repro it, even though it's very serious. Using the legacy console makes the crash happen immediately.

From poking around, Peb->OemCodePageData is NULL which means ConhostV1!GlyphCP is never initialized. This is used by OEMCP (the default) when converting to Unicode. List crashes just by calling WriteConsoleOutputCharacterA - not even with extended characters, just characters that require ASCII-to-Unicode conversion. Messing around with this shows it crashes in many other ways too.

Edit: I repro'd this on Server 2022 as well as Windows 11, including without list.

@malxau commented on GitHub (Mar 14, 2022): Okay, this is why nobody else could repro it, even though it's very serious. Using the legacy console makes the crash happen immediately. From poking around, Peb->OemCodePageData is NULL which means ConhostV1!GlyphCP is never initialized. This is used by OEMCP (the default) when converting to Unicode. List crashes just by calling `WriteConsoleOutputCharacterA` - not even with extended characters, just characters that require ASCII-to-Unicode conversion. Messing around with this shows it crashes in many other ways too. Edit: I repro'd this on Server 2022 as well as Windows 11, including without list.
claunia commented 2026-01-31 05:26:28 +00:00
Author
Owner
Copy Link

@HarjitSi commented on GitHub (Mar 14, 2022):

Great! Please let me know if there is anything else I can do to help.

I reread the thread and I now better understand the confusion around version numbers mentioned earlier.

You are right that the VS 2022 installer no longer asks about installing the debuggers when installing the SDK. I think this is a bug and the VS installer team needs to know...

I'm reasonably sure that the debuggers were installed previously. And I mistakenly assumed that the Win 11 SDK install had updated them.

@HarjitSi commented on GitHub (Mar 14, 2022): Great! Please let me know if there is anything else I can do to help. I reread the thread and I now better understand the confusion around version numbers mentioned earlier. You are right that the VS 2022 installer no longer asks about installing the debuggers when installing the SDK. I think this is a bug and the VS installer team needs to know... I'm reasonably sure that the debuggers were installed previously. And I mistakenly assumed that the Win 11 SDK install had updated them.
claunia commented 2026-01-31 05:26:28 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 14, 2022):

I'm tagging this one up for discussion - since this only repros with Conhostv1, and likely always did, I'm tempted to close this out, since that's not actively maintained.

@zadjii-msft commented on GitHub (Mar 14, 2022): I'm tagging this one up for discussion - since this only repros with Conhostv1, and likely _always_ did, I'm tempted to close this out, since that's not actively maintained.
claunia commented 2026-01-31 05:26:29 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 14, 2022):

This is actually MSFT-26378124, which I've had a fix stashed for for a while. Target got rid of their implementation of process-local OEM codepages. 😄

@DHowett commented on GitHub (Mar 14, 2022): This is actually MSFT-26378124, which I've had a fix stashed for for a while. Target got rid of their implementation of process-local OEM codepages. :smile:
claunia commented 2026-01-31 05:26:29 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 14, 2022):

@zadjii-msft: Discussion outcome: we have a fix in hand for conhostv1, so we might as well fix it.

@DHowett commented on GitHub (Mar 14, 2022): @zadjii-msft: Discussion outcome: we have a fix in hand for conhostv1, so we might as well fix it.
claunia commented 2026-01-31 05:26:30 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Aug 9, 2023):

The fix for this went out in version 22621. Closing as fixed!

@carlos-zamora commented on GitHub (Aug 9, 2023): The fix for this went out in version 22621. Closing as fixed!
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 Issue-Bug Needs-Tag-Fix Needs-Triage Product-Conhost
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#16893
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?