Dll spontaneous unloading

I am using third party dll in my project. The problem is
that this dll spontaneously unloads and loads during program execution. This
makes problems with calling functions. Sometimes functions return errors.
I use LabView classes with virtual inheritance in this project. This allows me
to decide control interface (UART, SPI, GPIB ...) at run time. In other words I
have parent class say called INTERFACE and a few classes (UATR, SPI, GPIB ...)
inherited from INTERFACE. I use external dll in SPI class functions which are
called dynamically at run time if I decide to use SPI interface. So there are
no explicit dll functions calling in my code. This I think makes a problem with
spontaneously loading and unloading the dll. Am I right? What do you think? If
I am right I think I have to tell LabView not to unload this dll until program
termination. Could somebody give me a clue how I can do this? Thank you.

Alex67 wrote:
I've tried VI which calls dll function explicitly. Situation is the same. The next is a part of dll log file with my comments. They told me that process attached detached messages correspond to dll load unload. Is this normal that LV loads dll so many times? I've found in one topic of this forum that LV loads dll when a VI containing dll call is loaded. But in my case I can see a lot of "ATTACHED" massages at run time. There are also a few "DETACHED" messages at run time. Do you think this is normal LV behavior to unload dll at run time?
[25.06.2008] [15:31:23] PROCESS ATTACHED m_hwnd :: (1) 0x00000000
[25.06.2008] [15:31:24] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:31:24] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:31:25] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
LV project started
[25.06.2008] [15:31:46] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
Test VI loaded.
Starting Test VI...
[25.06.2008] [15:32:17] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:32:20] PROCESS ATTACHED m_hwnd :: (2) 0x00220378
[25.06.2008] [15:32:20] PROCESS ATTACHED m_hwnd :: (2) 0x00220378
[25.06.2008] [15:32:46] PROCESS DETACHED m_hwnd :: (3) 0x00220378
[25.06.2008] [15:33:18] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:33:30] PROCESS ATTACHED m_hwnd :: (2) 0x0030036E
[25.06.2008] [15:33:30] PROCESS ATTACHED m_hwnd :: (2) 0x0030036E
[25.06.2008] [15:33:30] PROCESS ATTACHED m_hwnd :: (2) 0x0030036E
[25.06.2008] [15:33:30] PROCESS ATTACHED m_hwnd :: (2) 0x0030036E
[25.06.2008] [15:34:23] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:36:15] PROCESS DETACHED m_hwnd :: (3) 0x0090039A
[25.06.2008] [15:37:00] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:37:12] PROCESS ATTACHED m_hwnd :: (2) 0x009B03EE
[25.06.2008] [15:37:12] PROCESS ATTACHED m_hwnd :: (2) 0x009B03EE
[25.06.2008] [15:37:12] PROCESS ATTACHED m_hwnd :: (2) 0x009B03EE
Test stoped.
[25.06.2008] [15:37:48] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:37:52] PROCESS DETACHED m_hwnd :: (3) 0x00000000
[25.06.2008] [15:37:52] PROCESS DETACHED m_hwnd :: (3) 0x00000000
[25.06.2008] [15:37:53] PROCESS DETACHED m_hwnd :: (3) 0x00000000
Test VI unloaded.
[25.06.2008] [15:38:39] PROCESS DETACHED m_hwnd :: (0) 0x00000000
LV project unloaded.
The problem is probably in the dynamic invocation of your VIs. A VI that loads a DLL has to take care to unload it when it is unloaded itself. Otherwise the DLL stays lingering in memory. So that is what LabVIEW does. As soon as a VI that loaded a DLL goes out of memory it unloads that DLL too.
Each Call Library Node in a diagram loads the DLL explicitedly when it is loaded itself into memory and unloads it when it goes out of memory. As soon as the DLL is loaded at least once the additional loads will simply increment a reference counter for that DLL and on unlodaing that reference counter gets decremented and when it reaches 0 Windows will unload the DLL from memory.
If your DLL has trouble with that since it stores resources globally between calls, then you need to make sure that at least one VI that references that DLL stays in memory for as long as that DLL is needed. You could do that by adding a VI that loads a function from that DLL to a place in your main application that is always in memory for the duration of your application. Or extend the INTERFACE class to hold on to an Initiliaze function for each possible interface that gets derived from it, or whatever.
Just have one VI that does not get unloaded whenever the SPI class decides that it is not currently needed anymore.
Rolf Kalbermatter
Message Edited by rolfk on 06-25-2008 12:16 PM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Similar Messages

COM Object DLL never unloads

