后台线程上的 new System.Transactions.TransactionScope() 会停止程序
我有一些使用 System.Transactions.TransactionScope 的代码，创建事务范围的新实例只会停止程序。
没有异常或消息，程序只是停止，Visual Studio 返回代码编辑模式。 该过程完全消失了。 事件查看器中没有异常、消息或事件。
我有另一个使用 TransactionScope 的测试应用程序没有问题，所以它不应该是环境问题。
我只是不知道如何获取异常详细信息。 我已经打开了 Visual Studio 中“调试”->“异常”对话框中的所有“抛出”复选框，希望 VS 在抛出异常时自动中断，但事实并非如此。
谁能帮我找出程序退出的原因吗？
编辑：我刚刚发现了一些新东西。 TransactionScope 是通过 ThreadPool.QueueUserWorkItem 在后台线程上运行的方法中创建的。 如果我直接在主应用程序线程上调用该方法，这个问题就会消失。 所以现在我的问题是“在线程池线程上使用 TransactionScope 有什么问题？”。 请注意，在调用新线程之前，我没有启动事务范围，这一切都在线程池线程上运行的一个方法内。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我已经找到问题了。 它是运行我的计算机的柔软的有机组件。
ThreadPool.QueueUserWorkItem()将开始在线程池线程上工作。 这意味着后台线程。 该代码在测试控制台应用程序中运行，当然我忘记在 Main() 中添加任何内容以阻止程序在调用 ThreadPool.QueueUserWorkItem() 后退出>。 这意味着当我按 F10 进入下一行时，程序实际上已经停止，因此调试器自行关闭。我所做的就是在
Program.Main()末尾添加对Console.ReadKey()的调用来修复它，现在一切都工作得很好。 请注意，该问题与 System.Transactions.TransactionScope 或线程池线程无关。 无论我将断点放在哪一行，它都会发生。注意：
如果您认为我应该看到
ThreadAbortException，那么阅读上面链接的文章将会指出为什么没有发生这种情况。 这是直接引用：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 inMain()to stop the program exiting after it calledThreadPool.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 ofProgram.Main()and now it all works beautifully. Note that the problem had nothing to do withSystem.Transactions.TransactionScopeor 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:一种疯狂的猜测：Microsoft 分布式事务协调器服务 (MSDTC) 已停止？ 例如，Vista 上的默认情况就是这种情况。 不过，我预计会抛出异常，所以我不确定您为什么会观察到这种行为。
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.
首先，Windows 事件日志中有什么内容吗？
如果没有，您可能会运气好，将调试器附加到 Visual Studio - Visual Studio 本身或 NTSD（Windows 调试工具）。
如果失败，同行代码审查可能会有所帮助（第二双眼睛可能会注意到一些东西）或尝试猎枪方法 - 系统地删除代码片段，直到您发现为什么此应用程序会失败，而另一个使用 TransactionScope 的应用程序不会失败。
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.