Provided “AS IS”. No warranty, no guarantees. Use at your own risk — especially on production systems. Read the disclaimer.

Usage Best Practices

HangTrace is designed to be safe and lightweight, but “hang diagnosis” often touches sensitive areas (threads, memory, traces). These best practices help you get useful data without creating new problems.

1) Prefer a short observation window

  • Run HangTrace when the app is clearly hung, but before you force-kill it.
  • If possible, reproduce the hang, then diagnose immediately.

2) Start minimal, escalate carefully

  • Start with: --html (fast, shareable).
  • Use --deep only when needed (more threads/stacks).
  • Use --dump only when you understand the sensitivity of dumps.

3) Run as Administrator only when necessary

Some processes/threads cannot be inspected without elevation. If you see access denied warnings, rerun HangTrace as Administrator to improve signal quality.

4) Treat dumps and traces as sensitive

  • Minidumps can contain memory fragments (passwords, tokens, documents).
  • ETW traces can reveal process activity and paths.
  • Store artifacts securely and redact/share carefully.

5) Avoid disrupting production

  • Use HangTrace during maintenance windows when possible.
  • Prefer --etw “micro-trace” over long tracing sessions.
  • Document what you ran, when, and why (ticket/incident link).

6) Verify your environment

Run hangtrace --selftest on new machines to confirm reporting/WCT/symbol capability. If you plan to use ETW micro-trace, run hangtrace --selftest --etw test.etl to confirm WPR is available.

Example playbook

hangtrace --process app.exe --html report.html
hangtrace --pid 1234 --deep --dump app.dmp
hangtrace --pid 1234 --etw trace.etl --html report.html

Reminder: HangTrace is a diagnostic tool. Use only with permission and follow local laws and policies.