NI Package Builder 19.6.1 available

[_Ross_]

Unfortunately it's a fresh ISO from Microsoft, being built on the fly, that does contain the latest updates. Windows 10 IoT LTSC 1809. 

[Scott_Richardson]

The behavior that you are seeing is likely due to the version of NIPM that is either already installed and/or in the offline installer that you are running, and the switches you are using might be older.

Please try the following command-line, which is documented in the NIPM manual here, to achieve what you are trying to do: install.exe --passive --accept-eulas --prevent-reboot

[_Ross_]

Hey Scott,

It's a fresh system with the latest ISOs pulled from the MS. Updates are applied. Nidaq has not been installed.

In my tests I am mounting the 19.6.1 ISO and running those exact switches. I am mounting the same ISO on the host and vms, and running the same switches against the same Installer.exe.

On the host system it's all good. On every VM, it's all not good.

Something to note:

In VM:

Installer.exe --help

> Installer opens, see eula, no help

Installer.exe --help --accept-eulas

> Installer opens, don't see eula, no help

On Host:

Installer.exe --help

> Installer opens, see help, no eula.

So some switches are coming through.

To be explicit, these args worked on the host "--force-essential --prevent-reboot --accept-eulas --progress-only", but do not work on the VMs. That is where things broke, and I've tried to test combinations of different switches. .NET is up to date, everything is up to date, so I'm not quite sure where the issue lies. I don't know what's left to adjust on my system to troubleshoot this.

And because it seems like I'm not clearly describing my environment, here is a screenshot with visual proof of the system's state. I forgot to put winver's in there, let me know if you want those.

[WesW]

Hi Ross,

Based on which version of NIPM may or may not be installed, it's unfortunately expected that the "--help" flag will have the behavior you describe. Under the hood, there are different binaries in play which have somewhat different command-line flags.

If you could, please try the following on the non-working VMs:

start /wait install.exe --passive --accept-eulas --prevent-reboot
then once it returns, run: 
echo %errorlevel%

That last command prints the exit code, with 0 indicating success and -126300 also meaning success but that you need to reboot.

If NIPM and NI Product Builder is not installed correctly using that command, please share what return code you are seeing, and describe (or screenshot) exactly what isn't working. Thanks for working through this with us!

- Wes

[_Ross_]

No errors, reports the Installer may be corrupt now. Same installer, same ISO mounted on the host system runs just fine. I've probably cancelled one or two installations in the VM, so it worked at one point. It just gave up the ghost. Maybe the cancel action for the installer DOES NOT properly clean up after itself. So now I have two problems?

[EricYu]

That's an unusual error which seems to indicate that the Package Manager installation on the VM is in a bad state. The error seems to indicate a missing registry key.

To help us debug the issue, could you share the following?

1. The logs in: %localappdata%\National Instruments\NI Package Manager\Logs\NIPkgLogs

2: Open Registry Editor and share what keys are present in the following location:
On a 64 bit OS:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\National Instruments\NI Package Manager\CurrentVersion
On a 32 bit OS:
HKEY_LOCAL_MACHINE\SOFTWARE\National Instruments\NI Package Manager\CurrentVersion

3: The files in: %ProgramData%\National Instruments\NI Package Manager\Agents

[_Ross_]

Sure. I hope the screenshot format works for you.

I am including the last 3 logs. I had quite a few in there. From this group should be the installation that was cancelled and subsequent runs. Let me know if I missed the log you are after, I'll attach a few more (I'm not totally sure which is from which run).

[_Ross_]

I realized you probably wanted the contents of the files under Agents/. I'm attaching a zip. Because there are a couple of dats, it was hard to ensure there wasn't any compromising system information, so please remove the archive if it contains such.

[WesW]

OK - you seem to be in an odd state that many registry keys are missing, but the packages appear to be installed? I'd like to suggest one more thing before giving this image up as a lost cause. This isn't something we've run across before, so I'd like to get as much info as possible.

If you could, do the following:

1. List the contents of the NIPM directory, like this following, and attach dir1.txt:
   dir /s "C:\Program Files\National Instruments\NI Package Manager" > "%temp%\dir1.txt"
2. Run this command to have NIPM list the full contents of what it thinks is installed:
   cd "C:\Program Files\National Instruments\NI Package Manager"
   nipkg.exe info-installed > "%temp%\info-install1.txt"
3. Run a repair for NIPM itself:
   nipkg.exe repair ni-package-manager
   It should say that it's repairing 4 packages.
4. List the contents of the NIPM directory again, like this following, and attach dir2.txt:
   dir /s "C:\Program Files\National Instruments\NI Package Manager" > "%temp%\dir2.txt"
5. Post another screenshot of HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\National Instruments\NI Package Manager\CurrentVersion

If the above steps work and there are many more registry keys in step 5 - then hopefully should be fixed. But if nipkg.exe (or other necessary files) are also missing from the directory -- then the repair will fail, too. If so, then I'd recommend just re-imaging that VM and starting over again.

If you do try again, perhaps try from a regular cmd.exe prompt, as though it shouldn't make a difference, that isn't as widely used.

[_Ross_]

Hey Wes,

I was only able to get you the first file, because nipkg.exe was not installed.

Looks like it's just a failed installation. It doesn't impact me really, as it's a virtual machine. I'm much more interested in the silent installation switches working as intended. Potentially the --quiet works for me in production, and I believe that it affects the installation, but --progress-only does not seem to register.

Attached is the directory dump from the first instruction.