Skip to content

Windows httpPlatformHandler Queries

Reusable KQL queries for Azure App Service Windows Java SE apps running under IIS + httpPlatformHandler. Every query in this pack was validated during Lab 1 of the Windows Java httpPlatformHandler Timeout Lab.

Unlike the Linux-oriented HTTP query pack, these queries target the Windows-specific IIS sub-status codes (500.121.0, 500.121.64), the ScWin32Status field that only Windows populates, and the correlation between IIS request-log cuts and Java process console markers.

flowchart TD
    A[Windows Java SE app<br/>IIS + httpPlatformHandler] --> B[AppServiceHTTPLogs]
    A --> C[AppServiceConsoleLogs]
    B --> D[500.121 signature detection]
    B --> E[Front-end 230s cluster statistics]
    B --> F[ScWin32Status .0 vs .64 distribution]
    C --> G[Backend orphan-work timeline]
    B --> G

When to Use This Pack

Reach for these queries when any of the following holds:

  • Symptom is an intermittent or systematic HTTP 500 on a Windows App Service (Java SE, Python on Windows, Node on Windows) with ScSubStatus = 121.
  • Client-observed cutoff sits near 230 seconds and you need to prove it is the App Service front-end absolute limit, not the httpPlatformHandler requestTimeout or an application timer.
  • Client reports 500.121.64 bursts under load and you need to confirm adaptive-extension activity vs raw .0 cuts.
  • You need to correlate IIS request-log cuts with backend Java process activity to prove orphan work after the client is disconnected.

If the symptom is on Linux App Service, use the HTTP query pack or the Console query pack instead - ScSubStatus = 121 is a Windows-only signal.

Run It in the Portal

Paste any snippet below into the New Query 1 editor and press Run. Every query in this pack reads from AppServiceHTTPLogs or AppServiceConsoleLogs, both of which are populated once App Service diagnostic settings route to a Log Analytics workspace, so no extra Portal configuration is needed beyond the workspace itself. Tighten the blade-level Time range for burst-window investigations.

Available Queries

Query Purpose
500/121 timeout signature detection List every httpPlatformHandler timeout event (500/121) with URL, TimeTaken, and status details.
Timeout cluster statistics Aggregate TimeTaken mean/stdev/min/max across 500/121 rows to confirm the front-end 230s cluster.
ScWin32Status .0 vs .64 distribution Count 500.121.0 (normal front-end cut) vs 500.121.64 (adaptive-extension fire) to detect concurrency pressure.
Backend orphan-work timeline Union AppServiceHTTPLogs cuts with AppServiceConsoleLogs stream markers to visualize IIS <-> backend divergence.

Usage Notes

  • The 500.121 sub-status is documented as "The FastCGI process has timed out" but is reused by httpPlatformHandler on Windows App Service. Do not interpret it as a literal FastCGI event on Java SE apps.
  • ScWin32Status = 64 in the presence of ScStatus/ScSubStatus = 500/121 means the platform-side adaptive-extension logic fired. On the current App Service front-end this is a derived signal - it is not documented in the public IIS status-code reference.
  • AppServiceConsoleLogs captures stdout/stderr from the Java process regardless of whether the client is still connected. This is what makes the backend-orphan-work query possible.
  • All queries default to ago(24h). Widen to ago(7d) for slow-burn incidents, narrow to ago(1h) for burst-window investigations.

See Also

Sources