maxmustermann/terminal
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
terminal/src/Terminal.wprp

68 lines
4.8 KiB
Plaintext
Raw Normal View History

Add a WPR profile containing all of Terminal's ETW providers (#9630)
2021-03-26 17:46:14 +01:00
<?xml version="1.0" encoding="utf-8"?>
<WindowsPerformanceRecorder Version="1.0" Author="Microsoft Corporation" Copyright="Microsoft Corporation" Company="Microsoft Corporation">
<Profiles>
<EventCollector Id="EventCollector_Terminal" Name="Terminal">
<BufferSize Value="64" />
<Buffers Value="4" />
</EventCollector>
<EventProvider Id="EventProvider_TerminalControl" Name="28c82e50-57af-5a86-c25b-e39cd990032b" />
<EventProvider Id="EventProvider_TerminalConnection" Name="e912fe7b-eeb6-52a5-c628-abe388e5f792" />
<EventProvider Id="EventProvider_TerminalSettingsModel" Name="be579944-4d33-5202-e5d6-a7a57f1935cb" />
<EventProvider Id="EventProvider_TerminalApp" Name="24a1622f-7da7-5c77-3303-d850bd1ab2ed" />
<EventProvider Id="EventProvider_TerminalWin32Host" Name="56c06166-2e2e-5f4d-7ff3-74f4b78c87d6" />
<EventProvider Id="EventProvider_TerminalRemoting" Name="d6f04aad-629f-539a-77c1-73f5c3e4aa7b" />
Set keyword flags on all tracelog events (#10098) Set keyword flags on all events so those sharing a provider with telemetry do not fire unless tracing is enabled ## PR Checklist * [x] Closes #10093 * [x] I work here * [x] Tests passed * [x] Documentation added in `til.h` about how keywords work and at the only other site of keywords we define in the Host project tracing files. ## Detailed Description of the Pull Request / Additional comments I initially thought that we would need to split providers here to accomplish this... but @DHowett helped me realize that might be a lot of additional metadata and bloat binary size. So with help from a friend from fundamentals, I realized that we could use Keywords to differentiate here. We can no longer define 0 keywords as that represents an any/all scenario. Every `TraceLoggingWrite` event now needs a keyword. When our events have a keyword, they're not included in any trace. Additionally, when we have an explicit keyword to check that is different from the ones used for the telemetry pipeline, we can ensure that we only do "hard work" to generate debug trace data when an "ALL" type listener like TraceView or Windows Performance Recorder with our profiles is listening to these providers for ALL keyworded events. ## Validation Steps Performed - [x] - Built with full release build config to confirm performance is worse than dev builds BECAUSE of the telemetry event collector camping our provider and triggering full trace event generation on shared providers. - [x] - Built with full release build config to enable statistics collection and validated trace event collection is excluded and trace event short-circuits work with this change. - [x] - Checked that TraceView still sees both telemetry and tracing events - [x] - Checked that WPR with our .wprp profile sees both telemetry and tracing events
2021-05-15 01:14:26 +02:00
<EventProvider Id="EventProvider_TerminalDirectX" Name="c93e739e-ae50-5a14-78e7-f171e947535d" />
[a11y] Ensure buffer is initialized before interacting with it (#11312) Adds a check before every UIA function call to ensure the terminal (specifically the buffer) is initialized before doing work. Both the `ScreenInfoUiaProvider` and the `UiaTextRange` are now covered. ## References Closes #11135 #10971 & #11042 ## Detailed Description of the Pull Request / Additional comments Originally, I tried applying this heuristic to all the `RuntimeClassInitialize` on `UiaTextRangeBase` with the philosophy of "a range pointing to an invalid buffer is invalid itself", but that caused a regression on [MSFT 33353327](https://microsoft.visualstudio.com/OS/_workitems/edit/33353327). `IUiaData` also has `GetTextBuffer()` return a `TextBuffer&`, which cannot be checked for nullness. Instead, I decided to add a function to `IUiaData` that checks if we have a valid state. Since this is shared with Conhost and Conhost doesn't have this issue, I simply make that function say that it's always in a valid state. ## Validation Steps Performed - [X] Narrator can detect newly created terminals - [X] (On Windows Server 2022) Windows Terminal does not hang on launch
2021-09-24 00:14:03 +02:00
<EventProvider Id="EventProvider_TerminalUIA" Name="e7ebce59-2161-572d-b263-2f16a6afb9e5"/>
Add even MORE logging for defterm (#11537) Considering the number of reports of "defterm isn't working (mysteriously)", I figured more logging current hurt. I also added a wprp profile for the defterm logging as well, which should capture conhost side things as well. From an elevated conhost: ``` wpr -start path\to\Terminal.wprp!Defterm.Verbose wpr -stop %USERPROFILE%\defterm-trace.etl ``` * [x] I work here * [x] relevant to: #10594, #11529, #11524.
2021-10-19 22:29:18 +02:00
<!-- Console providers here -->
<EventProvider Id="EventProvider-Microsoft.Windows.Console.Launcher" Name="770aa552-671a-5e97-579b-151709ec0dbd"/>
<EventProvider Id="EventProvider-Microsoft.Windows.Console.Host" Name="fe1ff234-1f09-50a8-d38d-c44fab43e818"/>
<EventProvider Id="EventProvider-Microsoft.Windows.Console.Server" Name="1A541C01-589A-496E-85A7-A9E02170166D"/>
<EventProvider Id="EventProvider-Microsoft.Windows.Console.VirtualTerminal.Parser" Name="c9ba2a84-d3ca-5e19-2bd6-776a0910cb9d"/>
<EventProvider Id="EventProvider-Microsoft.Windows.Console.Render.VtEngine" Name="c9ba2a95-d3ca-5e19-2bd6-776a0910cb9d"/>
<EventProvider Id="EventProvider-Microsoft.Windows.Console.UIA" Name="e7ebce59-2161-572d-b263-2f16a6afb9e5"/>
<!-- Profile for General Terminal logging -->
Add a WPR profile containing all of Terminal's ETW providers (#9630)
2021-03-26 17:46:14 +01:00
<Profile Id="Terminal.Verbose.File" Name="Terminal" Description="Terminal" LoggingMode="File" DetailLevel="Verbose">
<Collectors>
<EventCollectorId Value="EventCollector_Terminal">
<EventProviders>
<EventProviderId Value="EventProvider_TerminalControl" />
<EventProviderId Value="EventProvider_TerminalConnection" />
<EventProviderId Value="EventProvider_TerminalSettingsModel" />
<EventProviderId Value="EventProvider_TerminalApp" />
<EventProviderId Value="EventProvider_TerminalWin32Host" />
<EventProviderId Value="EventProvider_TerminalRemoting" />
Set keyword flags on all tracelog events (#10098) Set keyword flags on all events so those sharing a provider with telemetry do not fire unless tracing is enabled ## PR Checklist * [x] Closes #10093 * [x] I work here * [x] Tests passed * [x] Documentation added in `til.h` about how keywords work and at the only other site of keywords we define in the Host project tracing files. ## Detailed Description of the Pull Request / Additional comments I initially thought that we would need to split providers here to accomplish this... but @DHowett helped me realize that might be a lot of additional metadata and bloat binary size. So with help from a friend from fundamentals, I realized that we could use Keywords to differentiate here. We can no longer define 0 keywords as that represents an any/all scenario. Every `TraceLoggingWrite` event now needs a keyword. When our events have a keyword, they're not included in any trace. Additionally, when we have an explicit keyword to check that is different from the ones used for the telemetry pipeline, we can ensure that we only do "hard work" to generate debug trace data when an "ALL" type listener like TraceView or Windows Performance Recorder with our profiles is listening to these providers for ALL keyworded events. ## Validation Steps Performed - [x] - Built with full release build config to confirm performance is worse than dev builds BECAUSE of the telemetry event collector camping our provider and triggering full trace event generation on shared providers. - [x] - Built with full release build config to enable statistics collection and validated trace event collection is excluded and trace event short-circuits work with this change. - [x] - Checked that TraceView still sees both telemetry and tracing events - [x] - Checked that WPR with our .wprp profile sees both telemetry and tracing events
2021-05-15 01:14:26 +02:00
<EventProviderId Value="EventProvider_TerminalDirectX" />
[a11y] Ensure buffer is initialized before interacting with it (#11312) Adds a check before every UIA function call to ensure the terminal (specifically the buffer) is initialized before doing work. Both the `ScreenInfoUiaProvider` and the `UiaTextRange` are now covered. ## References Closes #11135 #10971 & #11042 ## Detailed Description of the Pull Request / Additional comments Originally, I tried applying this heuristic to all the `RuntimeClassInitialize` on `UiaTextRangeBase` with the philosophy of "a range pointing to an invalid buffer is invalid itself", but that caused a regression on [MSFT 33353327](https://microsoft.visualstudio.com/OS/_workitems/edit/33353327). `IUiaData` also has `GetTextBuffer()` return a `TextBuffer&`, which cannot be checked for nullness. Instead, I decided to add a function to `IUiaData` that checks if we have a valid state. Since this is shared with Conhost and Conhost doesn't have this issue, I simply make that function say that it's always in a valid state. ## Validation Steps Performed - [X] Narrator can detect newly created terminals - [X] (On Windows Server 2022) Windows Terminal does not hang on launch
2021-09-24 00:14:03 +02:00
<EventProviderId Value="EventProvider_TerminalUIA" />
Add a WPR profile containing all of Terminal's ETW providers (#9630)
2021-03-26 17:46:14 +01:00
</EventProviders>
</EventCollectorId>
</Collectors>
</Profile>
<Profile Id="Terminal.Light.File" Name="Terminal" Description="Terminal" Base="Terminal.Verbose.File" LoggingMode="File" DetailLevel="Light" />
<Profile Id="Terminal.Verbose.Memory" Name="Terminal" Description="Terminal" Base="Terminal.Verbose.File" LoggingMode="Memory" DetailLevel="Verbose" />
<Profile Id="Terminal.Light.Memory" Name="Terminal" Description="Terminal" Base="Terminal.Verbose.File" LoggingMode="Memory" DetailLevel="Light" />
Add even MORE logging for defterm (#11537) Considering the number of reports of "defterm isn't working (mysteriously)", I figured more logging current hurt. I also added a wprp profile for the defterm logging as well, which should capture conhost side things as well. From an elevated conhost: ``` wpr -start path\to\Terminal.wprp!Defterm.Verbose wpr -stop %USERPROFILE%\defterm-trace.etl ``` * [x] I work here * [x] relevant to: #10594, #11529, #11524.
2021-10-19 22:29:18 +02:00
<!-- Profile for DefTerm logging. Includes some conhost logging. -->
<Profile Id="DefTerm.Verbose.File" Name="DefTerm" Description="DefTerm" LoggingMode="File" DetailLevel="Verbose">
<Collectors>
<EventCollectorId Value="EventCollector_Terminal">
<EventProviders>
<EventProviderId Value="EventProvider_TerminalControl" />
<EventProviderId Value="EventProvider_TerminalConnection" />
<EventProviderId Value="EventProvider_TerminalSettingsModel" />
<EventProviderId Value="EventProvider_TerminalApp" />
<EventProviderId Value="EventProvider_TerminalWin32Host" />
<EventProviderId Value="EventProvider_TerminalRemoting" />
<EventProviderId Value="EventProvider-Microsoft.Windows.Console.Launcher" />
<EventProviderId Value="EventProvider-Microsoft.Windows.Console.Host" />
<EventProviderId Value="EventProvider-Microsoft.Windows.Console.Server" />
</EventProviders>
</EventCollectorId>
</Collectors>
</Profile>
<Profile Id="DefTerm.Light.File" Name="DefTerm" Description="DefTerm" Base="DefTerm.Verbose.File" LoggingMode="File" DetailLevel="Light" />
<Profile Id="DefTerm.Verbose.Memory" Name="DefTerm" Description="DefTerm" Base="DefTerm.Verbose.File" LoggingMode="Memory" DetailLevel="Verbose" />
<Profile Id="DefTerm.Light.Memory" Name="DefTerm" Description="DefTerm" Base="DefTerm.Verbose.File" LoggingMode="Memory" DetailLevel="Light" />
Add a WPR profile containing all of Terminal's ETW providers (#9630)
2021-03-26 17:46:14 +01:00
</Profiles>
Add even MORE logging for defterm (#11537) Considering the number of reports of "defterm isn't working (mysteriously)", I figured more logging current hurt. I also added a wprp profile for the defterm logging as well, which should capture conhost side things as well. From an elevated conhost: ``` wpr -start path\to\Terminal.wprp!Defterm.Verbose wpr -stop %USERPROFILE%\defterm-trace.etl ``` * [x] I work here * [x] relevant to: #10594, #11529, #11524.
2021-10-19 22:29:18 +02:00
</WindowsPerformanceRecorder>
Reference in a new issue Copy permalink