SBOM generation in 2026 Q3 fails due to VI in conditional disable structure and channels

[Mads]

So, having just upgraded to 2026 Q3 I wanted to test the SBOM capability and checked the generate SBOM option in an application build we have...And it fails with code 18, which then seems to be misinterpreted by LabVIEW as an error related to picture controls..:

"

Error 18 occurred at BUIP_Create_SBOM_File.vi -> AB_Build.lvclass:Write_SBOM_File.vi

Possible reason(s):

LabVIEW: (Hex 0x12) Pen does not exist.

"

Now, looking at the output from the VIPM call it seems clear that while the Application Builder is target and condition aware, the SBOM feature is not. The builder is able to see that some VIs in the dependency list are not relevant here as they are only used on a different target (RT) and have been conditionally excluded, but the SBOM feature is not, and fails due to this:

"Checking for missing files done in 0ms
error: 1 file referenced in the project could not be found on disk
- <vilib>/rtutility.llb/RT LEDs.vi (linker)"

The SBOM feature also has plenty of warnings from Channels use din this project:

"Warning: Unrecognized symbolic path token, token=<extravilib>, rel=ChannelInstances/Stream-a[.](dbl)/)Channel.vi"


Some of these things could perhaps be ignored to allow the build to suceed anyway if there is a way to manipulate the JKI VIPM CLI Command the builder is using. Then we could perhaps add an ignore missing VIs parameter...(?)

Is there a way to edit the VIPM CLI command issued by Application Builder to deal more gracefully with missing (but excluded through Cond. Disable) VIs?

The lack of target and condition awareness might cause additional issues though. So far I have not been able to investigate how the Channels-issue might affect things. Would Channels be an issue with SBOMs for now?

[Mads]

.Net calls seem to cause issues as well. I had a Browse for Folder VI in another project and this will cause the SBOM generator to complain about System.Windows.Forms...:

error: 1 file referenced in the project could not be found on disk
- C:\Program Files (x86)\National Instruments\LabVIEW 2026\user.lib\System.Windows.Forms (linker)

So two of our most important projects fail (so far) with the 2026 Q3 SBOM feature as they are.

To check if anything would pass I tried the SBOM feature on a minimum project that just had some VISA calls and a few OpenG Array functions and that went through fine...but we rarely have projects that simple 😮

[Mads]

I am just talking to myself here now, but hey, someone has to generate some content for the AIs we ask instead these days 😄

Hopefully there is a way to manipulate the parameters sent to the JKI SBOM function (a checkbox next to the SBOM option saying its OK to ignore missing VIs would be a nice GUI option here), but what would be even better is if the error feedback when doing builds were interactive.

In this case, instead of just concluding that the build failed due to a (not-actually-used) missing VI it could show a list of the issues and ask us how to deal with in. If there was a list of VIs missing during the SBOM generation it could list them with checkboxes and then we coudl say; OK - it is fine to ignore that one (as I know it is an RT only VI e.g.)...then continue the build.

FYI: The previously described issue with the Browse to folder and .Net was the only thing that blocked that given project from going through the SBOM generator so switching to a SHBrowseForFolder (shell32.dll) based solution for that worked out...The key point is that in cases where the .Net call is not as easily replacable the SBOM generator might make it a problem...

[A-T-R]

---

@Mads wrote:

Possible reason(s):

LabVIEW: (Hex 0x12) Pen does not exist.

""Checking for missing files done in 0ms
error: 1 file referenced in the project could not be found on disk
- <vilib>/rtutility.llb/RT LEDs.vi (linker)"

---

Hi all,

I'm experiencing something very similar, and I have no idea how to eliminate this. While building the SBOM, it says something is missing...but not a file...a folder. That's correct...no such folder available. But how can I find out where it's referenced? 

Any ideas?

Regards

Achim

[Mads]

Your error looks like my RT LEDs.vi issue which is also noted as a "linker". In my case that RT LED.vi is in a non-active conditional disable case...I can see it "missing" if I go through the dependencies list so perhaps you can find "System" if you search for it there in your dependencies as well. If it is related to the splash screen you could perhaps remove teh splash screen temporarily and see if the build succeeds then, just to establish that it is the source of the issue...

Hopefully someone from JKI or NI can tell us a way to at modify the SBOM call made by the application builder to add an accept missing files parameter e.g.... 😮

[cordm]

Try running from the command line:

vipm sbom MyProject.lvproj --format cyclonedx --schema-version 1.5 --output sbom.json --allow-missing-files

There is a command line reference if you need other options: https://docs.vipm.io/latest/cli/command-reference/

[A-T-R]

Thanks for this tip...unfortunately, nothing happens...

[A-T-R]

---

@Mads wrote:

.I can see it "missing" if I go through the dependencies list so perhaps you can find "System" if you search for it there in your dependencies as well. 😮

---

This helped a little bit...I found an item called "System" in the dependencies...with a VI icon but no file extension ".vi".

I assume it has something to do with the vi.lib-VI "FileVersionInfo.vi" from "C:\Program Files (x86)\National Instruments\LabVIEW 2026\vi.lib\Platform\fileVersionInfo.llb"...which calls version.dll and kernel32.dll (the latter is also in dependencies)

I could remove the complete SplashScreen-VIs including all dependent VIs for testing, but that would break the code in more than one place. Right now, I'm not sure if its worth the work.

Obviously, the SBOM generator can not work with such (OS) dependencies. It would be nice to have a correction made by NI and/or JKI

Is someone from NI or JKI monitoring this thread or can be made aware of? 

Regards

Achim

[cordm]

Hm, for me it showed at least some error messages at that point.

Scanning project done in 37.08s
error: LabVIEW VI Server is not available for LabVIEW 2025 (64-bit) on port 3363
reason: LabVIEW did not answer VI Server on port 3363 (Operation 'LabVIEW startup on TCP port 3363' timed out after 30s)
help: Open VIPM Desktop and run Verify for this LabVIEW version, then retry. If LabVIEW is already running, restart it after changing VI Server settings.

My LabVIEW was configured for a different port and also allowed multiple instances (which took too long to start).

After fixing that, it took a minute to build the NIPM package cache, but there was always some output.

Maybe adding the --verbose flag shows something interesting?

[A-T-R]

Ok...in this case, the error source was sitting in front of the screen...

I left the cmd line in the background, and forgot it...then I saw your reply and went to add "--verbose"...

I saw that after more then 14 minutes the generation process put out an error.

Now adding the parameter...then my error showed up after a little more then three seconds:

After saving the project, the generation of the SBOM was successful!

I had to search for the output for a while! Is there a parameter available to specifiy the target folder?

And the json file is small. I'm not sure what i expected what it would contain. But there's only some information about LV itself, DAQmx, vipm, JKI

In the project, I'm using also TCP/Modbus for commanding a FESTO controller (Modbus library from NI) and "raw" TCP for climate cab communication. 

Is it not intended to list those libraries in a SBOM? 

Still...some errors occured:

Skipping of NI-native SW components?!

And the Windows-native user32.dll?!

Why's that?

A.