从论坛里下载的程序，运行时出现这个

wode答案

As a troubleshooting step, let's try setting an environmental variable.  Create the following:



MKL_DEBUG_CPU_TYPE=4



Once you've done that, restart LabVIEW and see if the behavior continues.  If that clears up the behavior, I've got a pretty good idea of what we're looking at.  If not, it'll likely require more work.  In that case, you'll probably want to open a service request to get more focused help.这个是ni官网上的采纳回答，但是我看不懂

wode答案

打包的项目库是构建的应用程序。因此，所有依赖项都被拉入生成，包括任何非系统dll。这与构建其他生成规范（如共享库或可执行文件）时发生的相同过程。在Windows中，应用程序只能从一个位置加载一次同名的DLL。如果LabVIEW.exe或生成的应用程序已将lvanlys.dll加载到内存中，则用户在加载其PPL时将收到一个加载冲突警告，这也取决于其自身的lvanlys.dll副本。不过，这并不是PPLs独有的问题。如果LabVIEW构建了依赖于lvanlys.dll的dll，则会发生相同的行为。我以lvanlys.dll为例，因为它是我调查中最常用的dll。



好消息是有办法避免这种冲突。避免此问题的最简单方法是在构建压缩库时向所有依赖项添加前缀。这将确保dll与LabVIEW附带的dll具有不同的名称。实际上，我们对使用lvanlys.dll的构建也做了同样的事情。

wode答案

如果一个项目中要有多个ppl，可以确保将它们构建到同一目录中。如果所有ppl的前缀名称相同，那么它们将共享公共依赖项。这将有助于将磁盘和内存中的项目总数保持在最低限度。下面的图片显示了一个包含3个依赖于lvanlys.dll的PPL的项目。所有这些ppl都构建在同一位置，因此它们将共享dll。它还带有前缀，因此不会与LabVIEW附带的lvanlys.dll冲突。请参阅共享依赖项ZIP文件中的示例。

wode答案

我将DLL lvanlys.DLL调用重命名为“C:\程序文件（x86）\国家仪器\LabVIEW 2014\resource\lvanlys.*”
它删除了我在依赖项中的一个lvanlys.dll。
我希望这对你们任何人都有帮助。

wode答案

我也有同样的问题，从2015年的SP1升级到2016年，当我的VI现在执行时，它给了我在RT上的错误。
似乎依赖关系是由niu AALBase.lvlib:Mean.vi和niu AALBase.lvlib:Median.vi引起的（在我的例子中），它们是在那个DLL中实现的，因此DLL试图在看起来没有实现那个函数的RT上加载ADVAPI。
编辑：
我想我发现了这个问题，以前，在生成RT构建时，有一个名为data的子文件夹是作为构建过程的一部分生成的，我曾经将构建的应用程序部署为llb，我也在交付data文件夹。
但是，如果您查看RT，系统目录中有一个lvanlys.dll，如果您将其复制（ftp）到您的PC并查看导入部分（以及大小），您可以看到labview构建过程打包的文件与数据文件夹中的文件不同，特别是可以看到，data文件夹中的一个具有advapi32依赖关系，而RT system文件夹中的一个不具有这种依赖关系。
为了解决这个问题，我从数据文件夹中删除了lvanlys.dll，这个文件夹是我在RT上用.llb部署的，现在它正在无错误地执行。
看起来RT的PE（可移植可执行文件）加载程序优先使用位于./data文件夹中的dll的本地副本，而不是系统副本（如果导入条目具有本地匹配项，则MS-Windows PE加载程序也会这样做，但清单中引入的一些新功能除外），如果找不到./data版本，则会返回到系统文件夹一。

wode答案

在构建RT可执行文件期间，不应将DLL复制到数据文件夹的分析很可能是正确的。
  lvanlys.dll以两种方式存在的原因与以下事实有关：除了最简单的dll外，现在必须构建两个不同的dll，用于Windows和用于LabVIEW RT的Pharlap ETS系统，尽管Pharlap基本上实现了与Windows兼容的加载程序。原因是，Pharlap API支持大多停留在Windows NT 4.0所提供的水平（缺少一些在RT系统上实现的功能）。如果你使用一个现代的C编译器，它只会创建一个不再在Pharlap ETS上加载的动态链接库，除非你通过循环和循环将其链接到一个定制的C运行库，这和拔掉所有牙齿一样有趣。但是，用一个旧的编译器为现代的Windows版本编译也不再是一个好主意。
   很明显，创建运行时可执行文件的生成组件在2016年发生了更改，并且由于目标上的RT系统已经提供了lvanlys.dll，因此不应将其包含在RT可执行文件的生成中。相反，它将通常用于Windows生成的lvanlys.dll复制到生成目标中。

wode答案

我想分享一些关于这个特定dll的想法。
RT构建规范不会故意部署某些库，即使它们可能包含在构建中。当使用LabVIEW开发环境进行部署时，部署会检查是否有RT系统已经使用的启动库，并从部署中删除这些库。
lvanlys.dll就是这些库之一。就像所有人提到的，RT目标上有一个版本，专门为RT编译。RT dll安装在RT OS上。生成时附带的dll是Windows版本。
如果RT构建规范是从LabVIEW项目部署的，则dll不应复制到RT目标。我在2015年、2016年和2017年的LabVIEW中对此进行了验证。在LabVIEW 2017中，dll根本不包含在生成中。
如果使用2016并手动将dll复制（如FTP）到c/ni rt/startup/data文件夹，则会看到systemfunction错误消息。不管出于什么原因，2016版本包含systemfunction036，而PharLap不支持它。它不应该阻止RT-EXE正确执行。看看这个知识库。它附带了一个可执行文件，您可以验证一个dll是否可以在PharLap中使用。如果在生成时附带的2016版dll上运行，则systemfunction036将显示为错误导入。