Benjaming/use stack pids

[bgn64]

Fix: Missing CPU samples in ETW traces with unresolved ProcessIDs

Problem

Profile Explorer shows significantly fewer CPU samples than WPA for the same ETW trace. For a Photoshop process in a WPR trace, WPA shows ~57K samples while Profile Explorer shows ~8.5K.

Two related bugs cause this:

1. Thread-to-process misattribution in merged WPR traces: For traces with LogFileName == "[multiple files]", the first pass builds a ThreadToProcess mapping reflecting final thread ownership. The second
   pass reuses this mapping, causing samples from reused thread IDs to be silently attributed to the wrong process (e.g., Photoshop samples counted under PowerShell).
2. Unresolved ProcessID samples dropped: TraceEvent reports ProcessID = -1 for ~40% of PerfInfoSample events in WPR traces lacking ThreadDCStart rundown events. These correspond to threads that existed
   before the trace started, where ETW's post-merge PID resolution has no ThreadStart event to work from. Profile Explorer skips all such samples. However, StackWalkStack events for these same threads
   reliably carry valid ProcessIDs — the kernel resolves them at capture time for stack walking purposes.

Fix

Commit 1: Always reopen trace between passes

Ensures the second pass builds its ThreadToProcess mapping incrementally as events arrive, reflecting temporal thread ownership rather than final state. This fixes the misattribution and correctly surfaces
PID = -1 for samples that can't be resolved from thread lifecycle events alone.

Commit 2: Deferred PID resolution from StackWalk events

When PerfInfoSample has PID = -1, defers sample creation until the immediately-following StackWalk event provides the correct ProcessID. A per-thread cache handles subsequent samples on the same thread
without deferral. Applied to all relevant event handlers: PerfInfoSample, PerfInfoPMCSample, StackWalkStack, StackWalkStackKeyKernel, StackWalkStackKeyUser, and BuildProcessSummary.

Testing

Verified against FileSave_PNG.generalprofile.etl using Profile Explorer's actual ProcessEvents and BuildProcessSummary code paths:

• Before fix: 8,489 samples for PID 14464
• After fix: 56,892 samples — exact match with WPA

[Copilot]

Pull request overview

Fixes missing / misattributed CPU samples when loading merged WPR ETW traces by reopening the trace between passes and using StackWalk events to resolve ProcessID = -1 samples.

Changes:

• Reopen the ETW trace for the main processing pass to rebuild ThreadToProcess mapping temporally (avoids thread-ID reuse misattribution in merged traces).
• Defer PerfInfoSample sample creation when ProcessID = -1 and resolve it from immediately following StackWalk events (with a per-thread PID cache).
• Propagate the resolved PID through StackWalk handlers (StackWalkStack / StackWalkStackKeyKernel / StackWalkStackKeyUser) when creating contexts/stacks.

Comments suppressed due to low confidence (2)

src/ProfileExplorerCore/Profile/ETW/ETWEventProcessor.cs:650

• This handler can return early after calling RentTempContext/AddContext without calling profile.ReturnContext(contextId) (e.g., when the triggering timestamp doesn't match). If AddContext inserted the temp context into the context table, failing to ReturnContext leaves tempContext_ aliased to a stored context and subsequent RentTempContext calls can mutate already-stored contexts. Ensure ReturnContext is called on all exit paths (e.g., wrap the body after AddContext in try/finally).

      int sampleId = perThreadLastSampleMap.GetValueOrDefault(data.ThreadID);
      var triggeringEventTimestamp = TimeSpan.FromMilliseconds(data.EventTimeStampRelativeMSec);

      // Check if the last sample on the core did not trigger this stack collection
      if (sampleId == 0 || profile.Samples[sampleId - 1].Time != triggeringEventTimestamp) {
        // Check if the last sample from the context did not trigger this stack collection
        if (!perContextLastSampleMap.TryGetValue(contextId, out sampleId) ||
            profile.Samples[sampleId - 1].Time != triggeringEventTimestamp) {
          // We don't know what sample this stack belongs to so we won't collect it
          return;
        }

src/ProfileExplorerCore/Profile/ETW/ETWEventProcessor.cs:709

• This handler can return early after calling RentTempContext/AddContext without calling profile.ReturnContext(contextId) (e.g., when the triggering timestamp doesn't match). If AddContext inserted the temp context into the context table, failing to ReturnContext leaves tempContext_ aliased to a stored context and subsequent RentTempContext calls can mutate already-stored contexts. Ensure ReturnContext is called on all exit paths (e.g., wrap the body after AddContext in try/finally).

      int sampleId = perThreadLastSampleMap.GetValueOrDefault(data.ThreadID);
      var triggeringEventTimestamp = TimeSpan.FromMilliseconds(data.EventTimeStampRelativeMSec);

      // Check if the last sample on the core did not trigger this stack collection
      if (sampleId == 0 || profile.Samples[sampleId - 1].Time != triggeringEventTimestamp) {
        // Check if the last sample from the context did not trigger this stack collection
        if (!perContextLastSampleMap.TryGetValue(contextId, out sampleId) ||
            profile.Samples[sampleId - 1].Time != triggeringEventTimestamp) {
          // We don't know what sample this stack belongs to so we won't collect it
          return;
        }

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jhpohovey]

nit: seems unnecessary to make a copy of data.ProcessID here? since the new variable it looks like is used only one time, and then there are more calls to data.ProcessID farther below