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

> Does AWAIT_TIME in an Application Insights profile mean that a worker thread remained blocked?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:29:09+00:00
- Modified: 2026-09-10T00:55:35+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Explainer
- DSE priority: Information
- Topics: IT
- Reading time: 2 minutes

## What you need to know

Does AWAIT_TIME in an Application Insights profile mean that a worker thread remained blocked?

## Potentially affected

Developers interpreting Application Insights Profiler for .NET asynchronous call stacks.

## DSE recommendation

Trace the awaited operation before proposing more worker threads or treating elapsed wait as CPU work.

## Article

## 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](https://learn.microsoft.com/en-us/azure/azure-monitor/profiler/profiler-data).

## 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](https://learn.microsoft.com/en-us/azure/azure-monitor/profiler/profiler-data). Source reviewed September 9, 2026.

## Primary reference

- Name: View .NET Profiler trace data - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/profiler/profiler-data
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Separate an awaited operation from a physically blocked thread in a .NET profile,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.