Skip to content

ScWin32Status .0 vs .64 Distribution

Scenario: You are investigating 500.121 timeouts on Windows App Service and want to distinguish quiet baseline cuts from concurrency-induced bursts. Data Source: AppServiceHTTPLogs Purpose: Quantify the ratio of ScWin32Status = 0 (normal front-end cut) to ScWin32Status = 64 (adaptive-extension fire). A significant .64 fraction indicates queue pressure or loopback saturation, not merely a slow request.

flowchart TD
    A[AppServiceHTTPLogs] --> B[Filter 500/121]
    B --> C[summarize by ScWin32Status]
    C --> D{Any ScWin32Status == 64?}
    D -->|No| E[Baseline signature only]
    D -->|Yes, small %| F[Occasional concurrency spike]
    D -->|Yes, large %| G[Sustained queue pressure]

Run It in the Portal

Paste the query below into the New Query 1 editor and press Run. The result grid returns one row per distinct ScWin32Status value in the filtered set; on a quiet app you may see only ScWin32Status = 0, and a ScWin32Status = 64 row is what you're looking for.

Query

AppServiceHTTPLogs
| where TimeGenerated > ago(24h)
| where ScStatus == 500 and ScSubStatus == 121
| summarize
    count_ = count(),
    earliest = min(TimeGenerated),
    latest = max(TimeGenerated)
    by ScWin32Status
| extend percent_of_500_121 = round(100.0 * count_ / toscalar(
        AppServiceHTTPLogs
        | where TimeGenerated > ago(24h)
        | where ScStatus == 500 and ScSubStatus == 121
        | count
    ), 2)
| order by count_ desc

Interpretation Notes

The ScWin32Status extension on 500.121 is a Windows App Service platform signal:

ScWin32Status Meaning
0 Normal front-end 230s absolute cut. The request was already at the front-end ceiling and there was no additional adaptive extension activity.
64 Adaptive-extension fire. The platform observed request-queue pressure or loopback saturation and augmented the raw 230s cut with an extension marker. Under load this becomes the dominant sub-status observed by production teams as 500.121.64.

Read your result against this decision table:

.0 % .64 % Interpretation
~100% ~0% Serialized baseline. Requests are being cut at 230s without concurrency pressure. Same as Lab 1 baseline.
60-90% 10-40% Occasional queue pressure. Look at the timestamps in the earliest / latest columns - if the .64 rows cluster into a short window, correlate with a deployment, traffic spike, or downstream slowdown.
< 50% > 50% Sustained queue pressure or loopback saturation. The dominant failure mode is no longer "slow request hits front-end ceiling"; it is "many requests queue in front of the httpPlatformHandler at once". Route to Lab 2 methodology (open-model load reproduction, mitigation candidates: httpPlatformHandler.requestTimeout extension, custom Auto-Heal, plan scale-out).

Lab 1 of the Windows Java httpPlatformHandler Timeout Lab confirmed the top row: 10/10 rows with ScWin32Status = 0 under serialized (queue depth 1) load, zero .64 rows. This established that .64 is not noise in the baseline signature - any .64 observed in production is a real signal of concurrency-induced pressure.

Limitations

  • ScWin32Status = 64 in the presence of 500/121 is a derived platform signal. It is not enumerated in the public IIS status-code reference; the interpretation above is based on empirical observation from Lab 1 and production ticket data.
  • The percentage math uses two independent queries against the same table. If new rows are ingested between the outer and inner query evaluation the percentages will be slightly off (typically < 1% error).
  • ScWin32Status values other than 0 and 64 may appear on 500/121 rows in future platform updates. Treat unknown values as "investigate further" rather than assuming they mean .64.
  • The query returns only aggregates. For per-request context, cross-reference with the 500/121 timeout signature detection query filtered by the same time range.

See Also

Sources