LabVIEW
Modified a DLL created in labview and now getting labview.lib was not called from a labview process error
Search LabVIEW like a graph! 
@dadreamer wrote:
It's rather odd that no one has mentioned that the DLL should be linked to labviewv.lib from cintools directory in order to run correct version of LabVIEW Runtime when loaded. So check your project settings and make sure it has labviewv.lib (not labview.lib) in additional dependencies field (Linker -> Input tab if you're working in MS Visual Studio). For the details on the "labview.lib vs. labviewv.lib" subject see also this thread.
That's only needed it the dll is going to do LabVIEW related things. Most dlls are in fact not linked to labviewv.lib.
Since the dll worked fine before, it seems a stretch that it's related.
Well dadreamer is partly right. The message about labview.lib not being called from a LabVIEW process is indeed caused by the load stub in the labview(v).lib link library that links any of the LabVIEW Manager functions to the correct LabVIEW kernel. This link library does late linking, meaning it only tries to resolve the manager call when it is first called rather than when the according DLL is loaded.
You need to add labview(v).lib to every Visual C DLL project that wants to call LabVIEW manager functions. Such DLLs however can only be called by a LabVIEW process as the stub in the labview(v).lib library will attempt to locate the current LabVIEW.exe process or lvrt.dll kernel to link to the according functions.
For LabVIEW created DLLs the DLL load routine should be actually instantiating a lvrt.dll context on loading, to which it later attempts to link the manager functions. For some reasons that instantiation of the lvrt.dll seems to fail so that when the actual LabVIEW function then is called and the late linking tries to resolve the manager functions to deal with LabVIEW datatypes, it can't find the according lvrt.dll and then shows this message.
Unfortunately I'm not intimate with LabVIEW created DLLs and can't say exactly how they get instantiated nor what they try to do on loading so I can't really be of much more help here. Something seems to have changed in respect to the previous created DLL. Could it be that you installed a service pack for the LabVIEW version in the meantime?
And of course, in stead of statically linking to the library, the dll can call those manager functions by dynamically linking (e.g. LoadLibrary, GetProcAddress).
wiebe@CARYA wrote:
And of course, in stead of statically linking to the library, the dll can call those manager functions by dynamically linking (e.g. LoadLibrary, GetProcAddress).
Which the labview.lib stub does. When you create a DLL and the according import library you can specify a flag to the Visual C linker that will instruct it to create the import library with the delay-linking functionality. https://msdn.microsoft.com/en-us/library/151kt790.aspx
NI uses its own load stub that does customized detection if it runs in the LabVIEW IDE (linking to labview.exe) or in the runtime environment (lvrt.dll or one of its variants) and then the C linker will create stubs for each exported function that does the necessary GetProcAddress() assembly call on first call. Once the function pointer is initialized the assembly stub will immediately jump to the target address in the function export table of the destination module.
It's in this NI load stub where the message is displayed about not being called from a LabVIEW process when the LoadLibrary() logic can't find either a LabVIEW.exe or lvrt.dll module already loaded into the process space. Chances that calling your own LoadLibrary() function to link to lvrt.dll would work if the load stub couldn't are probably pretty small, and you have the potential that it might try to link to the wrong runtime module than what the DLL load routine did instantiate if that load routine was successful.
I've used dynamic linking to avoid linking to external libraries. It's sometimes easier, for instance when not using C\C++.
Anyway, the dll we're dealing with in this thread is created in LabVIEW. So I (still) don't think including any LabVIEW libraries is the problem\solution.
As it hasn't really been possible to create CINs since about LabVIEW version 8.0 I generally just ignore mentioning of that in nowadays posts as most posters really mean Call Library Nodes anyways. But it could explain the problem indeed as an old CIN is not really prepared to deal with the situation where it is called from inside a LabVIEW generated DLL.
Well, I just found the time and did quick tests with CIN inside LV-made DLL. I compiled a primitive CIN against LV 8.5 toolchain and made two DLLs in LV 8.5 and 2011 with it and tried to call both from Delphi. Everything works fine, even when it's linked to labview.lib (without "v" at the end). If I remove 2011 RTE, the DLL code shows a pop-up about RTE missing and terminates. If I remove 8.5 RTE, the CIN code launches an installer (!), which tries to reinstall RTE (sometimes even with success). So, it is (was) okay to place CINs into LV-made DLLs, at least those compiled with the recent toolchain (4).
I did a second look at that strange CIN by TC ("NEGTHRES" it's called) and found this. It appears to be a VERY old CIN (27-28 years old, huh?). The internal field states, it was made with toolchain 1. And it doesn't export SetLVRTModule but tries to determine all addresses inside GetLVSBHeader. That is why it doesn't work as should. It just checks for GetModuleHandle(NULL) and LVRTTable symbol, no checks for lvrt.dll at all. LabVIEWFL says it's done with WATCOM C, but I doubt - I don't see clean marks of it (MZ?). A lot of ancient code still refusing to stop its work by a miracle. 
