3

I'm thinking of rewriting a brand new VB.NET application in VB 6.

The application runs under terminal services and makes heavy use of COM.

For some reason, there is random weirdness with the application -

  • Random Access Violation errors (WinDbg exception analysis points into dll's like comdlg32.dll, mscorwks)
  • Random Buffer Overflow errors (same)
  • Random errors in general - for example this line in Form.Load sometimes throws - Me.Icon = Resources.MyIcon

I have followed all possible advice concerning resources, garbage collection, disposal patterns, etc... It just doesn't seem to do any good.

I'm thinking there is hardware problems. This runs on a Win2k3 virtual machine under terminal services. The base server OS is Win2k3 with 64 GB RAM. The server has many virtual machines each running it's own "stuff" (Exchange, etc..).

Either there's hardware problems, or the .NET environment is not as easy to program against as one may think.

If the hardware were somehow verified (a entirely different story) and the application continued to behave as such would it be a feasible route to take (rewrite closer to the metal)?

I'm not a big fan of virtual machines and doubt their integrity. (Especially on huge servers.)

Edit - Thanks to all for the responses. The issue turned out to be a single .NET .DLL in my application that was not being targeted to x86 code. The COM objects are all 32 bit, the OS is 64 bit, thus my .NET application needs to be targetted to 32 bit. (This explains why my sample VB6 apps always worked. Not that I really wanted to go that route anyway.)

4

3 回答 3

1

安装 PDB 文件并使用“调试诊断工具 1.1”来监控您的应用程序，以识别是否发生泄漏。

也查看这个“分析 COM 对象注册表干扰的好工具？”

于 2009-02-10T15:23:49.010 回答
0

那么您是在其中一台虚拟机上的终端服务下运行的吗？同一个 VM 上有多少其他 TS 用户？我更担心终端服务的特殊性而不是虚拟机的特殊性。但是虚拟机上的 TS 可能会受到很大的打击。我们通常会使用单个 VM 来实现可移植性/DR 或 TS 机器的裸机。

什么 COM 对象？由于您必须通过 COM 互操作，因此您肯定会面临更多的性能问题。如果 COM 对象本身在终端服务下不礼貌......

好的，所以您在一台机器上有多个 TS 用户（现在忘记 VM）。如果这些 COM 对象表现得像他们拥有这台机器，因为一次只能登录一个用户 - BAM。例如，假设一个 COM 对象（尤其是像 Corel 或 Word 这样的巨大对象，其中 COM 对象是一个巨大子系统的接口），去读取它的一些配置文件或形状库或其他东西。通常，它是唯一一个这样做的，所以它永远不会被锁定或阻止或任何事情。现在突然之间，您有多个用户访问同一个（本地）文件。这与尝试从网络共享运行应用程序类似的问题。这几乎可以在任何假设本地机器资源可以被垄断的情况下发生。诸如配置文件、临时文件等之类的东西，

VB6 无法轻易解决此类问题，因为它是第三方子系统的内部问题。您可能会在单独的终端服务器会话中运行的第三方应用程序中看到同样的问题——这正是终端服务的早期采用者在使用多种应用程序时遇到很多困难的原因。我们是 Citrix 的重度用户，在某些早期版本中，您只是没有在 Citrix 上运行某些应用程序。根据 Citrix、Microsoft 或供应商的建议，即使是表现良好的应用程序也经常需要以特殊方式安装。

于 2009-02-10T01:35:07.467 回答
0

有没有机会用一个小应用程序重现这个问题？没有虚拟机或终端服务？

现在嫌疑人的数量实在是太大了。你可以得到一些不同方向的指点，希望你在不经意间发现问题。如果你缩小范围，这里的人可能真的可以帮助你。

如果它仍然不起作用，用VB6重写它将是一种可怕的浪费......

于 2009-02-10T12:25:34.383 回答