Separate an awaited operation from a physically blocked thread in a .NET profile

Source facts

In a .NET Profiler trace, AWAIT_TIME represents the logical wait for another task. With a C# await, the thread unwinds and returns control to the thread pool; no thread remains physically blocked waiting for that await. Framework attribution can represent the framework’s await handling or its telemetry recording. Disabling Framework dependencies in the view helps expose the application’s originating code. CPU_TIME instead identifies sampled execution on a processor. Microsoft Learn.

Applicability

Use this distinction while examining an asynchronous request trace. The duration of a logical operation, occupied processor time and a thread waiting for a resource are different observations and should not be assigned the same proposed remedy.

DSE recommendation

Trace the awaited operation before proposing more worker threads or treating elapsed wait as CPU work. Ask the application owner which dependency or task must finish and what evidence can explain its delay. Compare application-only and framework-inclusive views without discarding the original trace. Choose an investigation based on the identified wait rather than the largest duration alone.

Verification

Record the relevant call path, wait marker and operation timeline from a representative request. Confirm where the await originates and compare it with independent evidence from the awaited operation. After an approved change, collect comparable request traces and test whether the targeted delay changed. Do not claim reduced CPU demand or resolved thread contention solely because the logical wait became shorter.

Official references

Microsoft Learn: Reading .NET Profiler traces. Source reviewed September 9, 2026.