Microscope, C++ dll, and run-time error R6025

[kasiaw]

I'm working with a microscope that came with its own software development kit.  The kit allows the user to write code in C++ or Visual Basic and control the microscope through compiled application.  I'm working with LabView 8.2.  I have generated a set of C-convention dynamic link library functions that can be used to control the microscope through LabView.  Unfortunately, usage of the library, in particular motion functions, frequently throws run-time exception R6025.  The microscope moves the part as requested, but then R6025 exception is thrown and LabView terminates ungracefully.  I'm not certain how to alleviate this problem.  Any ideas?

[smercurio_fc]

What is error R6025? We don't have the microscope, or any of the documentation, so we're clueless on this aspect. Ungraceful terminations are typically memory issues, like stomping on memory that doesn't belong to you. I'd suggest looking at the C-code you wrote to see where you are messing around with memory.

[rolfk]

---

smercurio_fc wrote:
What is error R6025? We don't have the microscope, or any of the documentation, so we're clueless on this aspect. Ungraceful terminations are typically memory issues, like stomping on memory that doesn't belong to you. I'd suggest looking at the C-code you wrote to see where you are messing around with memory.

---

It could be also that the driver throws exceptions and LabVIEW has only a general exception handler around Call Library node that displays the message about some corruption that has occurred and that it recommends to close and restart the application.

If intentional exceptions are the culprit the only good way to make this work is to write a C++ wrapper DLL that handles those exceptions and exports standard C functions from the DLL that return an error code to LabVIEW instead.

[smercurio_fc]

---

rolfk wrote:

---

smercurio_fc wrote:
What is error R6025? We don't have the microscope, or any of the documentation, so we're clueless on this aspect. Ungraceful terminations are typically memory issues, like stomping on memory that doesn't belong to you. I'd suggest looking at the C-code you wrote to see where you are messing around with memory.

---

It could be also that the driver throws exceptions and LabVIEW has only a general exception handler around Call Library node that displays the message about some corruption that has occurred and that it recommends to close and restart the application.

---

Could be that too. Could be other things too. But without any information as to the microscope or the DLL, it's just a guessing game, as far as I'm concerned. 

[rolfk]

---

smercurio_fc wrote:

Could be that too. Could be other things too. But without any information as to the microscope or the DLL, it's just a guessing game, as far as I'm concerned. 

---

Fully agree and since my crystal ball to see into mysteries from far away is currently defect, we let the OP come up with much more relevant information and explain himself in much more detail 

[kasiaw]

Thank you all for responses.  The error R6025 is Pure Virtual Function Call error and I have seen it in the past whenever a pointer that pointed to null something was invoked.  SDK requires all the code to be written with pointers that point to actual microscope and its elements.  Below I show an example of a simple dynamic link library function that returns a current position of the filter casette. 

 long checkPosition(bool startDevice)

{

::CoInitialize (NULL);

ISCOPELib::IMicroscopePtr pMicroscope1;

ISCOPELib::IFilterBlockCassette *pCasette1;

long positionReport = 0; if (startDevice == TRUE)

{

if (pMicroscope1.CreateInstance(ISCOPELib::CLSID_Nikon90i) == S_OK)

{

if (pMicroscope1->get_FilterBlockCassette (&pCasette1) == S_OK)

{

positionReport = pCasette1->Position;

} else {positionReport = -1;} } else{positionReport = -1;} } else{positionReport = -1;} return positionReport;

if (pCasette1) {pCasette1->Release();}

if (pMicroscope1) {pMicroscope1.Release();}

::CoUninitialize();

}

One thing to notice here that return statement has to be followed by release statements.  If I swap code positions and put return statement after release statements, R6025 error is guaranteed.

I do not suspect that the driver is an issue at this time.  I have written a simple C++ console application that contains a correct constructor that initializes all the pointers and passes those pointers to functions.  With such architecture, the microscope works flawlessly and I am yet to get an error.   The problem with runtime errors arises when the pointer architecture is ported into a dynamic link library.

[kasiaw]

To be dilligent, I have to mention, that above library function is being declared as a C function:

extern "C" __declspec(dllexport) long checkPosition(bool startDevice)

The header file is in C++ at this time.  Would rewriting it in C make any difference in this case?

[Ray.R]

Not sure if the person has fixed the problem (probably has by now).

In case someone else sees this type of problem, it may be related to an incompatible driver (VISA, Serial).

[rolfk]

---

kasiaw wrote:

To be dilligent, I have to mention, that above library function is being declared as a C function:

extern "C" __declspec(dllexport) long checkPosition(bool startDevice)

The header file is in C++ at this time.  Would rewriting it in C make any difference in this case?

---

The extern "C" simply tells the compiler that this has to be treated as a standard C export and not a C++ export. That means mostly no name mangling.

You can't rewrite a header file as C file. The header file is included by a source file and will assume whatever C-ness the source file was invoked with. The implementation of the source file being C or C++ will usually depend in the first place if you make use of C++ libraries. In such a case there is no good way to use them from standard C, except when you talk about clean COM implementations which often do have standard C bindings too. Compiling as C++ might include some inherent exception handling which might or might not be useful, especially in conjunction with being called from an environment such as LabVIEW.

[kasiaw · Accepted solution]

Thanks, everyone, for your responses.

The problem was... the SDK.  The Relase() method that was written by the microscope manufacturer's programming group couldn't release the pointers.  At the end of the execution of each library function there was still a pointer that was holding  the memory location of microscope part.

The manufacturer of the microscope has released a new version of the SDK and now the code works.  The only change I made was replacement of pointers with objects of microscope part classes.  Now the microscope can be controlled and LabView does not complain anymore.