Run-Time Error -2147417848 (80010108)

[gdlewen]

**  Labview 7.1; Windows XP SP2; Excel 2003 w/VBA 6.4.x  **

I have created a simple VI that checks for available COM ports, and built a DLL from that VI.  I used the LV utility to make an installer with COM and Port I/O support (the latter is there for good measure.)  I am calling the DLL in a VBA application under Excel 2003, and it works fine. 

When I call the *only* function defined in the DLL--on another Windows XP machine with the same version of Excel/VBA--I get the following error message:

Run-Time Error -2147417848 (80010108)
Automation Error - The Object invoked has Disconnected from its Clients.

So far it has failed on two different systems, but has never failed on the original machine.  From what I can tell (Google), this error occurs in a variety of applications and for different reasons.  While I suspect a misplaced OCX file is the cause (again, Google), I am having a hard time figuring out if this is the case.   I am working on a detailed comparison of the file systems, but in the interim, If anyone has any ideas about this I would be very grateful.  (There must be an easier way to figure it out.)

I can attach the vi and dll if that is helpful.

Many Thanks In Advance....

[stanthetiger]

Hi gdlewen,

Have you tried using the dll on a third computer? Attaching the VI that creates the dll and the VB script that calls the function in the dll would be helpful. I would also suggest you to try posting on microsoft's MSDN forum to see if you can get any additional input.

Regards,
Stanley Hu
National Instruments
Applications Engineering
http://www.ni.com/support

[gdlewen]

Thank you, Stanley.  I have attached the VI, and the VBA code is at the end of this message.  The VBA code triggers the error when the dll i(red font) is called, but the rest of the code is there even though I do not send the VBA Form.  I have also tried this on a third PC (a laptop, and the other 2 trials used desktops)

I have a preliminary inventory of the filesystems on two computers:  one which runs the code and one which crashes.  I ran the VBA code and checked to see which OCX/DLL files were being accessed, and checked the version numbers.  One the PC which runs the code, WINNT\system32\Mscomm32.ocx and WINNT\system32\MSCOMCTL.OCX were accessed (along withthe DLL of course.)

On the PC which crashes, *two* copies of Mscomm32.ocx and MSCOMCTL.OCX were being accessed on the PC.  One set was in WINNT\system32, and one set was "not".  When I removed the copies *not* in WINNT/system32, the program still crashed with error -2147417848, etc.  I will try posting my question on the MSDN forum, as you suggest.

Again:  this runs as intended on the PC I am used to create the code, but not on two other PCs running XP/Excel2003, etc.
Thank you.



***********************
Option Explicit
Private Declare Sub FindSer1 Lib "C:\tmp\FindSer1.dll" _
        (ByVal ErrorCode As Long, _
          ByRef PortArray0 As Integer, _
          ByVal NPorts As Long, _
          ByRef PortCount As Long)

' Function Prototype in FindSer1.h
' void __stdcall FindSer1(long *ErrorCode, short PortArray[], long Nchars,
'                                        unsigned long *PortCount);

Private Sub CheckPorts_Click()
   Dim ErrorCode As Long
   Dim PortArray(127) As Integer
   Dim NPorts As Long
   Dim PortCount As Long
   Dim InpString As String
   Dim Stringout As String
   Dim i As Integer

   ErrorCode = 0
   NPorts = 128

   Call FindSer1(ByVal ErrorCode, PortArray(0), ByVal NPorts, PortCount)

   'Extract port numbers from PortArray[] and populate ListBox
   Stringout = ""
   For i = 0 To PortCount - 1
       Stringout = Stringout & VBA.Str$(PortArray(i)) & vbLf
       ListBox1.AddItem (PortArray(i))
   Next i
End Sub

Private Sub ListBox1_Click()
    Dim PortNumber As Integer
    MSComm1.CommPort = ListBox1.ListIndex + 1
    If MSComm1.PortOpen = True Then MSComm1.PortOpen = False
    MSComm1.PortOpen = True
End Sub

Private Sub OK_Click()
    '  Needed if OK clicked without selecting a port:  can't just close port when clicked
    If MSComm1.PortOpen = True Then MSComm1.PortOpen = False
    End
End Sub

[gdlewen]

