Explain what keeps an object alive in .NET and how that causes memory problems.

In production I distinguish retention from allocation pressure. Allocation-rate, heap-size, generation, and pause metrics tell me the broad symptom; two comparable heap snapshots and root paths explain why survivors remain. I reproduce the workload long enough to pass normal warm-up and cache population, then compare object counts and retained size rather than blaming any large object. Common owners include unbounded caches, static collections, event subscriptions, timers, pending Tasks, closures, channels, and native handles with managed targets. A weak reference is useful only when loss is semantically acceptable; it is not a general repair for unclear ownership. I also check whether a queue is legitimately backlogged, because retained work may indicate throughput failure rather than a memory leak. The fix introduces a real lifetime boundary such as bounded eviction, unsubscribe-on-dispose, completed callback removal, queue backpressure, or passing an ID instead of a full request graph. A load test then proves the heap reaches a stable range and that the root path disappears without forcing GC.Collect, which would only mask the ownership bug and add latency.