IDisposable, Finalizers and Resource Management Interview Questions

Q1 Walk through the full dispose pattern, including the finalizer. Why does Dispose(bool disposing) exist as a separate method?#

Short answer: The public parameterless Dispose() calls a protected virtual Dispose(bool disposing) with true, then calls GC.SuppressFinalize(this); the finalizer, if present, calls the same Dispose(bool disposing) with false. The disposing flag exists because the two call paths must behave differently: deterministic disposal can safely touch other managed objects, while finalization runs at an unpredictable time, possibly after those other objects were already finalized, so it must only release resources the object owns directly.

The bool parameter is the whole reason this pattern has two methods instead of one. When a caller calls Dispose(), every other object in the graph is still alive and it is safe to call Dispose() on managed fields, unsubscribe event handlers, and so on. When the finalizer runs instead — because a caller forgot to call Dispose() — the GC gives no ordering guarantee between finalizable objects; a referenced managed object could already be finalized, so touching it is unsafe and unnecessary, since it will be finalized on its own. Only unmanaged resources (raw handles, native memory) are safe and required to clean up from the finalizer path.

public class ReportExporter : IDisposable
{
    private FileStream? _output;      // managed: safe to dispose only when disposing == true
    private IntPtr _nativeBuffer;     // unmanaged: must be freed on both paths
    private bool _disposed;

    public ReportExporter(string path)
    {
        _output = File.Create(path);
        _nativeBuffer = Marshal.AllocHGlobal(4096);
    }

    public void Dispose()
    {
        Dispose(disposing: true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (_disposed) return;

        if (disposing)
        {
            _output?.Dispose(); // safe: nothing else has run its finalizer yet
        }

        if (_nativeBuffer != IntPtr.Zero)
        {
            Marshal.FreeHGlobal(_nativeBuffer);
            _nativeBuffer = IntPtr.Zero;
        }

        _disposed = true;
    }

    ~ReportExporter() => Dispose(disposing: false);
}

GC.SuppressFinalize(this) is the detail people forget to explain: without it, an object that was already deterministically disposed still gets queued for finalization later, paying the finalization cost for nothing since there is nothing left to free.

What interviewers look for: the exact reasoning for the disposing flag (safe to touch other objects vs. only touch what you own directly), not just the mechanical shape of the pattern.

Common mistakes: calling Dispose() on managed fields unconditionally inside the finalizer path, which can throw or do nothing useful if those fields were already finalized.

Q2 Why are finalizers expensive, and what does the GC actually do differently for a finalizable object?#

Short answer: A finalizable object cannot be collected in the GC cycle where it becomes unreachable; instead it is moved onto the finalization queue, its finalizer runs on a dedicated finalizer thread at some later point, and only after that does the object become eligible for collection in a subsequent GC — so every finalizable object survives at least one extra collection, and often gets promoted a generation earlier than an equivalent non-finalizable object would.

Mechanically: when the GC finds an unreachable object with a finalizer, it does not reclaim it. It moves the reference from the finalization queue to the "freachable" (finalization-reachable) queue, which by definition makes the object reachable again — the finalizer thread needs a live reference to call the finalizer on it. The object survives that collection, gets promoted, and only becomes truly collectible on a later GC once the finalizer thread has run its finalizer and removed it from the freachable queue. For a large, complex object, this doubles its effective lifetime and can drag surviving referenced objects into an older generation with it.

// Bad: forces every instance through the finalization queue even when Dispose is always called.
public sealed class Widget
{
    ~Widget() { /* cleanup */ } // present unconditionally: full finalization cost every time
}

// Good: GC.SuppressFinalize means a correctly-disposed instance skips finalization entirely.
public sealed class Widget : IDisposable
{
    public void Dispose() => GC.SuppressFinalize(this);
    ~Widget() { /* only runs if Dispose was never called */ }
}

The practical guidance follows directly from the mechanics: only add a finalizer when a type directly owns an unmanaged resource, always call GC.SuppressFinalize from Dispose(), and prefer wrapping the unmanaged resource in a SafeHandle so your own type does not need a finalizer at all, covered in the next question.

What interviewers look for: the freachable-queue mechanism explained correctly, specifically that finalization delays collection by at least one GC cycle rather than "finalizers are just slow" as a vague claim.

Follow-up questions:

• Why does an object referenced only by a finalizable object also get promoted a generation?
• What observable symptom would a profiler show for a type with an unnecessary finalizer under load?

Q3 What is SafeHandle, and why has it replaced hand-written finalizers for native resources in almost all modern code?#

Short answer: SafeHandle, in System.Runtime.InteropServices, is an abstract base class that wraps a native handle (an IntPtr) and guarantees it is released exactly once, safely, even under thread aborts or out-of-memory conditions during cleanup — problems a hand-written finalizer calling a P/Invoke release function directly cannot reliably solve on its own. You derive from it, override ReleaseHandle() with the native release call, and your own type then needs no finalizer at all, because SafeHandle already has one.

Before SafeHandle, correct native resource cleanup required careful ordering to avoid the handle being reused or the release call racing with a call still using the handle — subtle enough that most hand-rolled attempts got it wrong under stress. SafeHandle solves this with a reference-counting scheme tied to the actual use of the handle, plus critical-finalization guarantees so its own finalizer runs reliably even in shutdown scenarios where ordinary finalizers might not.

using System.Runtime.InteropServices;
using Microsoft.Win32.SafeHandles;

public sealed class NativeCounterHandle : SafeHandleZeroOrMinusOneIsInvalid
{
    public NativeCounterHandle() : base(ownsHandle: true) { }

