LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

CVI/2017 new installer issues (customResource0009.dll not found, but is there) - suddenly showing up on LTSC and Windows Arm.

I encountered an installer error with a packaged we've been building for several years. It says:

.\source\MetaInstaller\ConfigINfo.cpp(2506): InstallerError 10007
Fatal Error. Unable to load a resource DLL.
Unable to load the custom resource file C:\Users\...path...\Volume\supportfiles\customResource0009.dll because Windows Error 126: The specified module could not be found
while attempting to load the resource DLL C:\Users\...path...\Volume\supportfiles\customResource0009.dll

The file in question is in supportfiles.

 

Originally I thought this was related to Windows Arm, but not I know it is not. This error showed up on a fresh Windows Arm system (reset PC, nothing installed) and was seen on a Windows 10 LTSC system.


We have built hundreds of installers that have worked fine, and never seen this message before.

 

Anyone else suddenly encountering it? The only thing that was changed in the Distribution Kit was advancing the version number from 1.17.90xx to 1.17.10000.

 

The installer worked fine on a Windows 10 LTSC system I have here, and my development system running Windows 11.

 

The DLL error has been reported on another LTSC system, and on my Windows Arm test running inside Parallels virtual machine on a Mac.

 

0 Kudos
Message 1 of 26
(733 Views)

Update. Installer does NOT work on the LTSC system. I did a "Reset this PC" to restore to bare Windows 10 LTSC, and get the same error.

 

0 Kudos
Message 2 of 26
(712 Views)

Some thoughts/questions:
1) So does this error occur only with new built installers, or does it also fail with previously success built installers?
2) If only with new built installers, what version of NIPM created the previous versus the newer installers?

Scott Richardson
https://testeract.com
0 Kudos
Message 4 of 26
(707 Views)

@Scott_Richardson wrote:

Some thoughts/questions:
1) So does this error occur only with new built installers, or does it also fail with previously success built installers?
2) If only with new built installers, what version of NIPM created the previous versus the newer installers?


Installing an older version, then then upgrading, appears to work. The puzzler is ... nothing changed other than updating the version number, and I also updated the Company text. Beyond version numbers, and certain firmware .hex files I add to each build, I haven't touched anything in the installer in years since first getting it going.

I have tried installing the VC redistributable, but that did not help.

 

Clearly something changed, but now I don't have any idea what to change back. 2017 hasn't had any updates I am aware of. We have the original install with some patch, which I put on my machine a year or so ago when I got it back from DELL and had to restart everything.

 

It is very puzzling. The only thing we add from the installer is the VCI runtime. Changing it to use 2020, versus 2017, does not help either.

 

And, annoyingly, the path it says is "not found" actually has the file there in that path. I wonder if some Windows update changed something?

0 Kudos
Message 5 of 26
(692 Views)

So, did the version of NIPM on the build system change, and what is the version was used to build the installer that errors? Can you share more detail on your statement "The only thing we add from the installer is the VCI runtime"?

Scott Richardson
https://testeract.com
0 Kudos
Message 6 of 26
(690 Views)

Oops, typo. I include "NI LabWindows/CVI Shared Runtime" and that's all it has ever needed. I tried checking the Side-By-Side version but that did not help.

 

The changes made since the last build include:

 

General Tab

- Installer Version - I let it auto increment, but will change the third digit for main releases.

- Publisher: changed to new company name (we were acquired)

- Publisher URL - changed

 

Files Tab

- just adding some .hex files, which we do every build.

 

Nothing else has been changed. This issue may have existed for some time since we generally are just upgrading. But, we got a new batch of embedded PCs that run Windows 10 LTSC and it is quite possible they have a different version of Windows than the older ones we had been using in our systems.

 

On LTSC, the normal installer would run but the program would not -- missing two DLLs that come on Windows 10, but are not part of Windows 10 LTSC. So those got added to the installer two years ago or so, if I recall.

 

We only started getting these new PCs recently. The one I test with upgraded fine, so clearly at some point the old installer put something on it that allows updates to run, and after Reset this PC, that is missing.

 

I never intentionally touched things, so now the question is simply ... what should I have to include to make an installer that runs on a fresh Windows system?

 

I did a clean Reset this PC on Windows 11 Arm and get the same issue, so it applies there to. I do not have a normal non-LTSC Windows machine to reset and test with. It could be as simple as something no longer being part of LTSC/Arm and we need to manually add it, like the two DLLs I had to use for my program to run.

 

0 Kudos
Message 7 of 26
(686 Views)

Does anyone here know how to tell what is in an installer? I have old ones, that work, and the new one, that doesn't.

 

Is there some way I can look at the files in the /Volumes folder and figure out what used to be there, and is missing now?

0 Kudos
Message 8 of 26
(676 Views)

I went back in time to find when the last installer that runs was --

 

1.17.9008 builds, then the next installer was 1.17.9011 that does not. I did not change anything intentionally with the installer, but builds after that do not install.

 

I can put the 9008 build on, then upgrade, just fine, so that is a workaround for now.

 

I'd sure like to know what was in my 9008 installer that got omitted somehow. I only have one checkbox selected, and do not know what else could have changed. I wonder if there is some 32-bit/64-bit issue or something.

0 Kudos
Message 9 of 26
(672 Views)

You still haven't answered what NIPM version is on your system. The change could come from some NI component that was updated for whatever reason. Did you install or upgrade any software from NI recently? Even a small driver could have caused this.

Rolf Kalbermatter
My Blog
0 Kudos
Message 10 of 26
(665 Views)