LabVIEW为什么在存储VI时死机

有一个非常大的VI,使用了超过100子VI.它运行的很好，但当再加一些代码并保存时，LabVIEW死机了。该怎么使LabVIEW保存得快些或退出死机状态？

解答: 当创建VI时，LabVIEW为之分配内存空间和堆栈。当创建了一个非常大的，使用了很多子VI和局部变量的VI的时候，VI可用的资源开始减少。这会在修改和保存VI时产生保存异常。然而，总是有办法解决的。当想改变VI时，按以下步骤执行：

从顶层VI中隐藏子VI（顶层VI是将要修改的VI)

Note:方法之一是把客户子VI移到对LabVIEW不可见的其他文件夹下。下次打开顶层VI时，LabVIEW将搜索这些子VI。点击'stop'按钮，退出寻找子VI。顶层VI将加载，以问号代替子VI。只有顶层VI将被加载到内存中。

在顶层VI中作所需的修改，然后保存。

把子VI移到原来的位置。下次打开顶层VI时,LabVIEW将再次找到这些子VI，然后正常的加载。

LabVIEW内部错误和崩溃的初步故障排除步骤：

通过LabVIEWCrash Reporter对话框将崩溃报告发送给NI。添加任何有助于NI诊断崩溃的相关信息。

确定是否可以一致地重现崩溃。这将使故障源的诊断更加容易。如果可以重现崩溃，请尝试在知识库和NI社区中搜索类似的崩溃。包括十六进制代码以及崩溃发生时的操作。

安装最新的LabVIEW补丁。

查看LabVIEW版本的LabVIEW已知问题列表。

进一步的故障排除步骤：

尝试缩小警告的范围。减少代码量并减少用于创建崩溃的最小重现情况的硬件数量。如果可以消除与崩溃无关的部分，则更有可能找到此特定崩溃的根本原因。请参阅以下故障排除步骤以帮助实现此目的：

如果崩溃是由可执行文件发生的，请检查从LabVIEW开发环境运行VI时是否发生相同的行为。这样做可能指向运行引擎出现问题。

尝试使用禁用结构来禁用部分代码。这可以帮助缩小崩溃发生在代码中的位置。

尝试卸下所有硬件。如果仍然看到崩溃，则可以继续对软件进行故障排除。如果卸下硬件解决了崩溃问题，则可以将原因缩小到硬件。尝试使用其他类型的硬件，以查看崩溃是否特定于硬件类型。

检查在另一台计算机上是否看到相同的行为。崩溃可能与计算机环境有关。

监视内存以检查内存泄漏。

使用WinDbg对崩溃进行故障排除。如果崩溃是可重现的，则将此工具连接至LabVIEW进程，并导致崩溃再次发生。该工具可以让更深入地了解崩溃的根源。

如果使用硬件，请在程序结束时确保关闭所有内存引用。对引用的任何滥用都可能导致内存泄漏。

确保所有错误簇均已连接并受到监视。可能没有意识到之前发生了一个错误。错误编号用于指定出了什么问题，可以在“解释错误”对话框（“帮助”»“解释错误...” ）中进行搜索，以找到有关错误的说明。

如果使用的是.NETFramework或DLL，请尝试将其删除以查看崩溃是否仍然发生。可以参考dll崩溃的解决办法 。

如果只有一个VI发生崩溃，请尝试将程序框图的全部内容复制到新的VI。有时，这可以消除可能导致崩溃的损坏。

批量编译VI 。如从较早版本升级了LabVIEW，则可能有一些较旧的VI尚未更新。

崩溃也可能是由于代码中出现“Insane Object or fsane.cpp ”错误引起的。

如果要处理实时系统的问腿，请查看LabVIEW错误日志或实时系统错误日志 。

如果可执行文件发生崩溃，请确保在部署计算机上安装了所有必需的驱动程序。

添加自定义日志记录步骤 ，以获取有关崩溃可能发生位置的更多信息。

关闭防火墙，然后尝试运行项目。某些防病毒软件（例如SentielOne）包含导致LabVIEW崩溃的dll。

确保未超出框图或前面板的最大大小 。

使用LabVIEWDesktop Execution Trace Toolkit进行动态代码分析，以执行高级调试。

该问题可能与软件甚至操作系统的损坏有关。如果尝试了上述故障排除步骤，但仍无法解决，则可能需要考虑重新映像计算机。