LabVIEW Installation Freezing during Offline Manual

[santo_13]

---

@cy... wrote:

I got the "An internal error occurred. Value cannot be null. Parameter name: key" from using the latest NIPM online install for LabVIEW only (some additions may trigger the offline help error freeze) after choosing to check for update. the same error also happen with the offline iso

---

Few other seem to have faced this issue, and root cause seem to be a occaionally slow internet connection, retrying the install should work.

[ThaiDo345]

I don't seem to have this offline help viewer folder and the taskkill still gives me the same error.

[Christina_R]

---

@ThaiDo345 wrote:

I don't seem to have this offline help viewer folder and the taskkill still gives me the same error.

---

It's possible that you have a different root problem. There have been some issues related to network changes at NI recently. But we're also still working on the issue with the offline help file.

Would you be willing to share your log files with me? C:\Users\<username>\AppData\Roaming\ni-offline-help-viewer\logs

[ThaiDo345]

Actually took a few installation tries, but the offline folder finally showed up and I was able to move the database folder. Installation of LV 2025 worked after that.

[huikmn]

The "taskkill /IM NIOfflineHelpViewer.exe" option worked for me, with a caveat.  It appears that a previous installation of NI software installed a help viewer.  That help viewer seems to activate to help with the installer.  After killing it, it kept reopening and caused the installation to hang or crash at different times.  It was also hidden from the default (Processes) task manager tab, it would only show in the Details tab.  Here's what worked for me:

