Connor.Prior

I don't think paths are the issue here - builds from previous commits are passing with the same path lengths, and my build spec destination directory is C:\temp, so it's shorter than my repository location. I have questions about something weird I found while working on this issue - does anything about the code change when you copy it to a new location? I copied my directory to a new location to run some tests, but when I opened the project, I noticed several typedefs showing up as missing in the dependencies. They were all typedefs that I had recently deleted, but they weren't showing up as missing in the main project. In addition, when I clicked "why is this item in dependencies?" and found the offending VIs & typedefs, the dependencies were cleared as soon as I opened them, before I even resaved them to clear the changes. However, I found if I closed and re-opened the copied project the dependencies would reappear if I didn't re-save the VI the first time. The appearance of these was somewhat inconsistent, but I found the most reliable way to get them to show up was to create a fresh project, and pull in individual modules from the fresh copy of the main directory. I've cleared all such references that I can find, but the build is still failing. Does anyone know anything about why these appear, or how to reliably find them?

I did have a decent amount of broken code in diagram disable structures, but unfortunately removing them had no effect. The longest path length in my project is 136. When you say it might exceed the max length during the build, do you mean the build is the only time that limit is checked, or do you mean the paths may get longer during the build? I also have several packages in the vi.lib folder, and the longest there is 217. Does the path limit affect these the same way?

Thanks for the suggestions, but unfortunately I'm getting the same behaviour after the cache clear, and I'm not getting anything useful out of the build log either.

Hi! I work on a large (4000+ VIs, 1.6 GB repository) LabVIEW program. I've just finished working on a new feature, and all of the sudden the code won't build anymore, always failing with this error: "Error 1 occurred at An error occurred while saving the following file: C:\Program Files (x86)\National Instruments\LabVIEW 2019\vi.lib\registry\registry.llb\Registry refnum.ctl Click the link below to visit the Application Builder support page. Use the following information as a reference: Error 42 occurred at AB_Source_VI.lvclass:Close_Reference.vi -> AB_Build.lvclass:Save.vi Possible reason(s): LabVIEW: (Hex 0x2A) Generic error. Possible reason(s): LabVIEW: (Hex 0x1) An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @. ======= Command requires GPIB Controller to be Controller-In-Charge." The feature resulted in changes to several widely used typedefs, and an update to one of our core VIPM packages (one we make ourselves). The code runs fine from IDE, and nothing shows up as broken in the project. I've run mass compiles a few times, which found some broken VIs that were removed from the project but not deleted from the repository, so I removed those. It also found a few "Insane Objects", most of which I have now removed. The mass compile output gets smaller each time, but the error code on subsequent builds never changes. I've been trying to read the "LVInternalReports" that are created for each failed build, but I'm struggling to interpret some of its contents. In the lvlog.txt file of the latest build, I see several <DEBUG_OUTPUT> sections with DWarn lines that seem relevant. Here is one example: "<DEBUG_OUTPUT> 2022-09-15 1:03:56.779 PM DWarn 0xF481EB8C: error returned from SaveObjectData: 1 image {HeapClass=FPHP,UID=12,DPId=9,o=0x9db4fe00} d:\builds\penguin\labview\branches\2019\dev\source\panel\savedata.cpp(634) : DWarn 0xF481EB8C: error returned from SaveObjectData: 1 image {HeapClass=FPHP,UID=12,DPId=9,o=0x9db4fe00} minidump id: f47da8ab-45aa-4102-ba6b-3f32f5b84f42 $Id: //labview/branches/2019/dev/source/panel/savedata.cpp#4 $" Is there a way to trace what this is referring to? I assume if this refers to a particular VI it will help me track down the issue, but I don't know what these hexadecimal codes refer to. If anyone has suggestions for other ways to diagnose the build failure it would be greatly appreciated.