I built a new DLL, in which the VISA call was removed and its outputs replaced--literally replaced--by constants.  (I ran the VI to get valid output, and then converted the indicators to constants so data types are preserved, etc.)

The revised VI now processes the "dummy" list of VISA resources and returns a list of valid COM ports.  There is no Automation error generated when this DLL is called by Excel(VBA) on two machines.  I will not check further, as I am satisfied that the VISA call is the problem.

Now my question is:  why do I see this Automation error on some machines and not on others, when I make VISA calls? Recall--I added support for serial port communications when I built the DLL.

If I need to upgrade from LV 7.1 that is OK--whatever it takes.  But I would like to understand this problem a little better.

Thanks

Geoff

[stanthetiger]

Hi Geoff,

Did you make sure that you have NI-VISA Run-time Engine and LabVIEW 7.1 Runtime Engine installed on all of the computers that are using this dll?

Regards,
Stanley Hu
National Instruments
Applications Engineering
http://www.ni.com/support

[gdlewen]

The LV Run-Time Engine is "selected"--i.e. included in the installer--but I *assumed* VISA support was being included when I checked Serial and Port I/O Support in the installer.  I will try adding the NI-VISA RT Engine explicitly.

In the meantime, how should I interpret the selection of Serial and I/O Port support in the installer?  What files are being installed?

As an aside, LV executables created with the installer tool have had no problems on the machines choking on the DLL.  I don't want to assume the run-time engines have already been installed through this process, though.  While it is good to have the LV executables, I want to be able to access the same functionality in VBA.

Thank You Very Much.

[pBerg]

Howdy gdlewen,

You might also go around checking each machine to verify that they all have the same versions of NI-VISA and the NI-VISA Runtime engine as the development machine.

If I may, I must say nicely done in replacing the VISA call from the DLL and wiring constants to its outputs in an effort to narrow the cause of the problem. As I read your additional comments, that's the idea that came to my mind as well!

[gdlewen]

Update:  Stanley Hu & pBerg suggested confirming that the same version of the NI-VISA Run-Time Engine was installed on the machines (one of which ran the VBA code + DLL, and one which did not.)  As far as I could tell, the versions are the same.  Here is where I got careless:  I could not be sure which of the various NI-VISA runtime files I found on my various PC's were critical, or in the right directories.  So I decided to install the NI-VISA Runtime Engine as part of the DLL build.

1)  I downloaded the NI-VISA Runtime Engine 4.3 from NI and extracted the installer files--these went to C:\National Instruments Dowloads by default.
2.)  Then I added the file NIVISAruntime.msi to the Application Builder as a "Support File" under the "Source Files" tab.  There may be a KnowledgeBase document which describes this process in detail but I did not uncover it.
3.)  I built my DLL again, adding support for Serial and Port IO.
4.)  Ran the installer on a new machine, and noted that the NIVISAruntime installer transferred files during the process.

Now it works:  I can call the DLL successfully from the VBA code without the Automation Error.  To confirm I was not using a version of my hacked-dll that employed constants, I uninstalled one of the many "Bluetooth COM ports created by Microsoft's BT stack", re-ran the VBA code, and confirmed the "deleted" port disappeared from the list.  So far, so good.

So I'm happy and thank Stanley and pBerg for their helpful suggestions.  I will continue to test this solution and report any issues I discover.  (Hopefull this will be the last post.)

Many many thanks.

[ONorm]

Hi,

I am getting the same error code and similar message, using Visual Studio C++ 2005, and Datasocket library from CVI 9.01

Here is the message :

"First-chance exception at 0x7c812afb in HydrolinkCore.exe: 0x80010108: The object invoked has disconnected from its clients."

The situation is that after running an application creating, opening and deleting DataSocket, when leaving the application, we get as many "First chance exception" as DataSocket created or opened.

Let say we have 10  DS, and say we add one, the first 10 one seem to remain active, and 11 new are opened or created.

My questions are,

1 - how to handle this exception?

2 - What is the proper way to close a DataSocket connection?

At the moment, I have a constructor, which initialize the DataSocket and calls DS_Open(...).

Then, when exiting the application, the destructor calls DS_DiscardObjHandle(...), set the Status to Unconnected and handle to zero.

Below are the .h and .cpp I use to handle DataSocket:

 

