KQL · exceptions
Exception details for one problem ID
Everything about one exception problem in one row: count, first and last seen, affected operations, roles and users, and messages.
exceptions exceptions
let lookback = 7d;
let problem = "System.TimeoutException at Contoso.Orders.OrderRepository.Save";
exceptions
| where timestamp > ago(lookback)
| where problemId == problem
| summarize
exceptions = sum(itemCount),
first_seen = min(timestamp),
last_seen = max(timestamp),
operations = make_set(operation_Name, 10),
roles = make_set(cloud_RoleName, 10),
versions = make_set(application_Version, 10),
users = dcount(user_Id),
messages = make_set(outerMessage, 5)Returns: One row for the problem ID with its sampling-adjusted count, first and last time seen, up to ten operations, roles and versions, the number of distinct users and up to five distinct messages.
Pitfalls
- Replace the example problem ID with a real one; copy it from exceptions by type and operation, or from the Failures view. The match is exact and case-sensitive.
- users counts distinct user_Id values. Server-side exceptions often have no user ID at all unless your app sets one, so a small number here can mean 'not recorded', not 'few users'.
- make_set() lists distinct values, capped at the size you pass. Ten operations shown doesn't mean only ten were affected.
- Messages can contain IDs, e-mail addresses or other personal data your code put in them. Mind where you paste the result.
How it works
Once you know which problem to chase, you want its whole story in one place: how long it has been happening, where, to whom, and what it says. This query collapses one problem ID into a single row you can paste into a ticket.
Line by line
let problem = "...";is the problem ID to look at. The value in the query is an example; replace it with one from exceptions by type and operation or the Failures view. The data model describesproblemIdas identifying where in code the exception was thrown, typically the exception type plus a function from the call stack.exceptions = sum(itemCount)counts occurrences the sampling-aware way.first_seenandlast_seenbracket the problem in time. Afirst_seena few minutes after a deployment is the usual story.make_set(column, 10)collects up to ten distinct operations, roles and versions. Versions tell you whether a fix shipped: if the newest version is missing from the set, the problem may already be gone.users = dcount(user_Id)estimates how many distinct users were affected, when user IDs are recorded.messages = make_set(outerMessage, 5)shows up to five distinct outer messages, which often differ only in an ID and confirm it is one bug.
The stack frames
The row above has no call stack. The details column holds the exception structure, and Microsoft’s Classic API documentation shows reading methods from its parsedStack. For the latest occurrence:
let lookback = 7d;
let problem = "System.TimeoutException at Contoso.Orders.OrderRepository.Save";
exceptions
| where timestamp > ago(lookback)
| where problemId == problem
| top 1 by timestamp desc
| mv-expand frame = details[0].parsedStack
| project method = tostring(frame.method), operation_Idmv-expand turns the array of frames into one row per frame. Take the operation_Id into the end-to-end trace query to see the request, dependencies and logs around the exception. The correlation guide explains how that ID ties them together.
Variations
- Trend for the problem: replace the
summarizewithsummarize exceptions = sum(itemCount) by bin(timestamp, 1h)and add| render timechart. - Workspace tables: use
AppExceptions,TimeGenerated,ProblemId,OperationName,AppRoleName,AppVersion,UserId,OuterMessage,DetailsandItemCount.