COM object that has been seperated from its uderlying RCW cannot be used

[ATE_Dude_22]

What exactly does this error mean?

I receive this error when I perform "Unload All Modules" from the sequence editor using TestStand 4.2.1.83 development system, which is part of NI Developer Suite 2010 DS1.

It causes TestStand to crash citing that error, and then a secondary error cites corrupted memory.

[dug9000]

Most likely you are incorrectly releasing a COM reference too many times or unnecessarily in some place in your code causing a TestStand object to get prematurely destroyed before it's done being used. Or perhaps you are calling Marshal.ReleaseComObject() or Marshal.FinalReleaseComObject() on something you should not be.

Probably the best approach to figure out the code that's causing the problem is to figure out what the minimum set of your changes, code being called, etc. is required for the problem to occur, then look carefully at the code involved to make sure you aren't releasing references the code doesn't actually own.

Hope this helps,

-Doug

[ATE_Dude_22]

Thanks Doug.

Im assuming that is how TestStand creates the RCW for the vi being executed, and would also then assume TestStand would release it when the vi completes its execution? Is this a bug in how TestStand releases its objects?

[ATE_Dude_22]

Here is a capture of my sequence editor, where I have a alert from TestStand telling me the parameter specified doesn't match the sequence parameters (specified in the vi prototype as a string not a number), but this version of TestStand allows it to execute without needing to clear the error.

Do you think this may have anything to do with the error I am seeing?

[dug9000]

---

@ATE_Dude_22 wrote:

Thanks Doug.

Im assuming that is how TestStand creates the RCW for the vi being executed, and would also then assume TestStand would release it when the vi completes its execution? Is this a bug in how TestStand releases its objects?

---

An RCW (runtime callable wrapper) is a Microsoft .NET thing created by the .NET framework to wrap a COM object so that it can be called from .NET. There is no known bug in TestStand that would cause such an error. Most likely it is specific to the code you are running from TestStand.

Are you using the .NET adapter? What kind of code modules are you using?

[dug9000]

---

@ATE_Dude_22 wrote:

Here is a capture of my sequence editor, where I have a alert from TestStand telling me the parameter specified doesn't match the sequence parameters (specified in the vi prototype as a string not a number), but this version of TestStand allows it to execute without needing to clear the error.

Do you think this may have anything to do with the error I am seeing?

---

Probably not. Sequence calls support mismatched parameters, what happens is that the callee gets whatever is passed to it, if that's not what it's expecting, then you might get a type mismatch error if type checking is enabled, if not then it's up to the sequence what it tries to do with the parameter for what happens next.

Most likely the bug is in one of the code modules you are calling, probably a vi or dll is not properly maintaining a reference count somewhere or is corrupting memory and only indirectly causing the error. If most of your code is in labview, one thing to look out for is incorrectly specified calls to dlls from LabVIEW. If a call to a dll is incorrectly specified, either from LabVIEW or TestStand that can very easily lead to memory corruption and random errors later on in the code.

I'd recommend trying to either debug and see where it's failing, if it's always failing in the same place. Or try to eliminate possibilities and reduce the called code to the minimum code required to reproduce the problem and then look for bugs in that code (paying special attention to the possibility of incorrectly specified dll calls and/or perhaps incorrectly maintained reference counts on COM objects).

Another idea, to see if the problem is memory corruption caused by a vi, is to run all of your labview vis using the development environment (labview adapter setting), if so, any memory corruption would be in the labview process and not the main teststand process and should not bring down teststand.

-Doug

[ATE_Dude_22]

The vi being called by TestStand by itself runs without problem, does not crash, etc....

Does the version of TestStand I am using (4.2.1.83) create crash logs that you know of? I can't find anything that makes me think it does, and am considering upgrading the a newer version to see if solves the problem??

Thoughts?

[dug9000]

---

@ATE_Dude_22 wrote:

The vi being called by TestStand by itself runs without problem, does not crash, etc....

Does the version of TestStand I am using (4.2.1.83) create crash logs that you know of? I can't find anything that makes me think it does, and am considering upgrading the a newer version to see if solves the problem??

Thoughts?

---

TestStand does not create crash logs.

Memory corruption often doesn't cause an error where the bug is, but rather later on when the thing whose memory was overwritten gets accessed or used.

Do you only use labview modules? What is the minimum required to reproduce the problem? Does it happen if you just run the vi and do unload all modules? Does it happen if you don't run the vi and do unload all modules?

You could certainly try a newer version of TestStand, especially if you are using the .NET adapter since the .NET adapter was drastically improved in TestStand 2010 (4.5), but it's possible the problem has nothing to do with TestStand directly and is rather caused by some incorrect code in a code module.

-Doug

[ATE_Dude_22]

Yeah, all the routines are written in LabVIEW (2009 SP1).

When I first saw it, I would have swore that there was a repetitive pattern in which I could cause the crash to occur, but the harder I looked at it, that became untrue. The crash only happens when I unload the modules from TestStand, but it does not happen everytime, nor after any certain number of executions that I have come across so far.

One thing I am really not understanding is why these LabVIEW routines appear to be being left in their "run-time" state after the TestStand execution completes. I have other ATE's, where TestStand calls the vi, and after the execution completes the vi's are returned to there "development" state. Especially since there are no "special" VI properties being in the execution category??

[dug9000]

TestStand keeps VIs in their reserved state for as long as they are loaded (there is a setting to change this in the adapter configuration dialog but this is the default). This is for performance and to keep references alive that the vi might have opened. If you change the load/unload option on a step you can change when the unloading happens. Since the problem you mentioned is not reliably reproducible it is likely either a timing (i.e. race condition) issue, or a memory corruption issue. Memory corruption can be particularly difficult to track down because the errors it causes usually have nothing to do with the place in the code where the memory corruption is actually occuring. In LabVIEW code, the most common place were memory corruption can occur is when a vi makes a call into a dll and the parameters are not specified correctly or not used correcting in the dll's code. Another possibility more closely related to COM would be if all of a COM object's references were released/closed prematurely and some code still tried to use the COM object after it was already deleted. Ideally, if you can get the problem to happen reliably and reduce the amount of code involved for it to happen, you can then examine the code involved carefully and determine the cause. It wouldn't hurt to try a newer version of TestStand and/or LabVIEW if you can, but there are no known issues I am aware of that would cause this error. It's more likely that the issue is being caused by a code module in your system which TestStand is calling.

-Doug