ObjectDisposedException in C#: Stop Using Dead Objects

ObjectDisposedException is the lifetime bug that survives every code review because each method looks correct in isolation. The using block is textbook. The async call is textbook. The factory registration is textbook. But composed across scopes and threads, the disposal lands before the last use — a query returned past its scope, a client disposed per request, a context shared with a background task that outlives the request.

HttpClient is the famous case: disposing per request churns sockets into TIME_WAIT until the box runs dry, yet never disposing a DNS-cached singleton misses DNS changes. DbContext is the common case: scoped per request, dead the moment the scope ends, and lethal in any fire-and-forget continuation. Streams and readers fill out the trio — closed by one owner while another still reads.

This guide maps each pattern to its fix: IHttpClientFactory for HTTP, scope-bound awaiting for contexts, single ownership for streams, and fixture-per-test discipline. You'll learn to read the ObjectName property (it names the corpse), trace disposal to its scope, and restructure so use always precedes teardown.

What Disposed Really Means Under the Hood

Dispose tears down the unmanaged half of an object — OS handles, sockets, connections, file locks — while leaving the managed reference intact. That's why the failure is confusing: your variable isn't null, the debugger shows its fields, but every method throws because the resources behind it are gone. The ObjectName property names the corpse (HttpClient, AppDbContext, FileStream), and the stack trace shows who touched it — but neither shows who disposed it, which is the actual bug.

IDisposable exists because garbage collection only reclaims memory. Sockets, handles, and connections are scarce OS resources the GC can't see, so Dispose returns them deterministically instead of waiting for finalization. Using blocks automate the call on every exit path. The contract is one-way: once disposed, an object stays disposed — there is no undispse, and any use after is a defect by definition.

This asymmetry shapes every fix. You can't resurrect the object; you reorder the program so use precedes teardown. Find the disposal site (the using boundary, the scope end, the explicit Dispose call), find the late use (the continuation, the background task, the second test), and move one of them. Either extend the lifetime to cover the use, or finish the use before the lifetime ends. No third option exists, which makes these bugs wonderfully mechanical once you see them clearly.

await using var ctx = scope.ServiceProvider.GetRequiredService<AppDbContext>();
var rows = await ctx.Orders.Where(o => o.IsStale).ToListAsync();
// use BEFORE the block ends:
foreach (var r in rows) r.Archived = true;
await ctx.SaveChangesAsync();
// BAD: return ctx.Orders.Where(...); // executes after disposal

// Single owner closes; wrappers leave the inner stream alone:
using var reader = new StreamReader(sharedStream, leaveOpen: true);

HttpClient: The Singleton That Must Not Die Per Request

HttpClient looks disposable, so developers dispose it — and that instinct causes outages. Each disposal abandons its socket to TIME_WAIT for up to 4 minutes. At 900 requests per minute, dead sockets accumulate 28,000 deep against 16,000 ports, and new connections fail. The exception varies (disposed-object, timeout, connection-refused) but the cause is one: churning a pooled resource as if it were single-use.

The fix is sharing with rotation. IHttpClientFactory pools HttpMessageHandler instances with a default 2-minute lifetime: sockets reuse aggressively while DNS refreshes periodically, dodging both exhaustion and stale-DNS traps of static singletons. Registration is one line (AddHttpClient), consumption is constructor injection, and typed clients keep configuration per downstream service. For legacy code, a single static HttpClient works but needs handler-lifetime management by hand.

Watch the two adjacent traps. Disposing the injected client from the factory breaks pooling — the factory owns the lifetime, not you. And socket metrics belong on every dashboard: TIME_WAIT counts predict exhaustion hours early. After the incident, the team's load test at 2x peak plus an 8,000-port alert made this class self-announcing. No HTTP plumbing change ships without surviving the peak it will serve.

builder.Services.AddHttpClient<PaymentsClient>(c =>
{
    c.BaseAddress = new Uri("https://pay.example.com");
    c.Timeout = TimeSpan.FromSeconds(10);
});

public sealed class PaymentsClient(HttpClient http)
{
    public async Task<bool> ChargeAsync(string id, decimal amount)
    {
        // Never dispose the injected client: factory owns it.
        var res = await http.PostAsJsonAsync("/charge", new { id, amount });
        return res.IsSuccessStatusCode;
    }
}

DbContext in Async Code: Await Inside the Scope

DbContext dies with its scope, and async continuations routinely outlive theirs. The pattern that kills: a method returns an unmaterialized IQueryable or an un-awaited Task, the using block exits, disposal runs, and the caller's await executes the query against a corpse. The trace points at the innocent await line in the caller while the guilty return sits a frame away — which is why these bugs survive reviews that examine each method alone.

The rule is absolute: materialize before the boundary. Call ToListAsync, FirstOrDefaultAsync, or SaveChangesAsync inside the using block and return data, never queries. For background work, create a dedicated scope with IServiceScopeFactory inside the worker and resolve a fresh context there — never capture the request's context in a lambda that runs after the response.

Registration discipline backs it up. DbContext must be Scoped: Singleton shares one context across threads (concurrency throws plus memory leaks), Transient hides lifetime bugs until scale exposes them. Tests need the same care — an in-memory context per test, disposed by the test that built it. Scope-bound awaiting plus scoped registration removes the entire category: no query can outlive its context because none ever crosses the boundary unmaterialized.

