因此，这是一个几乎需要整整一天才能解决的问题。想通了，如果其他用户仍然使用旧版本的软件，我会告诉我发生了什么事以及如何解决。
因此，某些列已添加到本地计算机上的TrueDBGrid。经过测试以构建产品并准备好部署后，该产品将被推到另一台机器上。在添加了所有列之后，确认所做的更改使一切正常，一切都移到了处理生产的计算机上。
这些更改包括逻辑更改，添加其他全局变量，修改dataEnviornments以及其他一些小更改。将更改推送到计算机时就是发生“内存不足”错误。此外，其他项目已修改，但不包含此问题。就编译器而言，它指出该错误来自user32.dll。多数民众赞成在发生问题。
我将添加一些其他的事项，然后再在下面发布答案。
我们仔细阅读并尝试过的事情包括验证所有我们认为可能是原因的dll是否都未注册。（部分原因是这台新生产的计算机最近已更改，并且并非产品的所有部分都已构建还了解到，根据我的理解，如果注册表中包含某个dll作为已知dll，并且当某个程序尝试通过其他程序访问它时，windows会尝试在使用该dll进行搜索之前尝试使用该已知dll。区域。
验证我们所有的路径都是正确的，并且所有dll的所有实际存在的文件都被认为是可能的问题。
验证我们有足够的内存来运行所有需要的东西。出于一个主要原因，此可能性已被删除。跟踪任务管理器的性能不应出现接近最大容量的峰值。
我们还尝试将生产机器上的项目移至我们的开发机器之一，并创建了相同的问题。通过不涉及正常过程的其他方式从我们的生产机器中获取相同的代码。两者都造成了问题。这使我们相信生产机器上的某些东西是问题的真正根源。
这一切都是昨天完成的，所以我可能错过了我们尝试做的一些事情，但是从其他研究中我们确实了解到，对于Visual Basic，它会为与错误无关的错误抛出“内存不足”错误并不少见。那个。
以下是我们解决此问题的方法。尽管我不太确定这是怎么引起问题的，以及如何再次创建它。
答案 0 :(得分：1)
我们为解决此问题所做的工作。
我认为，自从我们修改了数据环境之后，我们就知道内存和全局变量很可能不是问题，因为我们有其他应用程序使用了更多或更大的变量，而且它们都运行良好，但这是第一次仍在此处工作的某人已修改了数据环境，这是我们逐渐减少的事情清单中试图解决此问题的下一件事。
我们将数据环境和datagrid恢复到以前的状态，并破坏了它以验证其是否有效。 它的工作原理。
在此基础上，我们修改了生产构建中的数据环境，以模仿事物开发方面的工作，从而能够成功进行编译。
曾经有人认为我的导师曾经在我们的开发方拥有但现在在生产方的dll的某些级别上有所不同。这导致更改以生产无法正确处理的方式发生。
因此TLDR的数据环境更改导致了“内存不足”错误，该错误在大多数计算机上都有效，但至少在其他机器上没有。