Practice Now
ThreadPool
QueueUserWorkItem
exception handling
multithreading
C#

How to catch exceptions from a ThreadPool.QueueUserWorkItem?

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions
ConcurrencyC# & .NETDebugging & Errors

Introduction

Exceptions thrown inside ThreadPool.QueueUserWorkItem crash the application because they are unhandled on a thread pool thread. Unlike the main thread, there is no outer try/catch to catch them. The fix is to wrap the work item's body in a try/catch block, or better yet, use Task.Run() which captures exceptions and lets you observe them when you await the task. QueueUserWorkItem is a legacy API. Task.Run() is the modern replacement with built-in exception handling.

The Problem

csharp
1// This crashes the application: unhandled exception on a pool thread
2ThreadPool.QueueUserWorkItem(_ =>
3{
4    throw new InvalidOperationException("Something went wrong");
5});
6
7// The main thread never sees this exception
8// The CLR terminates the process (since .NET 2.0)

In .NET 1.x, unhandled thread pool exceptions were silently swallowed. Since .NET 2.0, they terminate the process. There is no built-in way to catch them from the calling thread.

Fix 1: Try/Catch Inside the Work Item

csharp
1ThreadPool.QueueUserWorkItem(_ =>
2{
3    try
4    {
5        // Your work here
6        ProcessData();
7    }
8    catch (Exception ex)
9    {
10        Console.WriteLine($"Error in work item: {ex.Message}");
11        // Log, report, or handle the exception
12        Logger.LogError(ex, "ThreadPool work item failed");
13    }
14});

This is the simplest approach but it has a drawback: the calling code cannot observe the exception. It is handled entirely within the work item.

csharp
1// Task.Run captures exceptions automatically
2Task task = Task.Run(() =>
3{
4    ProcessData();
5    throw new InvalidOperationException("Something failed");
6});
7
8try
9{
10    await task;  // Exception is re-thrown here
11}
12catch (InvalidOperationException ex)
13{
14    Console.WriteLine($"Caught: {ex.Message}");
15}

Task.Run() wraps the delegate in a Task that captures any exception. When you await the task, the exception is re-thrown on the calling thread, giving you normal try/catch semantics.

Fix 3: Callback Pattern for Exception Notification

csharp
1public static void QueueWorkWithCallback(
2    Action work,
3    Action<Exception>? onError = null,
4    Action? onComplete = null)
5{
6    ThreadPool.QueueUserWorkItem(_ =>
7    {
8        try
9        {
10            work();
11            onComplete?.Invoke();
12        }
13        catch (Exception ex)
14        {
15            onError?.Invoke(ex);
16        }
17    });
18}
19
20// Usage
21QueueWorkWithCallback(
22    work: () => ProcessData(),
23    onError: ex => Console.WriteLine($"Failed: {ex.Message}"),
24    onComplete: () => Console.WriteLine("Done")
25);

Fix 4: Shared Exception Variable

csharp
1Exception? caughtException = null;
2var done = new ManualResetEventSlim(false);
3
4ThreadPool.QueueUserWorkItem(_ =>
5{
6    try
7    {
8        ProcessData();
9    }
10    catch (Exception ex)
11    {
12        caughtException = ex;  // Use Volatile.Write for thread safety
13    }
14    finally
15    {
16        done.Set();
17    }
18});
19
20done.Wait();  // Block until work item completes
21
22if (caughtException != null)
23{
24    Console.WriteLine($"Work item failed: {caughtException.Message}");
25    throw caughtException;  // Re-throw if needed
26}

This pattern blocks the calling thread until the work completes, which largely defeats the purpose of using the thread pool. Prefer Task.Run() with await.

Fix 5: Global Unhandled Exception Handler (Last Resort)

csharp
1// Catches ALL unhandled exceptions in the application
2AppDomain.CurrentDomain.UnhandledException += (sender, args) =>
3{
4    var ex = (Exception)args.ExceptionObject;
5    Console.WriteLine($"Unhandled: {ex.Message}");
6    // Log the exception
7    // args.IsTerminating is true, the process will exit
8};
9
10// For Task exceptions that are never observed
11TaskScheduler.UnobservedTaskException += (sender, args) =>
12{
13    Console.WriteLine($"Unobserved task exception: {args.Exception.Message}");
14    args.SetObserved();  // Prevent process termination
15};

This does not recover from the exception. It only lets you log it before the process terminates.

Migration: QueueUserWorkItem to Task.Run

csharp
1// Before (legacy)
2ThreadPool.QueueUserWorkItem(state =>
3{
4    var data = (string)state;
5    Process(data);
6}, "my-data");
7
8// After (modern)
9await Task.Run(() =>
10{
11    Process("my-data");
12});
13
14// Fire-and-forget with exception logging
15_ = Task.Run(async () =>
16{
17    try
18    {
19        await ProcessAsync("my-data");
20    }
21    catch (Exception ex)
22    {
23        Logger.LogError(ex, "Background processing failed");
24    }
25});

QueueUserWorkItem with Return Values

csharp
1// QueueUserWorkItem cannot return values, use Task.Run
2Task<int> task = Task.Run(() =>
3{
4    return ComputeExpensiveResult();
5});
6
7int result = await task;  // Get the result, exceptions propagate here
8Console.WriteLine($"Result: {result}");

Thread Safety Considerations

csharp
1// Shared state needs synchronization
2var results = new ConcurrentBag<int>();
3var countdown = new CountdownEvent(10);
4
5for (int i = 0; i < 10; i++)
6{
7    int captured = i;  // Capture loop variable
8    ThreadPool.QueueUserWorkItem(_ =>
9    {
10        try
11        {
12            results.Add(Compute(captured));
13        }
14        catch (Exception ex)
15        {
16            Console.WriteLine($"Item {captured} failed: {ex.Message}");
17        }
18        finally
19        {
20            countdown.Signal();
21        }
22    });
23}
24
25countdown.Wait();
26Console.WriteLine($"Completed {results.Count} items");

Common Pitfalls

  • Not wrapping in try/catch: Unhandled exceptions on thread pool threads terminate the process. Always wrap the work item body in try/catch if you must use QueueUserWorkItem.
  • Using QueueUserWorkItem instead of Task.Run: Task.Run provides exception capturing, return values, cancellation, and await support. There is rarely a reason to use QueueUserWorkItem in modern .NET.
  • Swallowing exceptions silently: catch (Exception) { } hides bugs. At minimum, log the exception. Use ILogger, Console.Error, or an error tracking service.
  • Capturing loop variables: ThreadPool.QueueUserWorkItem(_ => Process(i)) in a loop captures the variable i, not its value. By the time the work item runs, i may have changed. Capture with int captured = i before the lambda.
  • Blocking the calling thread: Using ManualResetEvent.Wait() to observe exceptions defeats the purpose of background execution. Use async/await with Task.Run() instead.

Summary

  • ThreadPool.QueueUserWorkItem does not propagate exceptions to the caller. They crash the process
  • Wrap the work item body in try/catch to handle exceptions within the thread pool thread
  • Prefer Task.Run() over QueueUserWorkItem because it captures exceptions and supports await
  • Use logger.exception() or error callbacks to report exceptions from background work
  • AppDomain.UnhandledException is a last resort for logging before process termination
  • Always capture loop variables when queuing work items in a loop
Related reading
Course
Intermediate
27 lessons
14 hours
OOD Fundamentals

Master object-oriented design from first principles, SOLID, design patterns, and classic interview problems with hands-on coding.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions
Codemia
© 2026 Codemia
Resources
Legal
Social
All Rights Reserved.