Analyze Crash

### Frame X: {function_name} ([{file}:{line}](GitHub link))

```cpp
// {file}:{start_line}-{end_line}
{code with crash line marked}

### Phase 4: Reconstruct Crash Flow

Build a narrative explaining the execution flow leading to the crash. This is the primary goal of the analysis - to help engineers understand what happened:

1. **Entry point**: Where did execution start? (e.g., profiler callback, background thread loop)
2. **Key operations**: What was the code trying to do?
3. **Critical transitions**: Where did control flow between components?
4. **Failure point**: Where and why did it crash?
5. **Crash type**: Describe what type of crash this is (e.g., null pointer dereference, access violation, invalid module reference, race condition, etc.)

Write this as a clear, step-by-step narrative that someone unfamiliar with the code can follow. Focus on explaining HOW the crash happened based on the evidence in the stack trace and code, without prescribing a specific fix.

### Phase 5: Identify Related Code

Use Bash tool with git commands to find relevant context, focusing on commits associated with PRs:

1. Check recent commits to the affected files: `git log --oneline -10 {file}`
2. Search for related changes: `git log --grep="crash" --grep="fix" --oneline -20` (use keywords relevant to the crash area)
3. For each relevant commit, check if it's associated with a PR:
   - Look for PR numbers in commit messages (e.g., "(#1234)" or "PR #1234")
   - If found, construct PR link: `https://github.com/DataDog/dd-trace-dotnet/pull/{number}`
4. Prioritize commits with PR associations - these have more context
5. Look for similar code patterns in other files that might provide context

**Focus on commits with PR links** - PRs provide valuable context including descriptions, discussions, and rationale that individual commits lack.

## Output Format

Generate a well-formatted markdown document with these sections:

```markdown
# Crash Analysis Report
**Generated**: {ISO 8601 timestamp}

## Executive Summary
{2-3 sentence summary of what crashed and where in the code. Focus on demystifying the crash location and describing what the crashing thread was doing.}

## Stack Trace Classification

### Crashed Thread: #{thread_number}

| # | Type | Location | Description |
|---|------|----------|-------------|
| 0 | {type} | {function/location} | {brief description} |
| 1 | {type} | {function/location} | {brief description} |
| ... | ... | ... | ... |

{If multiple threads provided, note other interesting threads but focus on crashed thread}

## Code Context

{For each critical dd-trace-dotnet frame, show code with analysis}

### Frame X: {function} ([{file}:{line}](GitHub link))

```cpp
{code snippet with crash line marked}

## Output File Management

1. **Create output directory**:
   - On Windows: Use `powershell.exe -NoProfile -Command 'New-Item -ItemType Directory -Force -Path (Join-Path $env:USERPROFILE ".claude\analysis") | Select-Object -ExpandProperty FullName'`
   - On Linux/Mac: Use `mkdir -p ~/.claude/analysis && echo ~/.claude/analysis`
   - **IMPORTANT**: On Windows, you MUST use single quotes around the PowerShell command to prevent bash from interpreting `$env:USERPROFILE`
2. **Generate filename**: Use format `crash-analysis-{YYYYMMDD-HHMMSS}.md` (e.g., `crash-analysis-20250316-143022.md`)
3. **Save file**: Write the markdown analysis to the file
4. **Return path**: Tell the user the full path where the analysis was saved

## Important Guidelines

- **Focus on triage and understanding**: The goal is to help engineers understand HOW the crash happened, not to prescribe specific fixes
- **Describe crash types**: It's okay to identify what type of crash this is (e.g., null pointer, race condition, invalid reference), but don't match against fixed "patterns"
- **End at explanation**: Phase 4 (Crash Flow Reconstruction) should provide a clear explanation of how the crash occurred. Engineers will then decide on fixes
- **No fix suggestions**: Do not suggest code changes, patches, or specific implementation fixes. Focus on analysis only
- **Handle path variations gracefully**: Stack traces from different build environments will have different path prefixes
- **Continue with missing information**: If a file can't be located, note this but continue the analysis with available information
- **Focus on the crashed thread**: If multiple threads are provided, focus primarily on the crashed thread but mention other relevant threads
- **Be concise but thorough**: Provide enough detail to understand the issue without unnecessary verbosity
- **Always include GitHub links**: Every file:line reference should have a clickable GitHub link to master branch
- **Prefer PR links over commits**: When git log finds relevant commits, prioritize those associated with PRs. Extract PR numbers from commit messages (e.g., "(#1234)") and link to the PR: `https://github.com/DataDog/dd-trace-dotnet/pull/{number}`. Only include standalone commit links if particularly relevant and not part of a PR
- **Mark uncertainties**: If something is unclear or speculative, explicitly state this

## Now Analyze

Parse the stack trace provided by the user and follow the workflow above to generate a comprehensive crash analysis.