我正在考虑在VB 6中重写一个全新的VB.NET应用程序。
应用程序在终端服务下运行，并大量使用COM。
由于某种原因，应用程序存在随机的怪异 -
我已经遵循了有关资源，垃圾收集，处置模式等所有可能的建议......它似乎没有任何好处。
我认为存在硬件问题。它在终端服务下的Win2k3虚拟机上运行。基本服务器操作系统是带有64 GB RAM的Win2k3。服务器有许多虚拟机，每个虚拟机都运行它自己的“东西”（Exchange等）。
要么存在硬件问题，要么.NET环境不像人们想象的那么容易编程。
如果硬件以某种方式得到验证（完全不同的故事）并且应用程序继续表现如此，那么它是一条可行的路径（重写更接近金属）？
我不是虚拟机的忠实粉丝，并怀疑它们的完整性。 （特别是在庞大的服务器上。）
修改 - 感谢所有回复。事实证明，我的应用程序中的单个.NET .DLL并未针对x86代码。 COM对象都是32位，操作系统是64位，因此我的.NET应用程序需要针对32位。 （这解释了为什么我的样本VB6应用程序始终有效。不是我真的想要去那条路线。）
答案 0 :(得分：1)
安装PDB文件并使用"Debug Diagnostics Tool 1.1"监控您的应用，以识别是否发生泄漏。
查看此内容"Good tools for analysing COM object registry interference?"
答案 1 :(得分：0)
所以你在其中一个虚拟机上的终端服务下运行？同一个VM上有多少其他TS用户？我更担心终端服务的特殊性而不是虚拟机特性。但VM上的TS可能会受到重创。我们通常会使用单个VM来实现TS机器的可移植性/ DR或裸机。
COM对象是什么？由于必须通过COM互操作，因此您肯定会遇到更多性能问题。如果COM对象本身在终端服务下不礼貌......
好的，所以你在一台机器上有多个TS用户（现在忘记了VM）。如果这些COM对象的行为与他们拥有的机器一样，因为一次只能有一个用户登录--BAM。例如，假设一个COM对象（特别是像Corel或Word那样巨大的东西，其中COM对象是一个巨大的子系统的接口），去读取它的一些配置文件或形状库等等。通常，它是唯一一个这样做的人，所以它永远不会被锁定或阻止或任何东西。现在突然间，你有多个用户点击同一个（本地）文件。尝试从网络共享运行应用程序也是一个类似的问题。几乎任何可以垄断本地机器资源的假设都可能发生这种情况。配置文件，临时文件等等都必须假设其他用户可能在同一区域内无所事事，并且有机器/应用程序区域和用户区域进行设置。
使用VB6无法轻易解决这类问题，因为它是第三方子系统的内部问题。您可能会在单独的终端服务器会话中运行的第三方应用程序中看到相同的问题 - 这正是终端服务的早期采用者在多种应用程序中遇到很多困难的原因。我们是Citrix的重度用户，有些应用程序在某些早期版本中只是没有在Citrix上运行。即使是行为良好的应用程序也必须以特殊方式安装，具体取决于Citrix或Microsoft或供应商推荐的内容。
答案 2 :(得分：0)
是否有可能使用小型应用程序重现问题？没有虚拟机或终端服务？
目前，嫌犯人数太多了。你可以在不同的方向得到一些指示，并希望你不小心发现问题。如果你缩小范围，这里的某个人可能真的能够帮助你。
如果它仍然不起作用，那么在VB6中重写它将是一个可怕的浪费...