Hello,
I have created a -very- basic ATL COM DLL with one ATL simple object in it.
It was generated using the default settings for a Microsoft Visual Studio 2008 ATL (DLL) project
Here is the IDL file for it:
object,
uuid(8C25269F-2F39-433B-85B3-DE91E3A9BD32),
dual,
nonextensible,
helpstring("I_AA_SimpleObject Interface"),
pointer_default(unique)
interface I_AA_SimpleObject : IDispatch{
[id(1), helpstring("method Method")] HRESULT Method(void);
uuid(FD10B1A1-3CE4-4E19-A7C6-6CD96ECB7421),
version(1.0),
helpstring("ATL_Main 1.0 Type Library")
library ATL_MainLib
importlib("stdole2.tlb");
uuid(B245EB27-C7B9-4663-AA02-E2647132B97B),
helpstring("_AA_SimpleObject Class")
coclass _AA_SimpleObject
[default] interface I_AA_SimpleObject;
Here is the .h file for the simple object
// _AA_SimpleObject.h : Declaration of the C_AA_SimpleObject
#pragma once
#include "resource.h"
// main symbols
#include "ATL_Main_i.h"
// C_AA_SimpleObject
class ATL_NO_VTABLE C_AA_SimpleObject :
public CComObjectRootEx<CComSingleThreadModel>,
public CComCoClass<C_AA_SimpleObject, &CLSID__AA_SimpleObject>,
public IDispatchImpl<I_AA_SimpleObject, &IID_I_AA_SimpleObject, &LIBID_ATL_MainLib, /*wMajor =*/ 1, /*wMinor =*/ 0>
public:
C_AA_SimpleObject(){}
DECLARE_REGISTRY_RESOURCEID(IDR__AA_SIMPLEOBJECT)
BEGIN_COM_MAP(C_AA_SimpleObject)
COM_INTERFACE_ENTRY(I_AA_SimpleObject)
COM_INTERFACE_ENTRY(IDispatch)
END_COM_MAP()
DECLARE_PROTECT_FINAL_CONSTRUCT()
HRESULT FinalConstruct(){ return S_OK; }
void FinalRelease(){}
public:
STDMETHOD(Method)(void);
OBJECT_ENTRY_AUTO(__uuidof(_AA_SimpleObject), C_AA_SimpleObject)
Here is the .cpp file for the simple object
// _AA_SimpleObject.cpp : Implementation of C_AA_SimpleObject
#include "stdafx.h"
#include "_AA_SimpleObject.h"
// C_AA_SimpleObject
STDMETHODIMP C_AA_SimpleObject::Method(void)
AFX_MANAGE_STATE(AfxGetStaticModuleState());
return S_OK;
I have also created a very simple winform C# application (Visual Studio 2008), using all defaults for project
I have added a reference to the ATL Project (above) to this winform application, then create buttons to create, call the exposed method and then
to set the object to null (hopefully to unload the DLL as well)
Here is the code for that:
ATL_MainLib._AA_SimpleObjectClass m_aa = null;
private void button_Create_Click(object sender, EventArgs e)
m_aa = new ATL_MainLib._AA_SimpleObjectClass();
private void button_Init_Click(object sender, EventArgs e)
m_aa.Method();
private void button_TearDown_Click(object sender, EventArgs e)
m_aa = null;
When I start debugging the C# application, I look at the modules window and see the "Atl_Main.dll" is NOT loaded.
When I click the create button, the DLL is loaded.
I click the Init button and I can hit the break point I set in the "Method" function of the ATL object.
When I click the TearDown button, the object is set to null and I expect the "Atl_Main.dll" to unload and all associated resources to
be freed as well... but it is not.
I have even tried using Marshal.ReleaseComObject, but the DLL still remains in memory.
private void button_TearDown_Click(object sender, EventArgs e)
int nCount = Marshal.ReleaseComObject(m_aa);
m_aa = null;
Can anybody unload my DLL?
Thanks

Hi,
Thank you for visiting the MSDN forum.
I’m afraid that it is not the correct forum about this issue, since this forum is to discuss Visual C#. I am moving your question to the moderator forum ("Where is the forum for..?"). The owner of the forum will direct you to a right forum. Thanks for your
understanding.
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

Prevent application from unloading dll

Hi
I have created an application that is made up of primarily two vi's, with one calling the other. The second vi, or the one that is called in turn calls/loads a dll. Now my problem is that before creating an application my vi's worked great since the dll did not get unloaded until labview was exited, however with the application it seems like if i close the second vi, or the one that calls/loads the dll then the dll is unloaded. Is there anyway to keep the dll in memory until the whole application is closed and not just the vi that calls the dll.
The solution I have used till now is to call the dll from both vi's but I rather not take that approach
thanks

reza_sed wrote:
Hi
I have created an application that is made up of primarily two vi's, with one calling the other. The second vi, or the one that is called in turn calls/loads a dll. Now my problem is that before creating an application my vi's worked great since the dll did not get unloaded until labview was exited, however with the application it seems like if i close the second vi, or the one that calls/loads the dll then the dll is unloaded. Is there anyway to keep the dll in memory until the whole application is closed and not just the vi that calls the dll.
The solution I have used till now is to call the dll from both vi's but I rather not take that approach
thanks
You don't need to call a DLL in order to have it in memory. As long as one VI in your VI tree has a reference to a DLL, and the according Call Library Node is not set to provide a dynamic DLL path (LabVIEW 8.2 and newer feature) that DLL stays in memory. No need to ever call that Call Luibrary Node. If another VI then gets into memory referencing the same DLL, LabVIEW will ask Windows to load that DLL too, but Windows seeing that the DLL is already loaded will only increment its internal load reference count.
So having a Call Library Node (or a subVI containing one) in your main VI will be enough to keep the DLL loaded. You can code something like where you put this SubVI in a case structure whose frame never gets executed. But do not disable that case by a diagram constant since LabVIEW will then optimize out the entire digram when you ever are going to build an application. Instead wire the case to a front panel control whose default value is set so that the frame will never be executed.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Delay unloading Acrobat dlls when using Acrobat 9

In our Java desktop application, we use Acrobat 9 to display a pdf file.
This pdf is opened in another window. When the window is closed the acrobat dlls loaded are expected to close by itself so that the corresponding javaw process can close.
The javaw process is not closing since the acrobat dlls are NOT closed automatically. It was found the dlls are unloaded after around 30 second.
When tried with Acrobat 8 it worked perfectly.
Has anyone come across the dll unload issue with Acrobat 9?
Can you suggest a solution?

Wrap the Adobe functionality in an executable.
Manage that from your main java app via Runtime.exec/ProcessBuilder.
Provide a communication interface so the two can interact.
Your main app can exit at any time. The secondary app will exit after the delay without being visible to the users.

Unload an external dll from memory

Hello friends,
we are currently trying to resolve the following problem:
A vendor supplied dll has certain problems that can probably only be solved by unloading the dll from memory. This happens naturally when the application quits. But we need to reset it at run time. Is it possible to tell windows and/or labview to remove the dll from memory, so that it is being reloaded with the next call?
Best regards
Matthias

Hello Matthias,
LabView unloads the DLL when the VI that uses this DLL is unloaded. This happens when the application quits or when you close LabView. However you could use the VI-Server technology to dynamically load the VI using the dll. This has the advantage, that you could unlaod the VI after you used it, and so the DLL would be unloaded, too. YOu can check the developer zone on www.ni.com, if you are not familiar with the VI-Server technology.
Hope this helps!
Andre

Multipanel and/or Multiple GUI DLL

Hello,
I am in the process of writing an application that will use some CVI GUI DLL's   The thought is each DLL is associated with an instrument and will have an instrument specific user interface that can be accessed through an exported function (RUNUI).   The inital problem I ran into was that each RUNUI function would call RunUserInterface() and each DLL had a callback with a QuitUserInterface() which resulted in strange behavoir ( the calling application was also written in CVI) After searching the forums i realized that I should be running each DLL's user interfaces in seperate threads each with it's own RunUserInterface() and QuitUserInterface() so i had modified my code according to what I thought would be the correct solution:
Each DLL has the following three functions along with some exported functions like init read and close and other associted callbacks for the GUI:
int __stdcall Photo1980A_RunUI (void)
     int threadFunctionId1 = 0;
    CmtScheduleThreadPoolFunction (DEFAULT_THREAD_POOL_HANDLE, ThreadFunctionPhoto, NULL, &threadFunctionId1);
    CmtWaitForThreadPoolFunctionCompletion (DEFAULT_THREAD_POOL_HANDLE, threadFunctionId1, OPT_TP_PROCESS_EVENTS_WHILE_WAITING);
    CmtReleaseThreadPoolFunctionID (DEFAULT_THREAD_POOL_HANDLE, threadFunctionId1);
        return 1;
static int CVICALLBACK ThreadFunctionPhoto (void *functionData)
    int DLLpanel;
    if ((DLLpanel = LoadPanelEx (0, "1980APhotomGUI.uir", PANEL1980A, __CVIUserHInst)) < 0) return 0;
    SetPanelPos (DLLpanel, 200, 200);
    DisplayPanel (DLLpanel);
    SetSleepPolicy (VAL_SLEEP_MORE);
    RunUserInterface ();
     /* Free resources for the UI and return success */
    DiscardPanel (DLLpanel);
    return 1;
int CVICALLBACK quitCB (int panel, int control, int event, void *callbackData, int eventData1, int eventData2)
    switch (event)
        case EVENT_COMMIT:
            HidePanel (panel);
            QuitUserInterface (0);
            break;
    return 0;
My Main application has two buttons (one for each of the two DLL's) and pressing a button calls associated RUNUI function.
So the application works fine as long as I don't try and have two DLL GUI's up at the same time. (open one and as long as it gets closed before calling the other no problems, all the callbacks work etc.)
As soon as I try and call the second RUNUI function from the main application it partially displays the panel and then goes off in the weeds and I have to abort everything. It seems to hang in the DisplayPanel() function (ie never get's to the RunUserInterface() when i'm single stepping).   So my question is if I'm approaching this the wrong way?
Other info CVI2010 Windows7 64bit
Another item is that I have seen the Multipanel example but when I try and run it I get similar behavor (ie when I select the Schedule Function button the panel pops but everything seems to lockup and I dont' see the start button ever fully display)
Any help would be much appreciated.
Regards,

Thanks for the response. I didn't include my code for the process attach and dettach but it looks very similar (right out of the example).
int __stdcall DllMain (HINSTANCE hinstDLL, DWORD fdwReason,
                       LPVOID lpvReserved)
    if (fdwReason == DLL_PROCESS_ATTACH)
         /* Place any initialization which needs to be done when the DLL */
        /* is loaded here. */
        if (InitCVIRTE (hinstDLL, 0, 0) == 0)
            return 0;
    else if (fdwReason == DLL_PROCESS_DETACH)
        /* Place any clean-up which needs to be done when the DLL */
        /* is unloaded here. */
        if (!CVIRTEHasBeenDetached ())
            CloseCVIRTE ();
    /* Return 0 to abort if initialization fails */
    return 1;
How does your DLL handle GUI callbacks and process events if you aren't running the RunUserInterface? If you call this from something other than a CVI application does it still work?
Regards,

Help! DLL's replying with strings give errors

Hi ,
I use the Call Library node to call a DLL function I wrote in C
void test (char Text[50])
strcpy(Text, "This is a test\0\n");
Next, I configured the Call Library Function as follows:
Parameter RETURN TYPE: Type = Void;
Parameter ARG1: Type = String; String format = C String Pointer;
(Which leads to Function prototype: void test(CStr arg1) )
The function executes just fine, but when I close the VI, I get an
APPLCATION ERROR! ("The instruction at '0x123456' referenced memory at
'0x123456'. The memory could not be read"). I guess this is when the DLL
is unloaded, but what am I doing wrong?
I am Using LabVIEW 5.1.1 & Win NT 4.0
Please help!
Patrick Pol
The Netherlands

Thanks Greg,
I wired a string constant containing at least 50 characters to the input of the
Library node, and that got rid of my crashing-problems.
Patrick Pol
Greg McKaskle wrote:
> I believe that your problem here is that you told the C compiler that there
> were 50 characters reserved for the function to write in. A caller of this
> function will need to allocate storage for the DLL function to scribble into,
> or this will be a possible crash/corruption.
>
> The same thing is true of LV. The caller, in this case, LV has no idea
> how much space to allocate for the DLL call. You will need to do this
> on the diagram using a constant, a control, or some other function that
> produces a string large enough to store the data into.
>
> Greg M
cKaskle

Issue using DLL / library function node

Hi All
I am using labview 8.2 / 8.0
I am writing a wrapper DLL to convert compex data types of a DLL to simpler ones for labview intefacing.
I have read the forums on all related items and could not find a solution.
I have cut my code back to basics and I am still getting error 1097 with 8.2 and a crash with 8.0
The error occurs as follows:
1) Start labview, open the vi.
2) Run vi - everything works (so far the wrapper DLL I am writing call just does a simple open handle and close handle on a driver dll).
The handle is passed back to the vi, and everything is good.
I can re-run the application numerous times and it always works
3) IF I close the vi, but not labview and re-open I get the following:
Labview 8.0 crashes on closing the vi
Labview 8.2 does not crash, but I get error 1097 if I re-open and run the vi.
So it seems like it's almost working but the issue comes on the release of the dll from one invocation of the vi to another.
I don't know what the error is, but I've tried everything I can think of! Any suggestions would be appreciated!
Note: I am not passing any arrays at the moment, but I am passing one unsigned 32 bit int pointer. I declare a constant for this in the call, so there is something for the pointer to use, and it seems to return the data ok.

Hi Kaem,
Thanks for your reply.
I have written C++ standalone programs that link to the DLL and these work fine. I have even called my wrapper DLL from a C++ program and that too works fine (just to check if the wrapper would cause issues there). I have a hunch that it is actually the DLL that my wrapper is 'wrapping' that is causing the issue, but I guess I don't know for sure.
The difference (IMHO) is that these C++ programs all run through once and then exit, so everything works fine. However if they load the DLL and unload it and try to load it again, maybe there would be an issue. I think labview is doing this.
The reason I think labview does something funny with the DLL after you exit a VI (but not labview) is because labview crashes in 8.0 when the VI is closed (8.2 is ok, but the next DLL invocation fails when the VI is reopened), so something must be happening at this point - and I think it's an ungraceful unload of the DLL.
Also, I've noticed that I cannot overwrite my wrapper DLL with a new version until I exit a VI - so labview is definitely doing something on VI close - it's releasing some lock on the DLL.
I don't use any consts in my code - sorry if I indicated that. What I have is a U32 constant in labview, and I connect that to the input of the library function node, and pass it as a pointer. And the DLL writes into this then. Are you saying that a labview constant cannot be used as an input to a function and passed as a pointer ? What should I use instead, a control?
Note: while writing - I just tried that - same error - so I don't think this is it.
I'm willing to take any and all suggestions!!
Cheers
John

Loading a DLL which is part of a JAR file

I have a C++ DLL which I can successfully load from Java using JNI when the DLL is in the same directory as my JAR file. However, for packaging reasons, I would like to bundle the DLL inside the JAR file. When I do this, I can no longer load the DLL. I've tried modifying the java.library.path property using -D on the java invocation. I've tried setting java.library.path to the current directory, and also to the JAR file which contains the DLL, but neither works. I have a platform-independent JAR file which contains my base code. I also have a Windows JAR file in which I'd like to ship the DLL. It is within the Windows JAR file that I've placed the Windows DLL. I put both JAR files in my classpath, and they both load, but I'm stuck on the DLL. I've search the forums, and it looks like someone on the WebStart forum did something like this, but he was not specific about whether the DLL was contained within the JAR file.
Here is the error:
java.lang.UnsatisfiedLinkError: no WindowsAudio in java.library.path
If all else fails, I will ship the DLL separately, but I was hoping there was a way to ship it within the JAR file.
Thanks.

>
Let me know if you figure out how to delete the dll
file from the applet once it is loaded.It is possible. I have done it but it is a bit convoluted.
The key is in having the dll loaded by a ClassLoader that can be GCed when you no longer need the dll. When the ClassLoader is GCed, the dll is unloaded from memory and then you can delete it. You can only create new ClassLoaders from signed code, but that should not be a problem because it has to be signed to load native libraries.
It basically goes something like this:
In the base ClassLoader define an interface to all the methods you need in the native code.
In create a ClassLoader that will define a class that implements the interface, and get a reference to an instance of it via Class.forName(String, boolean ClassLoader); Now you can access all the needed methods through the interface.
Load the native code via the new ClassLoader.
When you are done set all references to things loaded by the new ClassLoader to null, call System.gc() and System.runFinalization() several times to make sure it is cleaned up.
Then you can delete the native library.
As an alternative use a PhantomReference to the ClassLoader and then do the delete when the PhantomReference is enqueued. That way you don't have to call System.gc().

Lots of errors loading the C++ Coherence.dll

Hi,
I'm using the Coherence C++ interface in my project and i'm having some problems with the DLL loading. I have a plugin DLL which statically links to Coherence.DLL, I load this from an app so Coherence is being loaded consequentially in the call to LoadLibrary for my plugin. During the call I see a lot of errors:
Invalid parameter passed to C runtime function
The program seems to run ok and I can read/write the cache but when the plugin DLL is unloaded I run into an Access Violation. I can't be sure that the Access Violation is a direct result of this but it seems likely.
Is this anything anyone has seen before?
Thanks,
Jamie

This is the output from Depends when I run the app. You can see the errors as the DLL loads.
LoadLibraryA("c:\p4w\nobleja_cre_fxfwdrisk\depot\exotics\riskservices\cre\branches\cre_pb_fxfwdrisk.br\v2\project\bin\debugunittest\crecoherenceadapter.dll") called from "c:\p4w\nobleja_cre_fxfwdrisk\depot\exotics\riskservices\cre\branches\cre_pb_fxfwdrisk.br\v2\project\bin\debugunittest\CRECOMMON.DLL" at address 0x01176224 by thread 1.
Loaded "c:\p4w\nobleja_cre_fxfwdrisk\depot\exotics\riskservices\cre\branches\cre_pb_fxfwdrisk.br\v2\project\bin\debugunittest\CRECOHERENCEADAPTER.DLL" at address 0x046C0000 by thread 1. Successfully hooked module.
Loaded "c:\progra~1\oracle\coherence-cpp\lib\COHERENCE.DLL" at address 0x047B0000 by thread 1. Successfully hooked module.
Loaded "c:\winnt\system32\IMAGEHLP.DLL" at address 0x76C90000 by thread 1. Successfully hooked module.
DllMain(0x76C90000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\winnt\system32\IMAGEHLP.DLL" called by thread 1.
DllMain(0x76C90000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\winnt\system32\IMAGEHLP.DLL" returned 1 (0x1) by thread 1.
DllMain(0x047B0000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\progra~1\oracle\coherence-cpp\lib\COHERENCE.DLL" called by thread 1.
--- Removed a load of GetProcAddress calls for winsock calls.
LoadLibraryA("C:\WINNT\System32\mswsock.dll") called from "c:\winnt\system32\WS2_32.DLL" at address 0x71AB4B25 by thread 1.
LoadLibraryA("C:\WINNT\System32\mswsock.dll") returned 0x71A50000 by thread 1.
GetProcAddress(0x71A50000 [c:\winnt\system32\MSWSOCK.DLL], "NSPStartup") called from "c:\winnt\system32\WS2_32.DLL" at address 0x71AB4B3C and returned 0x71A5A830 by thread 1.
LoadLibraryA("DNSAPI.dll") called from "c:\winnt\system32\MSWSOCK.DLL" at address 0x71A5C714 by thread 1.
Loaded "c:\winnt\system32\DNSAPI.DLL" at address 0x76F20000 by thread 1. Successfully hooked module.
DllMain(0x76F20000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\winnt\system32\DNSAPI.DLL" called by thread 1.
DllMain(0x76F20000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\winnt\system32\DNSAPI.DLL" returned 1 (0x1) by thread 1.
LoadLibraryA("DNSAPI.dll") returned 0x76F20000 by thread 1.
GetProcAddress(0x76F20000 [c:\winnt\system32\DNSAPI.DLL], "DnsQueryConfigAllocEx") called from "c:\winnt\system32\MSWSOCK.DLL" at address 0x71A5C6FD and returned 0x76F27A5D by thread 1.
GetProcAddress(0x76F20000 [c:\winnt\system32\DNSAPI.DLL], "DnsApiFree") called from "c:\winnt\system32\MSWSOCK.DLL" at address 0x71A5C6FD and returned 0x76F23781 by thread 1.
GetProcAddress(0x76F20000 [c:\winnt\system32\DNSAPI.DLL], "DnsQuery_W") called from "c:\winnt\system32\MSWSOCK.DLL" at address 0x71A5C6FD and returned 0x76F22D83 by thread 1.
GetProcAddress(0x76F20000 [c:\winnt\system32\DNSAPI.DLL], "DnsRecordListFree") called from "c:\winnt\system32\MSWSOCK.DLL" at address 0x71A5C6FD and returned 0x76F25B13 by thread 1.
LoadLibraryA("C:\WINNT\System32\winrnr.dll") called from "c:\winnt\system32\WS2_32.DLL" at address 0x71AB4B25 by thread 1.
Loaded "c:\winnt\system32\WINRNR.DLL" at address 0x76FB0000 by thread 1. Successfully hooked module.
Loaded "c:\winnt\system32\WLDAP32.DLL" at address 0x76F60000 by thread 1. Successfully hooked module.
DllMain(0x76F60000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\winnt\system32\WLDAP32.DLL" called by thread 1.
DllMain(0x76F60000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\winnt\system32\WLDAP32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x76FB0000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\winnt\system32\WINRNR.DLL" called by thread 1.
DllMain(0x76FB0000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\winnt\system32\WINRNR.DLL" returned 1 (0x1) by thread 1.
LoadLibraryA("C:\WINNT\System32\winrnr.dll") returned 0x76FB0000 by thread 1.
GetProcAddress(0x76FB0000 [c:\winnt\system32\WINRNR.DLL], "NSPStartup") called from "c:\winnt\system32\WS2_32.DLL" at address 0x71AB4B3C and returned 0x76FB1688 by thread 1.
LoadLibraryA("C:\WINNT\System32\mswsock.dll") called from "c:\winnt\system32\WS2_32.DLL" at address 0x71AB4B25 by thread 1.
LoadLibraryA("C:\WINNT\System32\mswsock.dll") returned 0x71A50000 by thread 1.
GetProcAddress(0x71A50000 [c:\winnt\system32\MSWSOCK.DLL], "NSPStartup") called from "c:\winnt\system32\WS2_32.DLL" at address 0x71AB4B3C and returned 0x71A5A830 by thread 1.
LoadLibraryA("C:\WINNT\system32\ws2_32") called from "c:\progra~1\oracle\coherence-cpp\lib\COHERENCE.DLL" at address 0x0484E074 by thread 1.
LoadLibraryA("C:\WINNT\system32\ws2_32") returned 0x71AB0000 by thread 1.
GetProcAddress(0x71AB0000 [c:\winnt\system32\WS2_32.DLL], "getaddrinfo") called from "c:\progra~1\oracle\coherence-cpp\lib\COHERENCE.DLL" at address 0x0484E086 and returned 0x71AB2A6F by thread 1.
GetProcAddress(0x71AB0000 [c:\winnt\system32\WS2_32.DLL], "getaddrinfo") called from "c:\progra~1\oracle\coherence-cpp\lib\COHERENCE.DLL" at address 0x0484E0FD and returned 0x71AB2A6F by thread 1.
GetProcAddress(0x71AB0000 [c:\winnt\system32\WS2_32.DLL], "getnameinfo") called from "c:\progra~1\oracle\coherence-cpp\lib\COHERENCE.DLL" at address 0x0484E0FD and returned 0x71ABC671 by thread 1.
GetProcAddress(0x71AB0000 [c:\winnt\system32\WS2_32.DLL], "freeaddrinfo") called from "c:\progra~1\oracle\coherence-cpp\lib\COHERENCE.DLL" at address 0x0484E0FD and returned 0x71AB2B0B by thread 1.
GetProcAddress(0x76F20000 [c:\winnt\system32\DNSAPI.DLL], "DnsNameCompare_W") called from "c:\winnt\system32\MSWSOCK.DLL" at address 0x71A5C6FD and returned 0x76F2347A by thread 1.
LoadLibraryA("rasadhlp.dll") called from "c:\winnt\system32\WS2_32.DLL" at address 0x71AB4C38 by thread 1.
Loaded "c:\winnt\system32\RASADHLP.DLL" at address 0x76FC0000 by thread 1. Successfully hooked module.
DllMain(0x76FC0000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\winnt\system32\RASADHLP.DLL" called by thread 1.
DllMain(0x76FC0000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\winnt\system32\RASADHLP.DLL" returned 1 (0x1) by thread 1.
LoadLibraryA("rasadhlp.dll") returned 0x76FC0000 by thread 1.
GetProcAddress(0x76FC0000 [c:\winnt\system32\RASADHLP.DLL], "WSAttemptAutodialAddr") called from "c:\winnt\system32\WS2_32.DLL" at address 0x71AB4C4F and returned 0x76FC1AF3 by thread 1.
GetProcAddress(0x76FC0000 [c:\winnt\system32\RASADHLP.DLL], "WSAttemptAutodialName") called from "c:\winnt\system32\WS2_32.DLL" at address 0x71AB4C61 and returned 0x76FC11A0 by thread 1.
GetProcAddress(0x76FC0000 [c:\winnt\system32\RASADHLP.DLL], "WSNoteSuccessfulHostentLookup") called from "c:\winnt\system32\WS2_32.DLL" at address 0x71AB4C73 and returned 0x76FC13A0 by thread 1.
LoadLibraryA("kernel32.dll") called from "c:\progra~1\oracle\coherence-cpp\lib\COHERENCE.DLL" at address 0x04853343 by thread 1.
LoadLibraryA("kernel32.dll") returned 0x7C800000 by thread 1.
GetProcAddress(0x7C800000 [c:\winnt\system32\KERNEL32.DLL], "RtlCaptureContext") called from "c:\progra~1\oracle\coherence-cpp\lib\COHERENCE.DLL" at address 0x04853358 and returned 0x7C90331A by thread 1.
GetProcAddress(0x643D0000 [c:\p4w\nobleja_cre_fxfwdrisk\depot\exotics\riskservices\cre\branches\cre_pb_fxfwdrisk.br\v2\project\bin\debugunittest\DBGHELP.DLL], "SymGetOptions") called from "c:\winnt\system32\IMAGEHLP.DLL" at address 0x76C97368 and returned 0x64402300 by thread 1.
GetProcAddress(0x643D0000 [c:\p4w\nobleja_cre_fxfwdrisk\depot\exotics\riskservices\cre\branches\cre_pb_fxfwdrisk.br\v2\project\bin\debugunittest\DBGHELP.DLL], "SymSetOptions") called from "c:\winnt\system32\IMAGEHLP.DLL" at address 0x76C97368 and returned 0x64402110 by thread 1.
GetProcAddress(0x643D0000 [c:\p4w\nobleja_cre_fxfwdrisk\depot\exotics\riskservices\cre\branches\cre_pb_fxfwdrisk.br\v2\project\bin\debugunittest\DBGHELP.DLL], "SymInitialize") called from "c:\winnt\system32\IMAGEHLP.DLL" at address 0x76C97368 and returned 0x644016C0 by thread 1.
LoadLibraryA("kernel32.dll") called from "c:\p4w\nobleja_cre_fxfwdrisk\depot\exotics\riskservices\cre\branches\cre_pb_fxfwdrisk.br\v2\project\bin\debugunittest\DBGHELP.DLL" at address 0x6444E39C by thread 1.
LoadLibraryA("kernel32.dll") returned 0x7C800000 by thread 1.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
DllMain(0x047B0000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\progra~1\oracle\coherence-cpp\lib\COHERENCE.DLL" returned 1 (0x1) by thread 1.
DllMain(0x046C0000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\p4w\nobleja_cre_fxfwdrisk\depot\exotics\riskservices\cre\branches\cre_pb_fxfwdrisk.br\v2\project\bin\debugunittest\CRECOHERENCEADAPTER.DLL" called by thread 1.
DllMain(0x046C0000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\p4w\nobleja_cre_fxfwdrisk\depot\exotics\riskservices\cre\branches\cre_pb_fxfwdrisk.br\v2\project\bin\debugunittest\CRECOHERENCEADAPTER.DLL" returned 1 (0x1) by thread 1.
LoadLibraryA("c:\p4w\nobleja_cre_fxfwdrisk\depot\exotics\riskservices\cre\branches\cre_pb_fxfwdrisk.br\v2\project\bin\debugunittest\crecoherenceadapter.dll") returned 0x046C0000 by thread 1.

Calling a DLL in TestStand by reference

All,
I have developed a DLL that control's a USB based power supply. The dll call works from TestStand 4.1 most of the time. What I believe is happening is that each time I call the dll in my Main sequence file AS WELL AS other sequence files, that multiple instances of the dll are loaded.
Part of the init of the power supply is to pass back a SESSION number, which is used in subsequent calls to the dll. I store it as a Global variable in TestStand and pass it around to what ever sequence needs it.
How can I load the DLL at the start of the sequence and PASS a reference (Handle) to all additional calls to the dll?
thanks in advance
Carmine
Solved!
Go to Solution.

I checked and found that I had a release and debug version that were both beig called. That is now corrected. (Thanks)
Program still has the problem.
The "proper dll" is called from my first sequence, but called again in other sequences that are in separate files. As you suggested I looked at the load and unload options> I am not seeing an option that keeps the dll from unloading when the sub sequence file finishes and exits.
Program Architecture is as follows:
"Main File.seq" calls a "Child1.seq" to init a power supply and passes back a HANDLE, Now "Main File.seq" AND "Child2.seq" make calls to the Power Supply using the HANDLE.
Any additional help is welcome.
Thanks in advance

What causes inconsistent error: Error loading "mydll.dll" Invalid access to memory location.

I have a set of sample code vis which are wrappers around an external dll using the call library function nodes. These work in all versions of LabVIEW from 6.1 to 8.2. In version 8 and 8.2, there is an inconsistent error which appears after a vi is opened, run successfully, closed and then re-opened some time later - all without closing LabVIEW. The error is reported without an error number as 'Error loading "myDll.dll". Invalid access to memory location.' If LabVIEW is closed, reopened and the vi loaded again and run, it works fine. The same error occurs if a second vi calling the same .dll is loaded and run after the first is successful.
Since the vi works just fine the first time it is opened, why does this error occur the second time? What do I have to change so that I don't have to close LabVIEW every time I want to run a different VI?
Thanks in advance.
Mike.

Mea culpa. We have found a fix for this. It relates to our dll structure. We create a message pump in the dll associated with a hidden window. When the dll is initialized, the window is registered with the operating system. When the dll is unloaded, the window is closed but we weren't de-registering it. This caused the problem the second time the dll was loaded. By de-registering when the dll is unloaded, the problem has been solved.
Mike.

Make current values default in dll

Hello,
I build a dll in LV7.1. There is a function (.VI), where I have to open a reference of another VI, modify its default values on somel controls, then somehow save and close the reference.
This means, that if I use another function of my dll, which function needs those modified values, the new values are used. Is there any way to do it?
I tried to use the invoke node "Set Control Value" on a static VI reference of the VI. The changes are made on the controls, but the lifetime of my changes ends, if the dll is unloaded. Then I have to do the changes again.
I know, that a dll cannot be saved through a function of it, with new values. But what is the solution? Globals in the dll?
regards
Mitulatbati

Well, the idea would be to read/write the file only once.... So you would create an FGV/AE to read the settings at the call of the first function of the dll, keep the values until the last call will use the FGV/AE to write the settings back to file.
This change could possibly require a certain "setup" and "shutdown" routine in your dll which must be called from outside when using the dll. And it for certain creates issues if the dll is used without proper usage of those functions.
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Create a continuous data stream from C++, and read it in LabView

Hello all.
I'm working on a project which involves connecting to a motion tracker and reading position and orientation data from it in realtime. The code to get the data is in c++, so I decided that the best way to do this would be to create a c++ DLL file which contains all the necessary functions to first connect to the device and read the data from it, and use the Call Library Function node to feed this data into Labview.
I'm having trouble though, since ideally I would like a continuous stream of data from the c++ code into Labview, and I'm not sure how to achieve this. Putting the call library function node in a while loop seems like an obvious solution, but if I do it this way I would have to reconnect to the device every time I get the data, which is quite a bit too slow.
So my question is, if I created c++ function which created a data stream, could I read this into Labview without having to continually call a function? I'd prefer to only have to call a function once, and then read the data stream until a stop command is given.
I'm using Labview 2010, version 10.0.
Apologies if the question is poorly phrased, many thanks for your help.
Dave
Solved!
Go to Solution.

dr8086 wrote:
This method sounds like an excellent suggestion, but I do have a few questions where I dont think I've understood fully.
From what I understand the basic premise is to use one call library function node to access a DLL which creates an instance of the device object, and passes a pointer too it into labview. Then a seperate call library function node would pass this pointer to another DLL which could access the device object, update it and read the data. This part could be in a while loop and carry on reading the data until a stop command is given.
That's it. I'm including some skeleton code as an example. I'm also including the code because I don't know how much you have experience with multi threading, so I'm showing how you'd have to use critical sections to guard the interactions between threads so that they don't lead to issues.
// exported function to access the devices
extern "C" __declspec(dllexport) int __stdcall init(uintptr_t *ptrOut)
*ptrOut= (uintptr_t)new CDevice();
return 0;
extern "C" __declspec(dllexport) int __stdcall get_data(uintptr_t ptr, double vals[], int size)
return ((CDevice*)ptr)->get_data(vals, size);
extern "C" __declspec(dllexport) int __stdcall close(uintptr_t ptr, double last_vals[], int size)
int r= ((CDevice*)ptr)->close();
((CDevice*)ptr)->get_data(last_vals, size);
delete (CDevice*)ptr;
return r;
// h file
// Represents a device
class CDevice
public:
virtual ~CDevice();
int init();
int get_data(double vals[], int size);
int close();
// only called by new thread
int ThreadProc();
private:
CRITICAL_SECTION rBufferSafe; // Needed for thread saftey
vhtTrackerEmulator *tracker;
HANDLE hThread;
double buffer[500];
int buffer_used;
bool done; // this HAS to be protected by critical section since 2 threads access it. Use a get/set method with critical sections inside
//cpp file
DWORD WINAPI DeviceProc(LPVOID lpParam)
((CDevice*)lpParam)->ThreadProc(); // Call the function to do the work
return 0;
CDevice::~CDevice()
DeleteCriticalSection(&rBufferSafe);
int CDevice::init()
tracker = new vhtTrackerEmulator();
InitializeCriticalSection(&rBufferSafe);
buffer_used= 0;
done= false;
hThread = CreateThread(NULL, 0, DeviceProc, this, 0, NULL); // this thread will now be saving data to an internal buffer
return 0;
int CDevice::get_data(double vals[], int size)
EnterCriticalSection(&rBufferSafe);
if (vals) // provides a way to get the current used buffer size
memcpy(vals, buffer, min(size, buffer_used));
int len= min(size, buffer_used);
buffer_used= 0; // Whatever wasn't read is erased
} else // just return the buffer size
int len= buffer_used;
LeaveCriticalSection(&rBufferSafe);
return len;
int CDevice::close()
done= true;
WaitForSingleObject(hThread, INFINITE); // handle timeouts etc.
delete tracker;
tracker= NULL;
return 0;
int CDevice::ThreadProc()
while (!bdone)
tracker->update();
EnterCriticalSection(&rBufferSafe);
if (buffer_used<500)
buffer[buffer_used++]= tracker->getRawData(0);
LeaveCriticalSection(&rBufferSafe);
Sleep(100);
return 0;
dr8086 wrote:
My main concern is that the object may go out of memory or be deallocated, since it wouldnt be held in any namespace or anything.
Since you create the object with new, the object won't expire until either the dll is unloaded or the process (LabVIEW) closes. So the object will stay valid between dll calls provided LabVIEW didn't unload the dll (which it does if the VIs are closed). When that happens, I'm not exactly sure what happens to live objects (i.e. if you forgot to call close), I imagine the system reclaims the memory but the device might still be open.
What I do to make sure that everything gets closed when the dll unloads before I could call close and delete the object is to everytime I create a new object in the dll I add it to a list, when the dll unloads, if the object is still on the list I delete it.
dr8086 wrote:
I also have a more general programming question about the purpose of the buffer. Would the buffer basically be a big table of position values, which are stored until they can be read into the rest of the VI?
Yes, see the example code.
However, depending on the frequency with which you need to collect data from the device you might not need this buffer at all. I.e. if you collect a sample about every 100ms then you could remove all threading and buffer related functions and instead read the data from the read function itself like this:
double CDevice::get_data()
tracker->update();
return tracker->getRawData(0);
Because you'd only need a buffer and a seperate thread if you collect data at a high frequency and you cannot lose any data.
Matt

Autoplay and stop in flashbuilder

I created a small portfoliogallery in catalyst which I know brought into flashbuilder, the problem is that I got it to autoplay but not to stop so I figured I could do all of it in flashbuilder with actionscript.
Anyone now any code to use for Autoplay and then also how to make it stop??

If you post a code sample that shows the problem, I might be better able to determine the cause. At any rate, if you are already calling WaitForSingleObject on the thread handle after signalling the thread to exit in some way then there might be some other cause, however the fact that a crash occurs immediately after the dll is unloaded makes me think the thread might still be running (a crash after unload is exactly what would happen in this case). Another possibility is C++ objects at global scope. C++ objects at global scope have their destructors called during process detach. If you have objects declared at global scope you might want to take a look at what they do in their destructors. It's best to avoid declaring objects at global scope in a dll because what can be done in their constructors and destructors is limited the same as what can be done in dllmain.
Hope this helps,
-Doug

Dll spontaneous unloading

Similar Messages

Maybe you are looking for