Debugging scenarioMedium~8 min.NET Runtime Diagnostics Toolchain / 3 of 6

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

After counters confirm sustained CPU, I capture a short representative trace during the bad interval. A sampled CPU profile shows which call paths consume processor time, and runtime or application events can connect those paths to GC, contention, or a business operation. I avoid enabling every provider because noise and overhead can hide the signal. Then I compare the hot path with the active workload.

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.
After counters confirm sustained CPU, I capture a short representative trace during the bad interval. A sampled CPU profile shows which call paths consume processor time, and runtime or application events can connect those paths to GC, contention, or a business operation. I avoid enabling every provider because noise and overhead can hide the signal. Then I compare the hot path with the active workload.
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.
Sampling can miss very short or infrequent work, and managed traces may not explain native or kernel CPU. I choose capture length and providers from the hypothesis and escalate only when the missing visibility matters. A fix is verified by less CPU per unit of useful work and improved tail latency under the same load. Moving CPU elsewhere or reducing throughput is not a successful repair.

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 the section

Next in .NET Runtime Diagnostics Toolchain: Prove ThreadPool Starvation

Step 4 of 6

Prove ThreadPool starvation with counters, stacks, and traces

Practice route

Read core answer Review checklist Follow-up prompts Track progress

Finished this drill?

Practice freely. Sign in only when you want to save completion, confidence, notes, or bookmarks.

New to Aporeon? Create account

Drill details

Share the question with a concise Core-answer excerpt and invite other developers to add their perspective.

Was this drill useful?

Help improve the interview library.

Found this answer useful?

Say thanks with a standalone, one-time $5 contribution. No account required.

No subscription or perks.Choose another amount

Human editorial direction

Aporeon is shaped by Aleksandar Tomovski, a software developer with experience on both sides of technical interviews. Content is reviewed for accuracy, natural spoken delivery, useful depth, and honest trade-offs.

About the creator Editorial standards

Opening drill

Debugging scenarioMedium~8 min.NET Runtime Diagnostics Toolchain / 3 of 6

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.
After counters confirm sustained CPU, I capture a short representative trace during the bad interval. A sampled CPU profile shows which call paths consume processor time, and runtime or application events can connect those paths to GC, contention, or a business operation. I avoid enabling every provider because noise and overhead can hide the signal. Then I compare the hot path with the active workload.
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.
Sampling can miss very short or infrequent work, and managed traces may not explain native or kernel CPU. I choose capture length and providers from the hypothesis and escalate only when the missing visibility matters. A fix is verified by less CPU per unit of useful work and improved tail latency under the same load. Moving CPU elsewhere or reducing throughput is not a successful repair.

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 the section

Next in .NET Runtime Diagnostics Toolchain: Prove ThreadPool Starvation

Step 4 of 6

Prove ThreadPool starvation with counters, stacks, and traces

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 the section

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 the section