    protected override bool ReleaseHandle()
    {
        NativeMethods.CloseCounter(handle);
        return true;
    }
}

// A type that owns one: no finalizer needed here at all.
public sealed class PerformanceCounterReader : IDisposable
{
    private readonly NativeCounterHandle _handle = NativeMethods.OpenCounter();

    public long Read() => NativeMethods.ReadCounter(_handle);

    public void Dispose() => _handle.Dispose(); // SafeHandle's own Dispose/finalizer do the rest
}

The framework ships ready-made SafeHandle derivatives for the common cases — SafeFileHandle, SafeRegistryHandle, SafeWaitHandle, and cryptography-related handles all live in Microsoft.Win32.SafeHandles — so most application code never even writes a custom SafeHandle; it just holds one returned by a framework API and disposes it like any other IDisposable.

What interviewers look for: knowing that SafeHandle removes the need for a hand-written finalizer entirely in the common case, and roughly why it is safer than a raw IntPtr plus a finalizer (reliable single release, not just "it's the modern way").

Common mistakes: writing a finalizer that calls a P/Invoke release function directly on a raw IntPtr field instead of wrapping it in a SafeHandle, reintroducing exactly the reliability problems SafeHandle exists to solve.

Q4 What is IAsyncDisposable, and how does it change your Dispose implementation and call sites?#

Short answer: IAsyncDisposable declares ValueTask DisposeAsync() for resources whose cleanup itself needs to be asynchronous — flushing a network stream, closing a database connection with a final round trip — which a synchronous Dispose() cannot express without blocking a thread on that I/O. It does not replace IDisposable; a type can, and often should, implement both, with DisposeAsync as the preferred path and a synchronous Dispose as a fallback for callers that cannot await.

The call-site change is the await using statement (and, since C# 8, an await using declaration), which calls DisposeAsync() and awaits the returned ValueTask instead of blocking. ValueTask, not Task, is the return type deliberately: most disposals complete synchronously (nothing was pending), and ValueTask avoids allocating a Task object for that common case.

public sealed class BufferedLogSink : IAsyncDisposable, IDisposable
{
    private readonly Stream _stream;
    private bool _disposed;

    public BufferedLogSink(Stream stream) => _stream = stream;

    public async ValueTask DisposeAsync()
    {
        if (_disposed) return;
        await _stream.FlushAsync().ConfigureAwait(false); // real async work during cleanup
        await _stream.DisposeAsync().ConfigureAwait(false);
        _disposed = true;
        GC.SuppressFinalize(this);
    }

    public void Dispose()
    {
        if (_disposed) return;
        _stream.Flush();  // blocking fallback for synchronous-only call sites
        _stream.Dispose();
        _disposed = true;
    }
}

await using var sink = new BufferedLogSink(File.Create("audit.log"));
await sink.DisposeAsync(); // implicit at the end of the enclosing scope

When a type implements both interfaces, DisposeAsync should not simply call the synchronous Dispose() internally if genuine async cleanup is possible — that defeats the purpose — but it is reasonable for the synchronous Dispose() to block on the same underlying cleanup as a documented fallback.

What interviewers look for: the correct reason ValueTask is used instead of Task (avoiding allocation on the common synchronous-completion path), and knowing this is additive to IDisposable, not a replacement for it.

Q5 What's the real difference between a using statement, a using declaration, and manual try/finally? Are there cases where a using declaration is the wrong choice?#

Short answer: All three ultimately compile to the same try/finally shape calling Dispose(); the difference is purely about scope. A classic using (...) block disposes at the end of its braces, a using declaration (C# 8, using var x = ...;) disposes at the end of the enclosing block or method, and manual try/finally is what you still reach for when disposal logic needs to do more than just call Dispose() — logging on failure, conditional disposal, or disposing in a specific order relative to other cleanup.

The using declaration's implicit, wider scope is exactly where it can go wrong: it is easy to declare several using var resources in a long method and lose track of exactly when each one is released relative to code that runs later in the same method, especially if that later code is lengthy or itself does I/O. In a short, focused method this is a non-issue and the declaration form reads far better than nested blocks; in a long method with several disposables, an explicit block can make lifetime visually obvious again.

// using declaration: disposed at the end of the method, not at the next line.
static void ExportReport(string path)
{
    using var writer = new StreamWriter(path);
    writer.WriteLine("header");
    DoSomethingSlow(); // writer is still open and holding the file handle here
} // writer.Dispose() runs here

// Classic block: scope is explicit and narrow.
static void ExportReportNarrowScope(string path)
{
    using (var writer = new StreamWriter(path))
    {
        writer.WriteLine("header");
    } // writer.Dispose() runs here, before DoSomethingSlow()

    DoSomethingSlow();
}

Manual try/finally remains the right tool when disposal must be conditional (only dispose on the failure path, keep the resource alive on success to return it to the caller) or when you need to guarantee an exact disposal order across resources that a stack of using declarations would reverse.

What interviewers look for: correctly stating that a using declaration's scope is the enclosing block, not "the next statement," since that misconception causes real file-handle and connection-lifetime bugs.

Common mistakes: stacking several using var declarations in a long method and accidentally holding a file or connection open across slow, unrelated work later in the same method.

Q6 What are the dependency injection container's disposal rules, and what's the classic mistake that turns a transient registration into a memory leak?#

Short answer: The built-in container disposes exactly what it creates: transient and scoped IDisposable/IAsyncDisposable instances are disposed when the scope that resolved them ends, and singletons are disposed when the root provider is disposed at application shutdown. Instances you register yourself with AddSingleton(instance) are the exception — the container did not create them, so it never disposes them, and that is by design. The classic leak is resolving a transient disposable directly from the root provider instead of from a request or unit-of-work scope: the root provider is itself a scope that lives for the application's entire lifetime, so every such instance is tracked and held until shutdown, growing without bound.

A second, related failure mode is subtler: if a scope resolves a service that implements only IAsyncDisposable and not IDisposable, disposing that scope synchronously throws InvalidOperationException at shutdown, because the container has no synchronous way to run that service's cleanup. The fix is disposing scopes asynchronously wherever any resolved service might be async-only.

public sealed class ReportJob(IServiceScopeFactory scopeFactory)
{
    public async Task RunAsync(CancellationToken cancellationToken)
    {
        // Correct: a fresh scope per unit of work, disposed (and its transients with it) here.
        await using var scope = scopeFactory.CreateAsyncScope();
        var generator = scope.ServiceProvider.GetRequiredService<IReportGenerator>();
        await generator.GenerateAsync(cancellationToken);
    } // transient/scoped disposables created inside this scope are disposed here

    // Wrong: resolving a transient IDisposable from a singleton's captured root-level provider
    // ties its lifetime to the whole application, not to this one call.
}

A closely related rule worth stating unprompted: application code should never call Dispose() directly on a service it received through constructor injection. The container owns that instance's lifetime; disposing a shared scoped or singleton service yourself breaks every other consumer still holding a reference to it.

What interviewers look for: the root-provider-as-permanent-scope explanation specifically, since "resolving transients from the root leaks" is a fact many candidates know without being able to explain why it leaks.

Common mistakes: injecting IServiceProvider directly into a singleton and resolving scoped or transient disposables from it ad hoc, which silently recreates the exact same root-scope leak through a different door.

Q7 Why does creating a new HttpClient per request cause socket exhaustion, and how does IHttpClientFactory address it?#

Short answer: Each HttpClient wraps a handler that owns its own underlying connection pool; creating a new handler for every logical request means every request gets its own pool instead of sharing one, and under load the process runs out of available outbound sockets — many sitting in TIME_WAIT — faster than the OS can reclaim them, causing socket exhaustion and connection delays. IHttpClientFactory fixes this by managing a small number of HttpMessageHandler instances per named or typed client and letting many short-lived HttpClient instances share them, so the connection pool is reused instead of recreated.

The naive "fix" of making one static readonly HttpClient for the whole application avoids socket exhaustion but trades it for a different bug: a long-lived handler keeps its connections open and does not observe DNS changes, so if a downstream service's IP address changes (a common event behind a load balancer or in a container orchestrator), the app keeps talking to the stale address until the process restarts. IHttpClientFactory splits the difference deliberately: it caches and reuses handlers, but recycles each one on a timer — the default handler lifetime is two minutes, configurable through SetHandlerLifetime() — so DNS changes are picked up on a bounded schedule without paying the per-request cost of a brand-new connection pool.

// Startup: register a typed client once; the factory owns handler pooling and rotation.
builder.Services.AddHttpClient<WeatherApiClient>(client =>
{
    client.BaseAddress = new Uri("https://weather.example/");
    client.Timeout = TimeSpan.FromSeconds(10);
}).SetHandlerLifetime(TimeSpan.FromMinutes(5));

public sealed class WeatherApiClient(HttpClient httpClient)
{
    // httpClient is short-lived and disposable-looking, but its handler is pooled underneath.
    public Task<WeatherReport?> GetForecastAsync(string city, CancellationToken ct) =>
        httpClient.GetFromJsonAsync<WeatherReport>($"forecast/{city}", ct);
}

public sealed record WeatherReport(string City, double TemperatureCelsius);

IHttpClientFactory-created clients are also where resilience policies belong: Microsoft.Extensions.Http.Resilience attaches retry, circuit breaker and timeout behavior directly to a named or typed client's handler pipeline, which the resilience guide covers in depth.

What interviewers look for: both halves of the trade-off — why per-request creation exhausts sockets, and why naive static reuse causes DNS staleness — since a candidate who names only one has an incomplete mental model.

Follow-up questions:

• Why is a TIME_WAIT socket a limited, slowly-reclaimed resource in the first place?
• What symptom would you see in production logs or metrics specifically from socket exhaustion, as opposed to a downstream timeout?

Q8 What are the most common real-world resource leaks you've seen in production C# code, and how do you find them?#

Short answer: Beyond a plain forgotten Dispose() call, the recurring patterns are event-handler leaks (a long-lived publisher holding a subscriber alive because nobody unsubscribed), disposables captured into a cache or closure that outlives the scope that created them, and disposing a resource but continuing to hand out references to it elsewhere in the codebase. All three show up as steadily growing memory rather than a crash, which is exactly why they survive in production for months before anyone notices.

The event-handler case is the most common one that has nothing to do with IDisposable on the surface: publisher.SomethingHappened += handler keeps the object owning handler alive for as long as publisher lives, because the delegate holds a reference back to its target. A short-lived view model subscribing to a singleton event source and never unsubscribing is a textbook leak that a memory profiler shows as an ever-growing generation-2 heap of objects that should have been collected. The fix is either an explicit -= in Dispose(), or a weak-reference-based event pattern when the subscriber's lifetime is genuinely shorter and unpredictable relative to the publisher's.

public sealed class PriceTicker : IDisposable
{
    private readonly IMarketFeed _feed;

    public PriceTicker(IMarketFeed feed)
    {
        _feed = feed;
        _feed.PriceChanged += OnPriceChanged; // feed now indirectly keeps 'this' alive
    }

    public void Dispose() => _feed.PriceChanged -= OnPriceChanged; // required, easy to forget

    private void OnPriceChanged(object? sender, decimal price) { /* ... */ }
}

Diagnosing these in production combines a few tools: a memory dump analyzed with dotnet-gcdump or Visual Studio's diagnostic tools to find an unexpectedly large object count and its retention path (what is still referencing it), and dotnet-counters or EventCounters to watch generation-2 heap size trend upward over time rather than sawtooth as it should under healthy collection. The retention path is usually the fastest way to the root cause: it shows you exactly which live reference — a static event, a cache, a captured closure — is keeping the leaked object reachable.

What interviewers look for: event-handler leaks named specifically, since they are both extremely common and easy to miss because they have nothing to do with Dispose() on their face, plus a real diagnostic workflow, not just "I'd use a profiler."

Q9 A class holds both a managed Stream and an unmanaged native buffer. Walk through structuring Dispose(bool) correctly for both.#

Short answer: Guard the whole method with a disposed flag to make it idempotent, dispose the managed Stream only inside the if (disposing) branch, free the unmanaged buffer unconditionally on both paths, and null out or zero any field you free so a second, accidental call cannot double-free it.

The order and the conditionality both matter. Managed fields must only be touched when disposing is true, because on the finalizer path (disposing == false) those fields may already have been finalized by the runtime in an unpredictable order relative to this object — calling Dispose() on them again is at best redundant and at worst throws. Unmanaged resources have no such hazard, since nothing else "owns" or independently finalizes a raw native pointer, so they must be freed on every path or a finalizer-triggered cleanup silently leaks them forever.

public class NativeImageBuffer : IDisposable
{
    private Stream? _backingFile;
    private IntPtr _pixels;
    private bool _disposed;

    public NativeImageBuffer(Stream backingFile, int byteCount)
    {
        _backingFile = backingFile;
        _pixels = Marshal.AllocHGlobal(byteCount);
    }

    public void Dispose()
    {
        Dispose(disposing: true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (_disposed) return; // idempotency guard: Dispose() may legitimately be called twice

        if (disposing)
        {
            _backingFile?.Dispose();
            _backingFile = null;
        }

        if (_pixels != IntPtr.Zero)
        {
            Marshal.FreeHGlobal(_pixels);
            _pixels = IntPtr.Zero; // prevents a double free if Dispose(bool) somehow runs again
        }

        _disposed = true;
    }

    ~NativeImageBuffer() => Dispose(disposing: false);
}

The idempotency guard is not optional polish: IDisposable.Dispose() is documented to be safely callable more than once, and code throughout the ecosystem (including using blocks nested in unusual control flow) relies on that guarantee holding.

What interviewers look for: correctly separating "safe to double-call" (idempotency) from "safe on both the sync and finalizer paths" (the disposing flag), since these are two different correctness properties that a shallow answer conflates into one.

Common mistakes: freeing the unmanaged buffer only inside if (disposing), which means a caller who forgets to call Dispose() leaks the native memory forever, since the finalizer path then does nothing either.

Q10 Should a struct implement IDisposable? What are the specific gotchas?#

Short answer: It is legal and sometimes useful — the using-based scoping pattern (a stack-allocated timer, a ref-struct-based buffer lease) is a common reason — but it comes with sharp edges specific to value-type semantics: an unintended copy of the struct can run Dispose() independently of the original, and boxing a disposable struct (assigning it to an object or a non-generic interface variable) allocates a new heap copy that a using block disposes separately from the value you still hold.

The copy problem is the one that catches people off guard in code review. Because structs copy on assignment, on being passed by value to a method, and even implicitly through foreach over certain enumerators, a disposable struct can have Dispose() called on a copy while the original is still in scope and believed to still own its resource, or have Dispose() called twice — once per copy — on resources that were never designed to tolerate that. A readonly struct protects against the struct's own fields being mutated after construction, but it does not prevent extra copies from being made and disposed independently; that is inherent to any non-ref struct's value semantics.

public readonly struct PooledBuffer : IDisposable
{
    private readonly byte[] _array;
    private readonly ArrayPool<byte> _pool;

    public PooledBuffer(ArrayPool<byte> pool, int minimumLength)
    {
        _pool = pool;
        _array = pool.Rent(minimumLength);
    }

    public Span<byte> Span => _array;

    // Danger: if this struct is copied, Dispose() can run more than once on the same array.
    public void Dispose() => _pool.Return(_array);
}

// Boxing: assigning to 'object' copies the struct to the heap; the boxed copy is
// what a 'using' block on that variable would dispose, not the original value.
object boxed = new PooledBuffer(ArrayPool<byte>.Shared, 1024);

The practical guidance: keep a disposable struct's Dispose() idempotent exactly as you would for a class (rentals returned to a pool are a natural fit, since returning an already-returned array twice is a bug regardless), avoid passing it by value into anything that might retain a copy, and reach for a ref struct instead when you specifically need to prevent boxing and heap capture altogether, at the cost of the stack-only restrictions that come with ref struct.

What interviewers look for: the boxing-creates-an-independent-copy detail specifically, since it is the gotcha most likely to actually bite someone in code that "worked in testing" and misbehaved only once a disposable struct was stored somewhere as an object or interface reference.

Follow-up questions:

• Why would a ref struct be a stronger design choice than a plain struct for a disposable buffer lease?
• What happens if a disposable struct is captured in a lambda closure?