捕获内存转储 - .NET
寻找有关当用户在终端服务下运行时捕获内存转储的方法的建议。 我尝试过将“AdPlus”与 WinDbg 一起使用，但应用程序在终端服务下运行，并且它似乎不喜欢这种组合。
这是一个 VB.NET 应用程序。
我的问题类似于 用于分析 .NET 应用程序内存转储的工具，但是需要允许应用程序在没有外部对话框的终端服务下运行。 我在安静模式下尝试了 WinDbg，但它使会话崩溃。
Looking for suggestions for a method of capturing a memory dump while a user is running under terminal services. I have tried using "AdPlus" with WinDbg but the application runs under terminal services and it doesn't seem to like that combination.
This is a VB.NET application.
My question is similar to Tool for analyzing .NET app memory dumps but needs to allow the application to run under terminal services with no external dialogs. I tried WinDbg in quiet mode, but it crashes the session.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
adplus 在终端服务下应该可以正常工作——我们经常这样使用它。 您究竟想如何使用它。
终端服务会话需要注意的一件事是会话本身是否有空闲超时。 我们经常让客户通过终端服务部分将 adplus 连接到我们的服务，然后想知道为什么该服务在一小时后就终止了。 解决方案是强制终端服务连接使用控制台会话（mstsc 命令行上的 /console）。
adplus should work fine under terminal services -- we use it that way frequently. How exactly are you trying to use it.
One thing to watch out for with terminal service sessions is if the session itself has an idle timeout. We often had customer attached adplus to our service via a terminal services section and then wonder why the service died an hour later. The solution to this was to force the terminal service connection to use the console session (/console on the command line for mstsc).
因为 adplus 从命令行运行，所以如果您注销或终端服务会话超时，脚本将停止。
可以考虑的一种可能性是使用 DebugDiag，它作为“本地系统”服务运行，因此它不依赖于登录的交互式用户会话。
您可以配置该服务以定期安排内存转储，并稍后在 DebugDiag 的另一个组件中查看/分析结果，所有这些都可以通过脚本进行自定义。
有用的链接和下载：
http://blogs.msdn.com/sukeshak/pages/ddintro .aspx
http://blogs.msdn.com/tess/archive/2009/01/23/net-hang-analyzing-debug-diag-output.aspx
http://www.microsoft.com/downloadS/details.aspx?FamilyID =28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en
Because adplus runs from the command line, if you logout or a terminal services session times-out the script will stop.
One possibility to consider is using DebugDiag, it runs as a service as “Local System” so it’s not dependent on the logged on interactive user session.
You can configure the service to schedule memory dumps periodically and view/analyse the results later in another component of DebugDiag, all customizable via scripts.
Helpful links and download:
http://blogs.msdn.com/sukeshak/pages/ddintro.aspx
http://blogs.msdn.com/tess/archive/2009/01/23/net-hang-analyzing-debug-diag-output.aspx
http://www.microsoft.com/downloadS/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en