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

File Explorer Slow when Context Menu Enabled #15643

New Issue
Closed
opened 2026-01-31 04:44:14 +00:00 by claunia · 6 comments
claunia commented 2026-01-31 04:44:14 +00:00
Owner
Copy Link

Originally created by @mhunsber on GitHub (Oct 22, 2021).

Windows Terminal version (or Windows build number)

1.10.2714.0

Other Software

explorer 10.0.19041.1023
Microsoft Windows NT 10.0.19042.0

Steps to reproduce

  1. Install Windows Terminal
  2. Open File Explorer
  3. right-click a folder in file explorer or somewhere on the desktop to pull up the context menu
  4. alternatively, try to open some folders in file explorer

Expected Behavior

File Explorer should open the context menu quickly, opening folders should be fast.

Actual Behavior

The context menu takes at least a full second to load. Opening a folder takes a very long time. Task Manager shows the Windows Terminal process spike to at least 15% CPU while the folder is loading or the context menu is being loaded. This happens about every 30 seconds or so. If I try to right-click on other files/folders or open more folders within that 30 seconds, it happens quickly without a cpu spike.

I also noticed that expanding folders in the navigation pane happens quickly, and does not cause Windows Terminal to spike in CPU usage.

If I block the windows terminal shell extension as described in #7008 and restart file explorer, right-clicking to bring up the context menu is no longer slow, and folders load in file explorer quickly.

Originally created by @mhunsber on GitHub (Oct 22, 2021). ### Windows Terminal version (or Windows build number) 1.10.2714.0 ### Other Software explorer 10.0.19041.1023 Microsoft Windows NT 10.0.19042.0 ### Steps to reproduce 1. Install Windows Terminal 2. Open File Explorer 3. right-click a folder in file explorer or somewhere on the desktop to pull up the context menu 4. alternatively, try to open some folders in file explorer ### Expected Behavior File Explorer should open the context menu quickly, opening folders should be fast. ### Actual Behavior The context menu takes at least a full second to load. Opening a folder takes a very long time. Task Manager shows the Windows Terminal process spike to at least 15% CPU while the folder is loading or the context menu is being loaded. This happens about every 30 seconds or so. If I try to right-click on other files/folders or open more folders within that 30 seconds, it happens quickly without a cpu spike. I also noticed that expanding folders in the navigation pane happens quickly, and does not cause Windows Terminal to spike in CPU usage. If I block the windows terminal shell extension as described in [#7008](https://github.com/microsoft/terminal/issues/7008#issuecomment-662621638) and restart file explorer, right-clicking to bring up the context menu is no longer slow, and folders load in file explorer quickly.
claunia commented 2026-01-31 04:44:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 25, 2021):

Huh. I wonder if there's any way to trace why that is. I don't think we're invoking any logic just when the user navigates inside explorer. My only thought is that maybe it's taking a long time to load the title of the context menu entry? OpenTerminalHere::GetTitle is the code I'm thinking of. I'll reach out to the File Explorer team, see what's up.

@zadjii-msft commented on GitHub (Oct 25, 2021): Huh. I wonder if there's any way to trace why that is. I don't _think_ we're invoking any logic just when the user navigates inside explorer. My only thought is that maybe it's taking a long time to load the title of the context menu entry? `OpenTerminalHere::GetTitle` is the code I'm thinking of. I'll reach out to the File Explorer team, see what's up.
claunia commented 2026-01-31 04:44:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 25, 2021):

@mhunsber Heard back from the explorer team. They recommended:

A repro mode feedback hub trace that captures performance. And/or a time travel trace of explorer.exe.

whatever

Can you capture that, and send me the aka.ms link for the feedback item?

@zadjii-msft commented on GitHub (Oct 25, 2021): @mhunsber Heard back from the explorer team. They recommended: > A repro mode feedback hub trace that captures performance. And/or a time travel trace of explorer.exe. ![whatever](https://user-images.githubusercontent.com/18356694/138758308-6df7984e-627f-48b8-8b48-d4df3a7b094c.png) Can you capture that, and send me the aka.ms link for the feedback item?
claunia commented 2026-01-31 04:44:16 +00:00
Author
Owner
Copy Link

@mhunsber commented on GitHub (Oct 26, 2021):

Alright. I tried to get a recording of the issue, but both Feedback Hub and TTD were failing to start the recording. I believed it was my AV that was interfering and not allowing the debugger to attach to the process, so I tried disabling my AV. I had to upgrade the antivirus to allow disabling it, but after upgrading the AV I am not having any of the slow performance when using file explorer that I had before. So now I can record the process with TTD, but cannot reproduce the issue. I think the problem may have been my antivirus the whole time, and upgrading the sensor fixed the issue.

@mhunsber commented on GitHub (Oct 26, 2021): Alright. I tried to get a recording of the issue, but both Feedback Hub and TTD were failing to start the recording. I believed it was my AV that was interfering and not allowing the debugger to attach to the process, so I tried disabling my AV. I had to upgrade the antivirus to allow disabling it, but after upgrading the AV I am not having any of the slow performance when using file explorer that I had before. So now I can record the process with TTD, but cannot reproduce the issue. I think the problem may have been my antivirus the whole time, and upgrading the sensor fixed the issue.
claunia commented 2026-01-31 04:44:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 26, 2021):

I think the problem may have been my antivirus the whole time, and upgrading the sensor fixed the issue.

Oh, well, that's great to hear! Thanks for following up!

@zadjii-msft commented on GitHub (Oct 26, 2021): > I think the problem may have been my antivirus the whole time, and upgrading the sensor fixed the issue. Oh, well, that's great to hear! Thanks for following up!
claunia commented 2026-01-31 04:44:17 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 26, 2021):

@mhunsber Which AV software are you using? The File Explorer team is curious ☺️

@zadjii-msft commented on GitHub (Oct 26, 2021): @mhunsber Which AV software are you using? The File Explorer team is curious ☺️
claunia commented 2026-01-31 04:44:17 +00:00
Author
Owner
Copy Link

@mhunsber commented on GitHub (Oct 26, 2021):

@zadjii-msft Carbon Black Cloud Sensor (VMWare). I was on version 3.4.0.1052 when I had the issues. I updated to version 3.7.0.1411 this morning and haven't had the problem since.

@mhunsber commented on GitHub (Oct 26, 2021): @zadjii-msft Carbon Black Cloud Sensor (VMWare). I was on version 3.4.0.1052 when I had the issues. I updated to version 3.7.0.1411 this morning and haven't had the problem since.
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 Area-Performance Area-ShellExtension Needs-Attention Needs-Tag-Fix Needs-Triage Product-Terminal
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#15643
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?