open an elevated command prompt (maybe not necessary to be elevated, but it can't hurt)
type: taskkill /IM NIOfflineHelpViewer.exe 
open Task Manager
Go to Details tab
Run NI installer
Keep an eye on it, if NIOfflineHelpViewer.exe shows up in the Task Manger again hit enter in the command prompt.
Press up arrow in command prompt to load the previous taskkill command (or copy it to the clipboard) so you don't have to type it out each time.

[cy...]

I think NI should release a KB fix for this, since the Offline Help Viewer issue is blocking LV from being installed or uninstalled entirely. At minimum, the fix should clean up the system to a state where NI software can be installed OOTB successfully — without needing a full Windows reset. This really needs better failure handling and recovery steps.

Users shouldn’t have to jump through hoops just to get the LV into a usable state — much like what we saw with the broken toolkit.

[Christina_R]

---

@cy... wrote:

I think NI should release a KB fix for this

---

Support has created the KB:

LabVIEW Installer Hangs on 'NI Offline Help Viewer' Step - NI

[Rodney_D]

Hello,

I'm the member of our IT team which automates the install of the complete set of NI LabVIEW software using Microsoft Systems Center Configurtion Manager (SCCM) here at our university engineering college.

We've never experienced a major problems with the installation before and have a standard process for how we package LabVIEW to our PCs in the labs and research PCs.

Recently, our campus IT teams have been in a process to upgrade our desktop PCs to Microsoft IntraID (Azure) domain joined devices.

We are now seeing that our desktop PCs can't install the LabVIEW software because of a problem with the NI package manager hanging (freezing/deadlocking) during the install of the offline manuals using the "NIOfflineHelpViewer".

Until last week I have been attempting to install LabVIEW 2025 Q1 (25.10.49417) and encountered this deadlock issue, so I've recently downloaded the most up to date version of both LabVIEW 2026 Q1 (26.10.49909) with package manager 26.3.0 (26.30.49300) and am still encountering the deadlock issue.

If I take the exact same package and install it on a desktop PC which is part of our on historical on premises active directory (AD) domain, then the scripting works without any problems at all.

So our "NIOfflineHelpViewer" offline files deadlock seems to be caused not by Windows 11, but by which domain the desktop PC is a member of.

Note 1:  Our Microsoft System Center Configuration Manager (SCCM) executes our LabVIEW packaging script as user "NT Authority\SYSTEM".

Note 2:  The "No mapping between account names and security IDs was done" error does not appear in the package manager stdout log output, but is output directly to the terminal console instead.

Note 3:  The actual "ni-offline-help-viewer" was actually installed much earlier in our package manager stdout logging without issues as displayed in the following clipped 11 lines ...

6/29/2026 4:28:36 PM | Installing ni-discovery-service: 0%

6/29/2026 4:28:36 PM | Installing ni-discovery-service: Done

6/29/2026 4:28:36 PM | 

6/29/2026 4:28:37 PM | 

6/29/2026 4:28:42 PM | Installing ni-offline-help-viewer: 0%

6/29/2026 4:28:42 PM | Installing ni-offline-help-viewer: Done

6/29/2026 4:28:42 PM | 

6/29/2026 4:28:44 PM | 

6/29/2026 4:28:47 PM | Installing ni-license-manager: 0%

6/29/2026 4:28:48 PM | Installing ni-license-manager: 50%

6/29/2026 4:28:48 PM | Installing ni-license-manager: Done

Note 4:  For my own debugging, I attempted to execute the same setup that the NI package manager was attempting to perform, but without the '--no-ui' option, as in the following command line ...

"C:\Program Files (x86)\National Instruments\Shared\Offline Help Viewer\NIOfflineHelpViewer.exe"  --import "C:\Program Files (x86)\National Instruments\Shared\Offline Help Manuals\ni-lvdfc-offline-manual-en"

... and I got the following displayed GUI dialog error ...

[Dialog title bar]  Loading Error

         Application Launch Failed

  Application could not be launched due to an error

       Invalid permissions on the path

  c:\ProgramData\National Instruments\Offline Help Viewer should have write permissions.

Note 5:  When the deadlock occurs, terminating the "NIOfflineHelpViewer.exe" (and all child processes) does in fact allow the install to continue, but the termination must be performed multiple times before all our NI packages are installed.

Note 6:  In our situation, for the "fresh" installation of LabVIEW on a new PC, the folder tree has the following structure when the deadlock occurs:

C:\ProgramData\National Instruments\Offline Help Viewer\Crashpad

C:\ProgramData\National Instruments\Offline Help Viewer\Local State

C:\ProgramData\National Instruments\Offline Help Viewer\Crashpad\attachments

C:\ProgramData\National Instruments\Offline Help Viewer\Crashpad\metadata

C:\ProgramData\National Instruments\Offline Help Viewer\Crashpad\reports

C:\ProgramData\National Instruments\Offline Help Viewer\Crashpad\settings.dat

Our primary issue here is that we do not manually install the LabVIEW software on our faculty, staff, or student lab systems by hand.  We need to automate the install and that isn't working on our PCs that are members of our IntraID/Azure domain because of this deadlock issue.

We also support several versions of LabVIEW since 2019, so we need all of the versions to work.

Does National Instruments support have a fix for this issue yet?

Thank you for any help you may provide.

Rodney

[Rodney_D]

FYI,

I have managed to find the reason, in my situation, for the dilemma I have been having with the deadlock of the "NIOfflineHelpViewer.exe" during the NI package manager silent install setup.

It appears that the "NIOfflineHelpViewer.exe" is a binary where at least some, or most of it's development was done by a company called "zoomin-software", and some part of the development is done in Javascript.

Once the "NIOfflineHelpViewer.exe" is installed, there is a Javascript file called ...

   "C:\Program Files (x86)\National Instruments\Shared\Offline Help Viewer\resources\app.asar"

... and that file contains a line of code which calls "cacls" to set an ACL on the "C:\ProgramData\National Instruments\Offline Help Viewer" folder.

The "cacls" code line looks something like this ...

     'cacls "'.concat(e,'" /E /P "%username%:C"')

The problem is that, during our SCCM install process the "NIOfflineHelpViewer.exe" will be running as user "NT Authority\SYSTEM" and the %username% variable will contain the computers name with a "$" appended.  Example:  PC1$

Under an Intra ID domain joined PC, the name PC1$ can't be looked up by "cacls" to obtain the SID for the account.  So we get the error returned "No mapping between account names and security IDs was done."  But, under an AD joined PC, Windows "cacls" can lookup the SID normally.

So, if the line of Javascript is changed in the following way ...

     'cacls "'.concat(e,'" /E /P "%computername%:C"')

... then our LabVIEW will install without issues on our Azure PCs.

So, to resolve this issue as a quick-fix temporary solution, we have modified our SCCM package to install the "NIOfflineHelpViewer.exe" first, then modifiy the file "C:\Program Files (x86)\National Instruments\Shared\Offline Help Viewer\resources\app.asar" to contain the changed data above that uses the %computername% instead of the %username% environment variable.

I thought this information might be important for anyone suffering from this "bug" for the same reasons we are.

IMPORTANT!!!   I actually believe this is an Intra ID/Win11 issue and not neccessarily a National Instruments bug, but nevertheless the method above can only be used when the "NIOfflineHelpViewer.exe" is installed as user SYSTEM and not as a regular user of course.

Rodney

[Rodney_D]

Hi, I would like to add an addendum to my previous post about the deadlocking of the "NIOfflineHelpViewer.exe" during the LabVIEW NI package manager install.

There's actually no reason to modify the following file at all during the install processing to temporarily work around this deadlocking problem:

     "C:\Program Files (x86)\National Instruments\Shared\Offline Help Viewer\resources\app.asar"

Instead, during your install scripting, the %USERNAME% variable will be inherited by the "NIOfflineHelpViewer.exe" process, which in turn inherits the variable from the NI package manager, which can inherit the variable from your package scripting.  This means that if the %USERNAME% environment variable can be set by your parent packaging script, and then the "NIOfflineHelpViewer.exe" will eventually inherit it.

So, our SCCM packaging is done in PowerShell, and here's the code I've now added in our PowerShell script to solve the problem:

    if ( $null -ne $ENV:USERNAME )
    {
        if ( $ENV:USERNAME.EndsWith('$') )
        {
            $ENV:USERNAME = $ENV:COMPUTERNAME
        }
    }

I thought this extra information would be important for anyone trying to work around this deadlock.