Protection Fault After Communication with ActiveX Server dll

[Tomsaw]

I've got a visual basic ActiveX-dll and want to communicate with it by CVI. I've created an activex-controller (by the wizard) and it works fine by creating an instance of the object (==> I get the CAObjHandle) and releasing it. But when I set a parameter or call a method of my dll (this also works fine, too), it seems, resources are not being released correctly after my program has finished. Every time after clearing the object Handle, the CVI IDE reports a GPF. When running my application twice, my computer hangs up and even task-manager doesn't work anymore - the only possibility I have is to press the computer's reset button to regain control over the machine. What might be the reason - is it a problem caused b
y the dll (because it was created in VB) or do I have to change the procedure of releasing resources ? Are there any examples for communication between CVI and VB dlls ?

[JoeTestEngineer]

Here is a very simple example.....

#include "rdb_interface.h"
#include
#include

void main(void)
{

HRESULT Status;
CAObjHandle handle;
char * Buffer;

Status = rdb_NewInterface (NULL, 0, LOCALE_NEUTRAL, 0, &handle); // Create Server
Status = rdb_InterfaceConnect (handle, NULL,
"C:\\Program Files\\TMS\\database\\Remote TMS Database.udl"); // Connect to database
Status = rdb_InterfaceGetRecord (handle, NULL, "SELECT * FROM Software WHERE file_name = 'display.exe'", &Buffer); // Do Query
Status = rdb_InterfaceDisconnect (handle, NULL); // Disconnect from database

MessagePopup("Query Result Panel", Buffer); // Display Result

CA_DiscardObjHandle(handle); // Destroy Server
CA_FreeMemory(Buffer); // Fre
e Memory

}


Hope this helps,
Steve

[Tomsaw]

Thank you for the answer. Unfortunately it doesn't help me.

Instead of a char * I use a VARIANT for parameter transfer between my app and the dll. After the DiscardObjHandle I call VariantClear. There's one improvement : still I get the GPF, but now I can stop CVI regularly. I also call "FreeUnusedServers". Are there any other De-Inits to call, especially when using Variants ?

[JoeTestEngineer]

This is coming back to me now and you may find this interesting..... I also got a GPF because of the CVI Wizard. I corrected the wizard code manually. The example I gave you as you see below was an Active X Automation type (BSTR) as well but the CVI wizard converted it to the "char **record". The wizard I know is not bug free and I've got an open case with National Tech Support to fix their wizard. I expect it to remain open and swept under the rug until enough people complain. In any case this is what I had to do to fix the wizard code as shown in the code segment below.

You did not say you had a type libary but I guessing that is what you used in the wizard. I sent NI my type libary as well as the IDL and all they told me is that they were able to replicate the problem.

Here is a copy of the e-mail with the ticket number:

Note: Your reference number is included in the Subject field of this
message. It is very important that you do not remove or modify this
reference number, or your message may be returned to you.


H Steve,

I see the exact behavior that you described on the phone. I am working on
a resolution, but may have to escalate this issue to R&D, in which case, it
is likely that I will not have a resolution for quite some time. I will
keep you updated.


Regards,

Brian Anderson
Applications Engineer
National Instruments
http://www.ni.com/support

------------------------------------------------------------------------------

Here is the zip file....

Thanks,
Steve

