Debugging scenarioMedium~8 min

Interview question

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

Diagnose high CPU with dotnet-trace

Collects a bounded EventPipe CPU trace and reads stack evidence without confusing hot methods, blocked time, native work, or sampling artifacts.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I reproduce or wait for the high-CPU window, confirm the exact process and instance, and collect a short dotnet-trace session with CPU sampling enabled. I keep the duration long enough to cover representative requests without producing an unbounded file. I open the resulting trace in a compatible analyzer such as Visual Studio, PerfView, or a supported stack viewer, then inspect the CPU call tree and hot paths. Inclusive cost shows expensive call chains, while exclusive cost highlights methods doing work directly. I separate application code from runtime work such as GC, JIT, or thread scheduling, and I compare the hot stack with request, job, or deployment context before changing code.

Full answer below

Practice focus

EventPipe, sampled CPU profiles, collection windows, providers, call trees, inclusive and exclusive cost, native boundaries, symbols, and regression proof.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A CPU percentage confirms pressure but does not identify the code consuming it. A useful trace captures representative work and turns sampled stacks into a path that can be reproduced and changed.
I reproduce or wait for the high-CPU window, confirm the exact process and instance, and collect a short dotnet-trace session with CPU sampling enabled. I keep the duration long enough to cover representative requests without producing an unbounded file. I open the resulting trace in a compatible analyzer such as Visual Studio, PerfView, or a supported stack viewer, then inspect the CPU call tree and hot paths. Inclusive cost shows expensive call chains, while exclusive cost highlights methods doing work directly. I separate application code from runtime work such as GC, JIT, or thread scheduling, and I compare the hot stack with request, job, or deployment context before changing code.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I account for what the trace cannot prove. Sampling can miss very short work, safe-point behavior can bias managed stacks, missing symbols obscure names, and managed-only stacks may hide native or kernel cost. On supported Linux environments a kernel-aware profiler or newer combined collection path may be needed for native CPU and system calls; on Windows, ETW-capable tooling may provide deeper process and kernel context. I confirm that CPU throttling, multiple cores, process selection, and container limits match the interpretation. Mitigation may disable one feature, reduce concurrency, or move a job before the permanent fix. I then replay the same load and compare CPU per unit of work, throughput, p95 and p99 latency, allocation, and error rate. A shorter hot stack is not enough if total user performance or capacity did not improve.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Collecting the trace outside the high-CPU interval.
Enabling every provider and producing a huge, noisy artifact.
Optimizing the hottest framework frame without following the application call path.
Reading sampled percentages as exact timing for every method invocation.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The trace has no symbols, version, workload, or instance context.
Native or kernel time is ignored even though managed stacks do not explain the CPU.
The fix reduces one method's samples but worsens allocation or tail latency.
A production trace runs indefinitely or with unreviewed high-volume providers.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What is the difference between inclusive and exclusive CPU cost?
When would EventPipe evidence be insufficient?
How would you prove the optimization improved capacity?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

2 linked

Next interviewer turn

Continue the conversation with a linked follow-up drill.

Prove ThreadPool Starvation

Prerequisite

Review this first if the current drill feels shaky.

Triage with dotnet-counters

Opening drill

Debugging scenarioMedium~8 min

Interview question

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

Diagnose high CPU with dotnet-trace

Collects a bounded EventPipe CPU trace and reads stack evidence without confusing hot methods, blocked time, native work, or sampling artifacts.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

EventPipe, sampled CPU profiles, collection windows, providers, call trees, inclusive and exclusive cost, native boundaries, symbols, and regression proof.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A CPU percentage confirms pressure but does not identify the code consuming it. A useful trace captures representative work and turns sampled stacks into a path that can be reproduced and changed.
I reproduce or wait for the high-CPU window, confirm the exact process and instance, and collect a short dotnet-trace session with CPU sampling enabled. I keep the duration long enough to cover representative requests without producing an unbounded file. I open the resulting trace in a compatible analyzer such as Visual Studio, PerfView, or a supported stack viewer, then inspect the CPU call tree and hot paths. Inclusive cost shows expensive call chains, while exclusive cost highlights methods doing work directly. I separate application code from runtime work such as GC, JIT, or thread scheduling, and I compare the hot stack with request, job, or deployment context before changing code.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I account for what the trace cannot prove. Sampling can miss very short work, safe-point behavior can bias managed stacks, missing symbols obscure names, and managed-only stacks may hide native or kernel cost. On supported Linux environments a kernel-aware profiler or newer combined collection path may be needed for native CPU and system calls; on Windows, ETW-capable tooling may provide deeper process and kernel context. I confirm that CPU throttling, multiple cores, process selection, and container limits match the interpretation. Mitigation may disable one feature, reduce concurrency, or move a job before the permanent fix. I then replay the same load and compare CPU per unit of work, throughput, p95 and p99 latency, allocation, and error rate. A shorter hot stack is not enough if total user performance or capacity did not improve.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Collecting the trace outside the high-CPU interval.
Enabling every provider and producing a huge, noisy artifact.
Optimizing the hottest framework frame without following the application call path.
Reading sampled percentages as exact timing for every method invocation.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The trace has no symbols, version, workload, or instance context.
Native or kernel time is ignored even though managed stacks do not explain the CPU.
The fix reduces one method's samples but worsens allocation or tail latency.
A production trace runs indefinitely or with unreviewed high-volume providers.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What is the difference between inclusive and exclusive CPU cost?
When would EventPipe evidence be insufficient?
How would you prove the optimization improved capacity?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

2 linked

Next interviewer turn

Continue the conversation with a linked follow-up drill.

Prove ThreadPool Starvation

Prerequisite

Review this first if the current drill feels shaky.

Triage with dotnet-counters

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

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Next interviewer turn

Prerequisite

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

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Next interviewer turn

Prerequisite