Skip to content
littleden.blogEvidence-led Windows troubleshooting, without the guesswork
Diagnostics & reliability · scoped error record
Event ID 1002

Application Hang: the app stopped interacting with Windows

Treat Application Hang evidence as proof of a non-responsive process state, then correlate the process, report ID, wait chain and WER record before assigning cause.

Applies to: Windows application hang contextReviewed: 2026-09-17

What it means in this context

Application Hang records indicate that a program stopped interacting with Windows and was closed or reported as hung. Microsoft documents AppHang reporting as distinct from application-crash reporting and notes that hang reports can be correlated with WER using the same ReportID in the reporting pipeline. The event identifies the affected process and hang state; it does not by itself prove which dependency caused the hang.

Diagnostic state

What is known, and what is not proven yet

Keep observation, evidence and conclusion separate before making a higher-impact change.

Observed fact

One application stopped responding.

Windows evidence

Application Hang event, report ID, process path/version, wait chain and matching WER/ Reliability Monitor entry.

Likely subsystem

The user-mode application or a dependency/resource it waits on.

Evidence still needed

A repeated matching signature or dependency pattern.

Safe next action

Repair/update the owning application or proven dependency only after correlation.

Handoff boundary

Vendor/IT/debugger with the report ID and process dump if the hang remains reproducible.

Start here
  1. Confirm the source is Application Hang and preserve the exact timestamp.
  2. Record the application name/version, process ID, application path, report ID and hang type when present.
  3. Check whether the same application/hang signature repeats.
  4. Compare the incident with Task Manager wait-chain evidence, Reliability Monitor and WER records.
1

Correlate the hang instead of treating the event number as the cause

Low risk

Why: The useful information is the affected process, repeated signature and dependency state—not the number 1002 alone.

  1. Match the event to what the user saw at the same time.
  2. Compare another occurrence for the same executable/version/hang type.
  3. If the process is still hung, use Analyze wait chain before ending it.
  4. If support needs deeper state, capture a user-mode process dump securely.
Scope boundary

When not to use this record

Do not reinstall Windows, disable random services or kill unrelated wait-chain processes simply because Event ID 1002 appeared once.

If it persists

Use the app-hang guide for repeatable Not responding behavior; use Event 1000/WER crash guidance if the process actually terminates with a crash instead.

Evidence

Reviewed source