-----Original Message-----
From: smccray@wideopenwest.com [mailto:smccray@wideopenwest.com]
Sent: Thursday, November 14, 2002 11:21 AM
To: McCray, Steven
Subject: Fwd: Re: (Reference#447784) Phone Support E-Mail

----- Message Forwarded on Thu, 14 Nov 2002 17:20:40 GMT
-----
From: support@ni.com
To: smccray@wideopenwest.com
Subject: Re: (Reference#447784) Phone Support E-Mail
Date: Thu, 14 Nov 2002 -1:-1:-1 +0000

Hi Steve,

Just zip up all the files and attach it to this e-mail.

Regards,
Brian Anderson
Applications Engineer
National Instruments

Note: Your reference number is included in the
Subject field of this
message. It is very important that you do not remove
or modify this
reference number, or your message may be returned to
you.
- test.zip
============================================================

Here is the wizard code that I had to modify:


HRESULT CVIFUNC rdb_InterfaceGetRecord (CAObjHandle objectHandle,
ERRORINFO *errorInfo,
const char *sqlStatement, char **record)
{
HRESULT __result;
rdb_Interface_Interface * __vtblIFacePtr = 0;
int __didAddRef;
int __errorInfoPresent = 0;
BSTR sqlStatement__AutoType = 0;
BSTR record__AutoType = 0;

__caErrChk (CA_CStringToBSTR (sqlStatement, &sqlStatement__AutoType));

// I had to comment this out for obvious reasons!

//__caErrChk (CA_CStringToBSTR (*record, &record__AutoType));


__caErrChk (CA_GetInterfaceFromObjHandle (objectHandle, &rdb_IID_Interface,
0, &__vtblIFacePtr, &__didAddRef));
__caErrChk (__vtblIFacePtr->lpVtbl->GetRecord_ (__vtblIFacePtr,
sqlStatement__AutoType,
&record__AutoType));

// This line of code I had to add.... I'm not sure what's wrong with the wizard!
CA_BSTRGetCString (record__AutoType, record);


Error:
CA_FreeBSTR (sqlStatement__AutoType);
CA_FreeBSTR (record__AutoType);
if (__vtblIFacePtr && __didAddRef)
__vtblIFacePtr->lpVtbl->Release (__vtblIFacePtr);
CA_FillErrorInfoEx (objectHandle, &rdb_IID_Interface, __result, errorInfo,
&__errorInfoPresent);
if (__errorInfoPresent)
__result = DISP_E_EXCEPTION;
return __result;
}

[bilalD]

Hello

One way to test out problems like this is to try using another enviorment (VC or VB) to test out the behavior of the control as well. Do you have a similar problem if you try to use this in an enviornment besides CVI? I tried making a similar activex VB dll and using it from CVI. It didnt seem to have any problems like you mentioned.
The CA_FreeUnusedServers() function is a direct wrapper over the COM run-time CoFreeUnusedServers() function, like most of the other functions we provide with the CVI activex library. Its always a good idea to verify this using the other languages that make use if the COM rumtime as does CVI, since it helps to narrow down the problem of whether its the problem with the control or if CVI is doing something wrong.

I hope this
helps

Bilal Durrani
NI

[Tomsaw]

Hello,

Thanks for your answer. I followed your suggestion and tested communication with my dll in a VB project. Using it in VB worked fine. But communicating in CVI always causes the known problem.

May I send you my source code and the dll ? Perhaps when you take a look at it, you see what is our mistake. I also send you the class that the dll is based on.

[bilalD]

Hello

I can have a look at it, if its something simple I can try on my machine. Email it in at support@ni.com and just add my name to the subject line. If you can send me something simple that would help me see the problem really quick, that would be awesome.

Thanks

Bilal

[dhfx]

This may be a related problem. I'm communicating (in CVI 8.5) with an Agilent N5242 PNA-X network analyzer using the Agilent-supplied type library 835x.tlb, installed by running the the file "pnaproxy.exe" supplied with the instrument, which also registers an Active-X server. I generate the driver as .c/.h files using the Active-X controller wizard. When I look at the generated C code for any wrapper function that returns a value, I notice that CVI first puts the value in a local buffer location, then tests the caller's return pointer for NULL, and if non-NULL, copies the value to the caller's location using the caller's pointer. If the function is one that returns multiple data values (e.g., a measured trace), CVI still allocates a buffer for ONE value! As a result, the returned values effectively cause a local buffer overflow, overwriting pointers and even code, ultimately causing a GPF. The fix is to edit the CVI-generated C code manually, putting the caller's pointer(s) in place of the pointer(s) to the local buffer, and deleting the code that NULL-tests the pointers before moving the data to the caller space. In effect, the data are stored in the caller's space directly by the internal library routine, skipping the NULL-pointer test.

If the wizard were smart enough to recognize type-library functions that return multiple data points, it might be possible to avoid this - possibly by testing the caller's pointers BEFORE calling the internal routine that retrieves the data. Or perhaps this should be done for ALL generated wrapper functions.

David Friedman

Sr. Principal Engr.

Symtx, Inc.

Austin, TX

[arike]

Hi Gys

Perhaps someone has a CVI driver for PNA-X Analyzer?

TX

Arik