08-01-2005 07:02 PM
08-03-2005 06:02 PM
This is actually a Microsoft bug with statically loaded DLLs. There are a couple of workarounds for it, and I have included two links below to posts that address this issue:
Not found error message from LabVIEW runtime when called from VC++ with statically linked MFC
I get error 998 when calling a LabVIEW buildt DLL from MSVC++
Kind Regards,
05-31-2006 03:25 PM
I figured it out. In C++ Builder in your project\options uder advance linker you have to add your dll uder dll's to delay-load. This fixes it! Thanks for your help!
Jennifer
02-17-2012 02:16 AM
Dear JennS,
I am having the same problem, because I am not a skilled C++ user, could you use pictures demonstrating how did you solve this problem?
Thank you very much if you can help!
Best,
Matt
05-10-2016 09:23 AM
The NI suggestions don't do a very good job of addressing this. For example with delayed DLL loading it just means that the Labview System 998 Error appears later after the program starts running, as does using dynamic DLL loading when the C/C++ DLL is used. The real issue here is that the C/C++ DLL generated by labview has trouble linking to the Labview Runtime Framework when used in conjunction with some operating systems and programs. For example our program that makes use of a Labview-created C/C++ DLL loads fine with Windows XP, but in Windows Seven Professional (32-bit or 64-bit) it generates the Labview System 998 Error, in which it declares that it can't load the Labview Runtime 2011 DLL (the path shown in the error message has two backslashes at the end, as shown in the attachment). Since NI support says that this is Microsoft problem I've reported this to a Microsoft support community, however Microsoft has shown no interest in supporting this problem. At present the System 998 error that occurs when using the Labview- generated C/C++ DLL, Labview Runtime Engine 2011, Windows Seven and our program remains a problem that has been going on for two years.