Counters confirm sustained high CPU in a .NET service. How would you use `dotnet-trace` to find the responsible code path?

I choose providers from the hypothesis. A sampled CPU profile is appropriate for compute-heavy code; runtime events can add GC, contention, exception, and ThreadPool context; application EventSource or Activity data can connect the sample to a business operation. I avoid enabling every verbose provider because collection overhead and noise can hide the path. I include both the bad interval and enough normal work for comparison. Common findings include serialization, regex or parsing loops, repeated mapping, compression, logging format cost, lock contention, excessive allocation that drives GC, or a background job competing with requests.