#pragma once

#include "stdafx.h"

#include "ansi_c.h"

#include <cvirte.h>

#include "dataskt.h"

#include "userint.h"

#include "..\Common\HydrolinkDef.h" class COpcDataSocketUpdate

{

public:

COpcDataSocketUpdate( CHAR szOpcUrl[ HYDROLINK_OPC_SERVER_URL_LEN ],

CHAR szSensorUrl[ HYDROLINK_OPC_SENSOR_NAME_LEN ],

UINT8 un8VarType);

~COpcDataSocketUpdate();

VOID UpdateDataSocket();

VirtualVarTy GetValue() {return m_VirtualVar; } ;

UINT16 GetStatus() { return m_un16SensorStatus; } ;

static VOID CVICALLBACK OurDSCallback(DSHandle dsHandle, INT Event, VOID *callbackData);

private:

DSHandle m_OpcHandle;

UINT8 m_un8VarType;

VirtualVarTy m_VirtualVar;

UINT16 m_un16SensorStatus;

DSEnum_Status m_DataSocketStatus;

};

//------------------------------------------------------------------------------

// File: OpcDataSocketUpdate.cpp

// Date: 2009-10-08

// Purpose: Update DataSocket Value.

//------------------------------------------------------------------------------

//------------------------------------------------------------------------------

// Include files

//------------------------------------------------------------------------------

#include "stdafx.h"

#include "OpcDataSocketUpdate.h"

#include "Tools\DebugTools.h"

COpcDataSocketUpdate::COpcDataSocketUpdate( const PCHAR szOpcUrl, const PCHAR szSensorUrl,

UINT8 un8VarType ) :

m_un8VarType(un8VarType)

{

// rh ne sert que pour le dbuggage

HRESULT hr = S_OK;

PCHAR szDataSocketUrl = new CHAR[ HYDROLINK_OPC_SERVER_URL_LEN + HYDROLINK_OPC_SENSOR_NAME_LEN + 1 ]; if(szDataSocketUrl != NULL)

{

sprintf_s( szDataSocketUrl,

HYDROLINK_OPC_SERVER_URL_LEN + HYDROLINK_OPC_SENSOR_NAME_LEN + 1,

"%s%s",

szOpcUrl,

szSensorUrl);

/*

// Initialisation des paramtres du DataSocket (Url, Handle, Status et VarType)

strcpy_s( szDataSocketUrl,

HYDROLINK_OPC_SERVER_URL_LEN + HYDROLINK_OPC_SENSOR_NAME_LEN + 1,

szOpcUrl );

strncat_s( szDataSocketUrl,

HYDROLINK_OPC_SERVER_URL_LEN + HYDROLINK_OPC_SENSOR_NAME_LEN + 1,

szSensorUrl, HYDROLINK_OPC_SENSOR_NAME_LEN );

*/

m_OpcHandle = 0;

m_DataSocketStatus = DSConst_Unconnected;

m_un16SensorStatus = 0;

hr = DS_Open( szDataSocketUrl, DSConst_Read, OurDSCallback, &m_DataSocketStatus, &m_OpcHandle );

/*

hr = DS_OpenEx( szDataSocketUrl,

DSConst_Read,

OurDSCallback,

&m_DataSocketStatus,

DSConst_EventModel,

2000, // 2000 ms avant timeout

&m_OpcHandle );

*/

 if( SUCCEEDED(hr) )

{

m_DataSocketStatus = DSConst_ConnectionActive;

}

// Librer le szDataSocketUrlTbl

 delete [] szDataSocketUrl;

}

else

{

m_DataSocketStatus = DSConst_Unconnected;

m_OpcHandle = 0;

}

}

COpcDataSocketUpdate::~COpcDataSocketUpdate()

{

// hr utilis pour debug

HRESULT hr = S_OK;

if(m_OpcHandle != 0)

{

hr = DS_DiscardObjHandle( m_OpcHandle );

m_OpcHandle = 0;

m_DataSocketStatus = DSConst_Unconnected;

}

}

Thanks for you advices and tips

Normand

[RavensFan]

This is an old thread.  And it is also in the LabVIEW forum.  People here don't know anything about CVI.

Try posting in the CVI forum.