Engineering

Error Analysis Prompt

An exception is a symptom, not a diagnosis: trace from the throw site back to the root trigger, with the runtime checklist on the table.

Overview

The exception message tells you where it hurt — not why. This setup runs the runtime error strategy on a production-adjacent NullReferenceException: locate the exact failure point and the state at that moment, trace the execution path backward from the throw to the trigger, and distinguish the proximate cause (what threw) from the root trigger (what made it throw) — with the runtime checklist covering null paths, dependency failures, invalid state, configuration differences, environment drift, and unchecked input contracts.

Workflow

Paste the exception raw
Message, stack, and the log lines around it — the detector recognizes them and the contract carries them verbatim.
Demand the trigger, not the site
Line 142 threw; the investigation asks what reached line 142 in that state.
Validate before patching
A null check at the throw site is a symptom fix — the contract labels it as a temporary mitigation unless the trigger is addressed.

Why This Works

Throw-site vs cause-site framing redirects effort to where the bug actually is
The runtime checklist covers the unglamorous causes (config, drift) that stack traces hide
Symptom-fix labeling stops null checks from masquerading as repairs

Best for

Exceptions that "can't happen" but did
Errors that appear in one environment and not another
Developers handed a stack trace and a deadline

Not for

Errors with no exception — wrong results are the functional-bug strategy
AI output format errors — that's the AI Output Validator

Use cases

Working a NullReferenceException back to its real cause
Separating what threw from what made it throw
Checking environment drift before blaming the code

Customize This Resource

Opens this setup in Debugging Prompt Generator. Generate to get the full investigation contract — then adjust the problem type, mode, and environment.

Open in Debugging Prompt Generator

Prompt Template

DEBUGGING OBJECTIVE
Analyze the NullReferenceException thrown in checkout since this morning.
Problem type: runtime error — an exception, crash, or stack trace marks the failure.
Determine what is actually happening. Do not jump directly to a solution before identifying the most likely root cause.

SYSTEM CONTEXT
Environment: staging — verify parity with production configuration; any difference from production is itself a suspect.
Reported severity: High.
Investigation strategy for this problem type:
- Locate the exact failure point: the line, the call, and the state at the moment of failure.
- Trace the execution path backward from the failure to its trigger — the throw site is rarely the cause site.
- Distinguish the proximate cause (what threw) from the root trigger (what made it throw).

KNOWN FACTS
Symptoms: Checkout fails with HTTP 500 for some users.
Expected behavior: Checkout completes and returns the confirmation page.
Actual behavior: HTTP 500; exception thrown in OrderProcessor.CalculateShipping.
Reproduction steps:
- Add an item with no shipping dimensions to the cart
- Proceed to checkout
Logs / errors:
```
System.NullReferenceException: Object reference not set to an instance of an object.
   at OrderProcessor.CalculateShipping(Order order) in OrderProcessor.cs:line 142
   at OrderProcessor.Process(Order order) in OrderProcessor.cs:line 87
   at CheckoutController.Post(CheckoutRequest req)
```

INVESTIGATION FRAMEWORK
Structure the investigation in exactly these stages:
1. SYMPTOMS — restate the observable symptoms, separating observations from interpretations.
2. KNOWN FACTS — list what is directly evidenced, each fact with its source.
3. REPRODUCTION STEPS — verify the provided steps reproduce the problem; reduce them to the minimal failing case.
4. POSSIBLE CAUSES — candidate causes, drawn from the checklist below and from the evidence.
5. ROOT CAUSE ANALYSIS — the most likely cause and the alternatives, per the root cause rules.
6. EVIDENCE REVIEW — which evidence is solid, which is weak, which is missing, and what contradicts what.
7. MISSING INFORMATION — what you need that you do not have. Ask for it; do not guess it.
8. VALIDATION PLAN — the tests or observations that will confirm or eliminate the leading cause.
9. FIX RECOMMENDATION — per the fix requirements below.
10. POST-FIX VERIFICATION — per the verification requirements below.

DEBUGGING CHECKLIST
Candidate causes to check for this problem type:
1. Null/undefined references on the failure path
2. Dependency failures (network, database, filesystem) surfacing as exceptions
3. Invalid state reached through an unexpected order of operations
4. Configuration differences from the environment where it works
5. Environment drift: versions, locales, time zones, OS differences
6. Input that violates an implicit contract the code never checks

ROOT CAUSE RULES
- Identify the MOST LIKELY root cause — and at least two ALTERNATIVE causes.
- For each candidate cause: list the evidence supporting it AND the evidence contradicting it.
- Define a validation step for each candidate: what observation would confirm or eliminate it.
- The symptom site and the cause site may be different places — finding where it hurts is not finding why.

EVIDENCE RULES
Label every statement as exactly one of:
- FACT: directly observed. Example: "The application returned HTTP 500."
- ASSUMPTION: believed without direct evidence. Example: "The database is probably down." Assumptions must be verified or discarded — never silently promoted to facts.
- HYPOTHESIS: a testable causal claim. Example: "A failed database connection may be causing the 500 response." Every hypothesis comes with its test.
- Prefer evidence over inference; where evidence is missing, label the assumption explicitly.
- Carry at least two hypotheses until evidence separates them.

VALIDATION REQUIREMENTS
- Before proposing any fix, state how the diagnosis was validated — or what validation is still pending.
- The gold standard: a reproduction that turns the failure on and off by toggling the suspected cause.
- If the root cause cannot be validated with the available information, say so and list what is needed.

FIX REQUIREMENTS
- Any fix proposal must include: the likely cause, the supporting evidence, the proposed change, and how to verify it worked.
- Frame it as "here is why this is likely the fix" — never an unexplained patch.
- Prefer the smallest fix that addresses the root cause; label symptom-only fixes as temporary mitigations.

POST-FIX VERIFICATION
- Define what to observe after the fix: the original reproduction passing, error rates at baseline, the affected metric recovered.
- Check for regressions in the paths the fix touched.
- State how long to observe before declaring the problem resolved — intermittent problems need longer windows.

Related Resources

Explore more resources that work well with this one.