LabVIEW
DLL access violation - unless caller's FP is open.
Solved!
tyk has already explained it to you. Basically you can't just go and create renamed copies of DLLs to manage multiple resources unless the DLL is specifically written to do so. But it would usually be more straightforward for a DLL developer to actually write the DLL in such a way that it can access multiple devices at the same time by implementing a session based device handling where the user passes a refnum or handle of some sort from function to function and the DLL manages all the information including the device state to communicate with a particular device.
If the programmer found this to cumbersome he most likely didn't care either about making sure that two different instances of the DLL would not stomp on each others feet in some way.
And managed (.Net) or unmanaged doesn't really matter in this case, both could be written in such a way that they stomp on each other in some ways, for instance by accessing a secondary low level driver library that does not protect the global communication resource (bus, interface) in a proper way with locking.
That it doesn't crash when you have the front panel open is most likely a red herring. It still somewhere somehow corrupts memory but not memory that is crucial to LabVIEWs operation at that time. By opening the front panel LabVIEW needs to allocate more memory to manage all the front panel resources and such and that changes the actual memory layout of the whole process significantly enough that your misbehaving DLL stomps somewhere into memory where it doesn't immediately lead to a crash. It still will eventually crash somewhere, for instance when you try to close the front panel or maybe when you try to close LabVIEW itself and it tries to clean up everything and stumbles over corrupted memory pointers that your DLL caused.
I hoped the header files wouldn't be necessary in order to identify "resource" related syntax with the potential to "stomp" on neighboring process memory. "myVendor.h" does #define the initial DAQ buffer-size constant, but DAQ buffer is reallocated later, prior to DAQ, based on finite-DAQ size.
Yes - the "ID" parameter allows the DLL to identify, and communicate with, a specific "drive". I created two EXEs - one for each DLL/copy (each communicating with a different "ID") - they run in parallel without errors and without interfering with each other. This ID mechanism can even work when the two copies of the DLL are loaded by LabVIEW IDE. Today the two DLLs ran in parallel for about 4 hours without error. The application terminated normally, but the access-error appeared on restart - even with non-reentrant FP opened/hidden (1st time).
Unfortunately, obtaining help/information from the "external party" is not convenient.
It seems it's time to start "carving out" a test case!
The code as is shown is pretty terrible in terms of contained localness of resources. It basically starts up a background thread that communicates with the device and then puts everything into global variables to be picked up by the functions that you call from the application with some events thrown in for synchronization between the two. Analyzing where the possible conflict could come from is a major headache that nobody will want to do for free. There is also a chance that the actual conflict is happening in how the USB interface is accessed though it seems to be able to handle two isolated processes accessing it at the same time.
Your results are typical for a memory corruption bug. It seems to work sometimes but simply restarting your LabVIEW system or your computer changes the actual memory layout enough to cause the corruption to happen in a different and more or less serious location. I hate to say it but if the hardware device is designed as the driver code you showed, it would be nothing more than crap.
Well, the DLL looks really like a mix mash of styles. There are the two low level functions getDescriptor() and SendCommand() which look mostly like a copy past job from one of the Microsoft DDK samples and then the whole shenanigan around it which looks like from someone used to write low level embedded software in a C like language without quite all the features that real C has.
if I would be tasked to make this work I would throw away everything in that C code except the low level communication routines like SendCommand(), ConnectDrive() (and because ConnectDrive() uses it also getDesriptor()) and then write a proper session based wrapper around it so that a single DLL can handle multiple devices at the same time.
Such a DLL would take maybe 1 or 2 days to develop for me. The nice thing in this respect is that it could also be done all in LabVIEW with just the above mentioned 3 functions implemented with minor modifications in a DLL. Then write a LabVIEW class that maintains all the necessary data variables to drive these function in the class private data. It wouldn't be really less work but for someone not so inclined with C programming it would still be significantly easier.
Trying to debug this monster with multiple renamed DLLs in memory is something that easily takes a lot more time than that and still is hard to proof that it actually works reliable. Not crashing your app is absolutely no proof that everything is right!!
And I'm pretty sure the DLL is doing something wrong. With all those global variables accessed by your API calls and at the same time the background acquisition thread without much of a serialization through semaphores or something similar, this is bound to create race conditions at some point which can result in crashes very easily.
I would love to tackle this but I don't have any hardware to test it nor can I do this amount of work for just good karma alone.
