WT is relatively slow at executing cmd scripts at Windows startup

[vadimkantorov]

Windows Terminal version

1.16.10262.0

Windows build number

10.0.22621.1413

Other Software

No response

Steps to reproduce

My Windows system somehow has some *.cmd logon scripts: Terminal/cmd windows get spun up and closed several times at Windows login.

I could not find those scripts in Sysinternals autoruns64.exe, but they certainly get executed. My system is in a good shape, so it's not some virus etc.

These scripts do not require user input and typically do not even print anything, but the time to open a WT window, render it and then close is relatively slow. So WT startup/teardown time is a whole different beast when the usecase are the logon scripts and the OS/disk is bombarded by tons of apps/services starting up in parallel.

Some questions:

1. Is it possible to somehow ask WT to log to file its launches / closings with times (and hopefully with the argv)?
2. WT should be much faster for these cycles. Maybe it could somehow lazily render the Window or do only a minimal render (since the teardown is imminent faster than it could complete the rendering)? cmd.exe used to be much faster for these cycles. Ideally, WT would not be rendered at all for these scenarios. Maybe some "quiet" calls of cmd.exe did not show any window before, and started to show WT window now?

Expected Behavior

No response

Actual Behavior

N/A

[carlos-zamora]

Hi @vadimkantorov. Thanks for the feedback.

2. WT should be much faster for these cycles. Maybe it could somehow lazily render the Window or do only a minimal render (since the teardown is imminent faster than it could complete the rendering)? cmd.exe used to be much faster for these cycles. Ideally, WT would not be rendered at all for these scenarios. Maybe some "quiet" calls of cmd.exe did not show any window before, and started to show WT window now?

Yes! We definitely need to improve our startup/teardown performance. We're tracking this over in #5907, so we're going to mark this as a /dup of #5907.

1. Is it possible to somehow ask WT to log to file its launches / closings with times (and hopefully with the argv)?

As of now, no. The console hosting process model precludes us from doing this. However, there is a windows system feature that you can enable to audit process execution. This section from our FAQs may help out: https://github.com/microsoft/terminal/wiki/What-is-causing-consoles-to-pop-up-on-me%3F

[microsoft-github-policy-service]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

[vadimkantorov]

Is it possible to have some heuristics that delay full UI rendering specifically when it's running in unattended mode? Rendering of the UI / full Terminal systems bootstrapping is useless in these cases as the whole thing needs to exit in 500ms. E.g. ideally it should run cmd.exe some_script.cmd as fast as the old cmd.exe wrt UI loading and teardown

[vadimkantorov]

I think that this specific usecase is not discussed in #5907

[zadjii-msft]

@zadjii-msft could Terminal somehow run headless / without UI or with minimal non fully-fledged UWP UI if a *.cmd (or other) script is being launched in an unattended way as part of Windows startup? usecase of slow Terminal UI flickering when Windows runs some startup scripts: #15001 - maybe these runtime scripts are being executed as cmd.exe .... which now spins up Terminal. maybe for these cases Terminal could support a headless mode?

(from #9996)

Maybe? But those scripts shouldn't be displaying consoles in the first place. Defterm handoff is pretty specific - if a script wanted a visible console window, it tries to do a defterm handoff (resulting in the Terminal UI). Any of the many ways to start a hidden / minimized / headless console application won't invoke a defterm handoff.

So, a defterm handoff starting the Terminal headless is kinda besides the point here. Those apps either wanted to have a visible console window, or didn't bother hiding themselves on startup.

Now, 1.18 does have an unrelated fix where it won't display the Terminal HWND at all till the UI is actually ready. So that should mitigate some "transparent terminal window frames that pop in and out of existence before the Terminal even appears".

[vadimkantorov]

hmm... and in my case, these scripts somehow don't appear in sysinternals autoruns. I wonder if Terminal/cmd.exe (or maybe Windows in general?) has any simple way of logging all process executions (along with args)? that way at least I can give you a concrete example

I agree that they shouldn't be displaying consoles, so probably some command line flags are missing to hide these windows. but if they show it anyway, i wonder if there's any way to speed up these UI's starting up / shutting down. Maybe Terminal launches first in headless mode, is it faster for all subsequent Terminals to start up / shut down?

[DHowett]

simple way of logging all process executions

Sorry to give you a drive-by, but you might be served well enough on this point by https://github.com/microsoft/terminal/wiki/What-is-causing-consoles-to-pop-up-on-me%3F 😄

[vadimkantorov]

btw gpedit.msc is not included in Windows 11 Home... So hacks needed to install it https://answers.microsoft.com/en-us/windows/forum/all/how-to-enable-the-gpeditmsc-on-windows-10-and-11/dbc76919-f2b5-4dec-a2b7-bcf545c34d00 - maybe worth including it in that wiki document

I used these two cmd commands in an elevated Command Prompt:

FOR %F IN ("%SystemRoot%\servicing\Packages\Microsoft-Windows-GroupPolicy-ClientTools-Package~*.mum") DO (DISM /Online /NoRestart /Add-Package:"%F")
FOR %F IN ("%SystemRoot%\servicing\Packages\Microsoft-Windows-GroupPolicy-ClientExtensions-Package~*.mum") DO (DISM /Online /NoRestart /Add-Package:"%F")

Then gpedit.msc opened

[vadimkantorov]

@DHowett btw how can I filter the Process Creation events in the Event Viewer? What should I select as Event Sources? Without selecting Event Sources, the Task Category filter drop down is disabled so I can't choose Process Creation to filter only the relevant events

[DHowett]

That is an excellent question! Unfortunately, I am not particularly good with Event Viewer and I don't know how to filter those events adequately. ☹️

[vadimkantorov]

I wonder if Terminal could have an option for logging to its own topic in Event Viewer logging, including its startup arguments