LabVIEW
Bug? - crash when loading DLL
Attempting to load the attached libMPSSE.dll via a Call Library Function Node will cause LabVIEW to crash.
Steps to reproduce:
1) start with a blank VI
2) drop a CLFN
3) select the DLL
4) specify any function
5) (optional) specify parameters
6) click OK
7) Watch LabVIEW briefly hang, then crash
The problem seems to be dependency related, as the solution is to copy ftd2xx.dll to SysWOW64. Now, I recognize it isn't LabVIEW's fault that the DLL as dependency issues, but it seems to me that it should do something a little more graceful than just crash.
In my case, I was opening code that already had the CLFN dropped and pointing at the dll, so it would just crash on open. Given that I had no idea what was in the VI (I didn't write it), I ended up having to generate and load a crash dump. Luckily the offending DLL appears in the call stack.
Worth noting, Dependency Walker indicates that the libMPSSE.dll has a circular dependency. Seems like it could be related, but I can't definitively say.
I can reproduce the issue in LabVIEW 2017 SP1 and 2019 (both 32-bit).
Also, this was originally reported over on LAVA (found after the fact), but I can't find any record of it being reported to NI, or posts on the NI forums: https://lavag.org/topic/19453-cr-mpssedll-labview-driver/?tab=comments#comment-121451
DLL loading is a fairly hairy part in Windows. DLLs have the possibility to do all kinds of things in the DLLMain() function on loading and Microsoft warns explicitly to not doing certain things from within this routine. For one Windows holds a loader lock during the load as it modifies certain global tables that manage all currently loaded DLLs and messing in there with trying to load other DLLs can end up into a mutual exclusion bug.
In your case it looks like the DLL programmer got smart and tries to load the FTDI DLL (despite Microsoft saying you shouldn’t) and then tries to reference a function in there without checking that tbe load succeeded. Crashes like that during such a tricky moment are serious and can undermine the entire process integrity so crashing is actually one of the better solutions.
Besides I’m pretty sure that LabVIEW couldn’t even try to get an exception handler called during this to give you the same dialog it gives when an error happens during normal Call Library Node execution since the exception handling is most likely suspended or catched in the DLL loader anyhow.
Rolf,
Thanks for taking the time to look at the DLL. Honestly, I'd be curious to know how you figured out the details of how it is loading. Any chance you could share?
Also, I can completely understand that in some cases a crash is preferable; I was just hopeful there was some way of avoiding it in cases like this because it would be very difficult for the majority of people to track down.
I usually use a Disassembler to look at DLLs when I want to see what they might be doing wrong. Interpreting assembly code isn't really trivial but it has shown me many times what was the problem.
DLLs are really outside of LabVIEWs control for the most part. They only work as good as the DLL programmer did its job. LabVIEW or really any caller of DLLs can only attempt to call the functions correctly (in the case of LabVIEW this generally requires that someone made sure the Call Library Nodes are configured fully right) and after that you are at the mercy of the DLL implementation. A bad implementation means a bad experience. Nothing that can be changed there by the caller except trying to not call the DLL where it has proven to be bad.
To fully isolate a process from a potentially bad DLL, one would have to call it out of process and that is an overhead and performance killer that nobody is willing to pay unless many human lifes depend on a process that won't crash, but if you use a PC for such an application you went basically already bad right there! 
