Seemingly random crashes with VB.NET and COM Interop

Question

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.)

Answer 1

Install PDB files and use "Debug Diagnostics Tool 1.1" for monitoring you app, for identify were leak occurs.

View this too "Good tools for analysing COM object registry interference?"

Answer 2

Is there any chance that you can reproduce the problem with a small application? Without Virtual Machine or Terminal Services?

Right now the number of suspects is simply too big. You can get some pointers in different directions and hope that you accidentaly find the problem. If you narrow it down, someone here may really be able to help you.

Rewriting it in VB6 would be a terrible waste if it still does not work...

Answer 3

So you're running under terminal services on one of the VMs? How many other TS users on that same VM? I would worry more about terminal services peculiarites than VM peculiarities. But TS on a VM is probably taking a big hit. We typically would use a single VM for portability/DR or bare metal for TS machines.

What COM objects? You are definitely opening up for more performance problems since you have to go through COM interop. And if the COM objects themselves aren't polite under terminal services...

OK, so you've got multiple TS users on a machine (forget the VM, right now). If those COM objects are behaving like they own the machine because only one user can be logged on at a time - BAM. For instance, say a COM object (especially something enormous like Corel or Word, where the COM object is an interface to a huge subsystem), goes to read some of its configuration files or a shape library or something. Normally, it's the only one doing it, so it will never get locked or blocked or anything. Now all of a sudden, you've got more than one user hitting the same (local) file. It's a similar problem to trying to run the application off a network share. This can happen with pretty much any assumption that a local machine resource can be monopolized. Things like config files, temp files, etc., all have to assume other users might be fooling around in the same area and have machine/app areas and user areas for settings.

This kind of problem cannot easily be solved with VB6, since it's internal to the third-party subsystems. You would probably see the same problem in the third-party app running in separate terminal server sessions - and that is exactly why early adopters of terminal services had a lot of difficulties with many kinds of apps. We were heavy Citrix users, and there were apps you just didn't run on Citrix in some early versions. Even well-behaved apps often have to be installed in special ways depending on what Citrix or Microsoft or the vendor recommends.