Question

I have some code using a System.Transactions.TransactionScope, that creating a new instance of the transaction scope simply halts the program.

There are no exceptions or messages, the program simply stops and Visual Studio returns to code editing mode. The process is completely gone. There are no exceptions, messages or events in the event viewer.

I have another test app that uses TransactionScope with no problem, so it shouldn’t be an environment issue.

I just don’t know how to get the exception detail. I’ve turned on all the “thrown” checkboxes in the Debug->Exceptions dialog within Visual Studio, hoping that VS would automatically break when the exception was thrown, but it doesn’t.

Can anyone help me get the reason for the program exiting?

EDIT: I just found something new. The TransactionScope is being created in a method running on a background thread via ThreadPool.QueueUserWorkItem. If I just call the method directly on the main application thread, this problem goes away. So now my question is “what is the problem with using TransactionScope on a threadpool thread?”. Note I’m not starting a transaction scope before invoking the new thread, it’s all within one method running on the threadpool thread.

Answer 1

I’ve found the problem. It was the squishy organic component that operates my computer.

ThreadPool.QueueUserWorkItem() will start work on a threadpool thread. Which means a background thread. The code was running in a test console application, and of course I’d forgotten to put anything in Main() to stop the program exiting after it called ThreadPool.QueueUserWorkItem(). This meant that by the time I got to pressing F10 to step to the next line, the program had actually already stopped, so the debugger closed itself.

All I did to fix it was add a call to Console.ReadKey() at the end of Program.Main() and now it all works beautifully. Note that the problem had nothing to do with System.Transactions.TransactionScope or threadpool threads. It would’ve happened no matter what line I put my breakpoint on.

Note:
If you’re thinking I should’ve seen a ThreadAbortException, then reading the article linked above will point out why that didn’t happen. Here’s a direct quote:

When the runtime stops a background
thread because the process is shutting
down, no exception is thrown in the
thread. However, when threads are
stopped because the AppDomain.Unload
method unloads the application domain,
a ThreadAbortException is thrown in
both foreground and background
threads.