{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile/",
        "slug": "dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile",
        "url": "https://update.dsesecurity.com/updates/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile/"
        },
        "title": "Separate an awaited operation from a physically blocked thread in a .NET profile",
        "summary": "Does AWAIT_TIME in an Application Insights profile mean that a worker thread remained blocked?",
        "format": {
            "slug": "explainer",
            "name": "Explainer"
        },
        "priority": {
            "slug": "info",
            "name": "Information"
        },
        "featured": false,
        "image": {
            "theme": "managed-it",
            "label": "Managed IT operations",
            "alt": "A controlled technology lifecycle progressing from assessment to approved production.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/managed-it-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/managed-it-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "it",
                "name": "IT",
                "url": "https://update.dsesecurity.com/topic/it/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-09-10T00:29:09+00:00",
        "modified_at": "2026-09-10T00:55:35+00:00",
        "reviewed_on": "2026-09-09",
        "reading_minutes": 2,
        "word_count": 244,
        "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.",
        "primary_source": {
            "name": "View .NET Profiler trace data - Azure Monitor | Microsoft Learn",
            "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/profiler/profiler-data",
            "published_on": null,
            "authority": "Microsoft Learn"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<h2>Source facts</h2>\n<p>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&#8217;s await handling or its telemetry recording. Disabling Framework dependencies in the view helps expose the application&#8217;s originating code. CPU_TIME instead identifies sampled execution on a processor. <a href=\"https://learn.microsoft.com/en-us/azure/azure-monitor/profiler/profiler-data\" target=\"_blank\" rel=\"noopener noreferrer\">Microsoft Learn</a>.</p>\n<h2>Applicability</h2>\n<p>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.</p>\n<h2>DSE recommendation</h2>\n<p>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.</p>\n<h2>Verification</h2>\n<p>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.</p>\n<h2>Official references</h2>\n<p><a href=\"https://learn.microsoft.com/en-us/azure/azure-monitor/profiler/profiler-data\" target=\"_blank\" rel=\"noopener noreferrer\">Microsoft Learn: Reading .NET Profiler traces</a>. Source reviewed September 9, 2026.</p>",
        "content_text": "Source facts\nIn 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.\nApplicability\nUse 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.\nDSE recommendation\nTrace 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.\nVerification\nRecord 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.\nOfficial references\nMicrosoft Learn: Reading .NET Profiler traces. Source reviewed September 9, 2026.",
        "content_markdown": "## Source facts\n\nIn 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).\n\n## Applicability\n\nUse 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.\n\n## DSE recommendation\n\nTrace 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.\n\n## Verification\n\nRecord 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.\n\n## Official references\n\n[Microsoft Learn: Reading .NET Profiler traces](https://learn.microsoft.com/en-us/azure/azure-monitor/profiler/profiler-data). Source reviewed September 9, 2026."
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile/",
                "url": "https://update.dsesecurity.com/updates/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-09-09"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Separate an awaited operation from a physically blocked thread in a .NET profile",
                        "item": "https://update.dsesecurity.com/updates/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile/#article",
                "identifier": "https://update.dsesecurity.com/updates/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile/",
                "url": "https://update.dsesecurity.com/updates/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile/",
                "headline": "Separate an awaited operation from a physically blocked thread in a .NET profile",
                "description": "Does AWAIT_TIME in an Application Insights profile mean that a worker thread remained blocked?",
                "abstract": "Does AWAIT_TIME in an Application Insights profile mean that a worker thread remained blocked?",
                "articleBody": "Source facts\nIn 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.\nApplicability\nUse 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.\nDSE recommendation\nTrace 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.\nVerification\nRecord 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.\nOfficial references\nMicrosoft Learn: Reading .NET Profiler traces. Source reviewed September 9, 2026.",
                "datePublished": "2026-09-10T00:29:09+00:00",
                "dateModified": "2026-09-10T00:55:35+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/dse-20260909-167-separate-an-awaited-operation-from-a-physically-blocked-thread-in-a-net-profile/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Separate an awaited operation from a physically blocked thread in a .NET profile"
                },
                "articleSection": [
                    "IT"
                ],
                "keywords": [
                    "IT",
                    "Explainer",
                    "Information priority"
                ],
                "genre": "Explainer",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "IT",
                        "url": "https://update.dsesecurity.com/topic/it/"
                    }
                ],
                "wordCount": 244,
                "timeRequired": "PT2M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "View .NET Profiler trace data - Azure Monitor | Microsoft Learn",
                    "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/profiler/profiler-data"
                }
            }
        ]
    }
}