public async Task<List<Order>> GetStaleAsync(IServiceProvider sp)
{
    using var scope = sp.CreateScope();
    var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
    return await db.Orders.Where(o => o.IsStale).ToListAsync();
} // materialized INSIDE: safe to return

// Background worker owns its scope:
await using var wscope = provider.CreateAsyncScope();
var wdb = wscope.ServiceProvider.GetRequiredService<AppDbContext>();
await wdb.Orders.Where(o => o.IsStale).ExecuteDeleteAsync();

Streams and Readers: One Owner Closes

Shared streams die the same death: a StreamReader closes its underlying stream on dispose by default, so the second consumer finds a corpse. Helpers that accept a stream and wrap it in using look tidy and destroy the caller's resource. The fix is explicit single ownership — exactly one component disposes, everyone else borrows with leaveOpen: true and documents the arrangement in comments.

The leaveOpen parameter exists for this: new StreamReader(stream, leaveOpen: true) lets wrappers read without claiming disposal rights. The owner — usually the method that opened the file or the object holding the field — disposes last, after all borrowers finish and return. For async pipelines, await using on the owner guarantees flushed bytes before the handle closes.

Cross-thread sharing adds ordering to ownership. A stream closed on thread A while thread B reads throws regardless of flags, so hand off with explicit completion — await the reader task before disposing, or transfer ownership with a clear comment. When in doubt, don't share: copy the bytes into memory once and hand each consumer its own MemoryStream. Memory is cheap; debugging cross-thread disposal races at midnight is not worth it.

static string ReadTwoWays(Stream shared)
{
    using var r1 = new StreamReader(shared, leaveOpen: true);
    string a = r1.ReadToEnd();
    shared.Position = 0;
    using var r2 = new StreamReader(shared, leaveOpen: true);
    string b = r2.ReadToEnd();
    return a + b; // caller still owns shared: only caller disposes
}

static async Task CopyAsync(string src, string dst)
{
    await using var inf = new FileStream(src, FileMode.Open, FileAccess.Read, FileShare.Read);
    await using var outf = new FileStream(dst, FileMode.Create);
    await inf.CopyToAsync(outf);
}

Disposed Fixtures in Tests: Stop Sharing Corpses

Test suites produce the same exception for dumber reasons: a fixture disposed by test A gets reused by test B. Static shared contexts, ClassFixtures holding one DbContext for fifty tests, and parallel collections racing disposal all create failures that pass in isolation and fail in the suite — the classic suite-only red build that wastes whole mornings.

The fix is fixture-per-test economics. Build a fresh in-memory context or container per test, dispose it in the same test, and accept the milliseconds of setup cost — it's cheaper than one flaky-suite investigation. xUnit's IAsyncLifetime gives per-test Initialize/DisposeAsync hooks; collection fixtures should hold factories and connection strings, never live disposables.

Diagnose by bisection: run the failing test alone (green means cross-test interference), then binary-search the suite halves until the killer pair surfaces. Parallelization settings deserve a look too — tests sharing a static resource must declare a collection boundary or stop sharing. The incident team added a simple rule: no static disposable fields in test projects, enforced by a 10-line analyzer. Suite-only disposal failures dropped to zero within a sprint and never returned.

public sealed class PricingTests : IAsyncLifetime
{
    private AppDbContext _db = null!;
    public Task InitializeAsync()
    {
        var opts = new DbContextOptionsBuilder<AppDbContext>()
            .UseInMemoryDatabase(Guid.NewGuid().ToString()).Options;
        _db = new AppDbContext(opts);
        return Task.CompletedTask;
    }
    public async Task DisposeAsync() => await _db.DisposeAsync();
    [Fact]
    public async Task Discount_applies()
    {
        _db.Orders.Add(new Order { Amount = 10m });
        await _db.SaveChangesAsync();
        Assert.Equal(1, await _db.Orders.CountAsync());
    }
}

A Repeatable Disposal-Debugging Workflow

Start with the ObjectName — it tells you what died. HttpClient means pooling, DbContext means scope, Stream means ownership, fixture types mean test sharing. Then find the disposal site, not the use site: search for the using boundary, scope end, or Dispose call governing that instance. The use site in the trace is the victim; the disposal site upstream is the criminal.

Reproduce with lifetime in miniature: construct, dispose, then use — assert it throws the same ObjectName. For async scope bugs, write the test with an explicit scope block and an await after it; for socket churn, loop 1,000 requests and watch TIME_WAIT climb. Minimal repros turn cross-method mysteries into single-screen obviousness anyone can see.

Fix by reordering, never by resurrecting. Extend the lifetime (wider scope, factory pooling, single ownership) or finish the work earlier (materialize, copy bytes, await inside). Then add the guard that announces the next one: socket-count alerts, scope-leak analyzers, parallel-open tests, fixture rules. Disposal bugs are mechanical — use before teardown, always — and a codebase with the right guards stops producing them entirely within a single quarter of steady focused work.

using Xunit;
public sealed class DisposalTests
{
    [Fact]
    public async Task Query_after_scope_throws_named_context()
    {
        IQueryable<Order> leaked;
        using (var scope = TestProvider.CreateScope())
        {
            var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
            leaked = db.Orders.Where(o => o.IsStale); // not materialized!
        }
        await Assert.ThrowsAsync<ObjectDisposedException>(async () =>
            await leaked.ToListAsync());
    }
}