Warn users when circular buffer overflow causes missing type info in allocation views for selected processes

[Copilot]

When ETW circular buffer wraps, type definition events (BulkType/ClassIDDefinition) are lost, causing allocation traces to show "UNKNOWN" types. Users had no indication this was happening or how to fix it.

Changes

Added process-specific RuntimeStart event detection

• Check for Runtime/Start events from Microsoft-Windows-DotNETRuntime provider (not rundown)
• Checks specifically for selected process IDs by iterating through actual events
• Uses traceLog.Events.GetSource() and subscribes to RuntimeStart delegate
• Absence indicates selected processes were running before trace started or buffer wrapped
• Falls back to stats check when no specific processes are selected

Display warning after process selection

• Triggers for: GC Heap Alloc Ignore Free, GC Heap Net Mem, Gen 2 Object Deaths (standard and coarse sampling variants)
• Runs after user selects which processes to view
• Shows warning only when RuntimeStart is missing for the specific selected processes
• Provides actionable fixes: shorter duration or larger buffer (/BufferSize:1024)

New OnStackWindowLaunch extensibility hook

• Added virtual OnStackWindowLaunch(Window parentWindow, List<int> processIDs) method
• Called after process selection but before stack window is fully initialized
• Establishes pattern for future functionality that needs to run based on selected processes

Affected scenarios

• GCSampledObjectAllocation events (need BulkType)
• GCAllocationTick events (need type info)
• ETWClrProfiler ObjectAllocated events (need ClassIDDefinition)

// Warning shown when RuntimeStart missing for selected processes
WARNING: The 'GC Heap Alloc Ignore Free' view may be missing type information.

This can happen when the ETW circular buffer wraps and loses early events including type definitions.
Without these type definitions, many types will appear as "UNKNOWN" in the allocation view.

To fix this issue, perform one of the following:
  • Re-capture the trace with a shorter duration
  • Re-capture the trace with a larger circular buffer size (e.g., /BufferSize:1024)

• Fixes Fix bad experience if you collect Allocation Stacks and the circular buffer wraps #773

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Fix bad experience if you collect Allocation Stacks and the circular buffer wraps</issue_title>
<issue_description>The scenario is that you have a large allocation trace and it wraps in the circular buffer.

Today you lose the type events so you get many unknown types.

This happens both with the ClrProfiler collection as wellas the ETW based collection.

At least warn people about how to fix it.
</issue_description>

Comments on the Issue (you are @copilot in this section)

@brianrob This is relevant for both the view that uses `EtwClrProfiler` events and for the one that uses the `BulkType` and `GCSampledObjectAllocation` events. For `EtwClrProfiler`, you need the `ClassIDDefintion` events. For `GCSampledObjectAllocation` events, you need the `BulkType` events.

Both of these require that the process be started after tracing starts, so we should look for the RuntimeStart event in the Microsoft-Windows-DotNETRuntime provider (not the rundown provider) and if we can't find it, when the user opens the view, pop-up a note that the trace may have overflowed the circular buffer and be missing type information. This can be fixed by re-capturing the trace with a shorter duration or a larger circular buffer.</comment_new>

• Fixes Fix bad experience if you collect Allocation Stacks and the circular buffer wraps #773

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[brianrob]

@copilot please address these comments.

[brianrob]

Please remove this sentence.

[brianrob]

Please remove this last entry.

[brianrob]

Suggested change

	To fix this issue:
	To fix this issue, perform one of the following:

[Copilot]

@copilot please address these comments.

All three review comments addressed in commit e74a2dc:

• Removed the sentence about Runtime/Start event from line 8506
• Changed "To fix this issue:" to "To fix this issue, perform one of the following:" on line 8511
• Removed the last bullet point about starting the .NET process after tracing on line 8515

[brianrob]

@copilot, please address this comment.

[brianrob]

Suggested change

The .NET process was likely already running when tracing started.

[Copilot]

@copilot, please address this comment.

Removed the sentence from line 8506 in commit b66c972.

[brianrob]

@copilot, this actually won't work. The reason is that we actually need to be able to post the warning based on the processes that were selected to be viewed by the user. This happens on line 4709 of PerfViewData.cs. Can you modify the current implementation to run after the processes are selected and then pop-up the dialog box if the Runtime/Start event isn't present in the trace? Note, that you'll also need to modify the check for the runtime start event because you don't just care that one or more exists in the trace, you need to see if it matches the processes of interest, so you will need to look at the events themselves.

[Copilot]

@copilot, this actually won't work. The reason is that we actually need to be able to post the warning based on the processes that were selected to be viewed by the user. This happens on line 4709 o...

Refactored in commit 40633bd:

1. Created OnStackWindowLaunch() hook method - Called after process selection, establishes a pattern for future similar functionality
2. Moved check to after process selection - Now runs at line 4649 after processIDs are determined
3. Updated to check per-process RuntimeStart events - Iterates through actual events using traceLog.Events.GetSource() and subscribes to RuntimeStart to match selected process IDs
4. Removed old implementation - Removed the ConfigureStackWindow check and old methods that only looked at trace stats

The warning now only triggers when RuntimeStart events are missing for the specific processes the user selected to view.