Problems Building PPL in 2025Q3

[nottilie]

Dear community

I am used to build a PPL for usage as a plugin. This worked fine all the time till 2025Q3

Now I always get the massage that the nilvaiu.dll which is used by some daqmx calls can not be validated.

The resulting PPL is fine but I need to ignore the warning massage during the build process a few times.

I also reinstalled daqmx to be sure the dll is not modified with no success. When building an *.exe of the same vi (the only one which is in the lib for the PPL) all is fine.

The resulting message when building the PPL is 

nilvaiu.dll (nilvaiu.dll)
- This file was installed with National Instruments software and it has been modified or replaced since installation. Therefore, this file cannot be used. Reinstall the National Instruments software to reinstall the original version of the file.

Is there anyone out there who has an idea to fix this problem.

Thank you

[SpaghettiCoder]

I have the same issue. It occures each time a PPL uses DAQmx or another PPL which uses DAQmx. Very annoying.

[SpaghettiCoder]

The problem still exists. Found no way to workaround, very annoying since my buildstack now involves manually clicking away the warning in multiple steps. 

[SpaghettiCoder]

Ok, I dont exactly how I solved it, but I recently removed the 32 bit versions of LV as well as older versions. After clearing the cache and a full recompile of all involved PPLs, the issue has gone away... My guess is, that one of my dependencies had the wrong linkage to an older LV version in the cache somehow. 

[avogadro5]

I had LabVIEW 2023 Q3 and 2025 Q3 installed, both 32-bit, and I got rid of this warning by uninstalling LabVIEW 2023, which also uninstalled DAQmx support for LabVIEW, and after reinstalling DAQmx support for LabVIEW the warning was gone.

Repairing DAQmx/support packages did not help.


Never mind I still have warnings with only 1 LabVIEW installed (2025 Q3 32-bit)

[fmorandat]

Hi, got the same issue here today. Pure LV2025 64 bits, never 32 bits installed.
Found a tricky workaround.

With DAQmx functions, the PPL build warning only happens when using them in a class inside a lvlib, but not if you put them in the lvlib.

But now DAQmx is part of the version unspecific LVAddons... which use the same daqmx llbs for both LV64 AND 32 bits ?... inside no access write ProgramFiles folder.
How simple.

There's for sure a link with the cache :
- Clear the user object cache change nothing because the clear function doesn't clear the LVAddon content
- Clear LabVIEW object cache change nothing 'cause it does not contains the LVAddon part
- Delete the user cache file resets the issue once corrected ! (LV rebuild LVAddons during the first call)
- I didn't try with other LVAddons
- Does it comes because of llbs ? The 32/64bits link during LVAddons build cache ? Not enough tests ? Mystery

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA0VU0000004OyD0AU&l=fr-FR
https://www.ni.com/docs/fr-FR/bundle/labview-api-ref/page/properties-and-methods/vi-server/applicati...
https://www.ni.com/docs/fr-FR/bundle/labview/page/version-independent-add-ons.html?srsltid=AfmBOorIE...

Here's a manual reproducible workaround (magic ON) :
- In a sample method of a class in a lvlib using a simple daqmx vi
- Opens the daqmx function
- Delete the dll call node
- Undo with Ctrl-Z
- Close the vi (no save cause the code didn't change)
- Build
-> no warning during build
- Relaunch LabVIEW
- Rebuild
-> no warning during build

Ok if you use a dozen of daqmx functions, but if you use all of them...

[PhilHer · Accepted solution]

We upgraded to LV2026 Q1 64bit where the warnings disappeared, so for some you you running into the same issue this could be an option as well. Thanks for sharing the workaround and explanation @fmorandat!