new System.Transactions.TransactionScope() on background thread halts program

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

One wild guess: the Microsoft Distributed Transaction Coordinator service (MSDTC) is stopped? That is the case by default on Vista, for example. Still, I would have expected an exception to be thrown, so I am not sure why you observe that behavior.

Answer 2

Firstly, anything in the Windows event log?

If nothing, you might have some luck by attaching a debugger to Visual Studio - either Visual Studio itself or NTSD (part of Debugging Tools for Windows).

If that fails, peer code review might help (a second set of eyes might notice something) or try a shotgun approach - remove bits of code systematically until you discover why this app fails when another app using TransactionScope doesn't.

Answer 3

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.