Error Installing Offline Packages - LabVIEW 2020 Runtime Engine

[Andrew.D.Owens]

Hello forum peeps,

I encounter an install error during LabVIEW Runtime Engine (RTE) 2020 / 32 bit offline installer. 

I am attempting to install LabVIEW Runtime Engine 2020 (32 bit) on a new Windows 10 Pro PXIe controller.  Note this is a new installation of 'Windoze' 10 Pro.  My end goal deployment involves a compiled LV executable with the LV Runtime | VISA | PXI | NI Switch etc. drivers all installed offline due to access restrictions for this isolated system.

Here's what I have tried:

• NIPM 20.1.0 offline install - no issue
• LabVIEW RTE 2020 offline image install - Error code: -125083
  • See screenshot and NIPM error log attachment (from <USER>\AppData\Local\National Instruments\NI Package Manager\Logs>
• VISA 20.0.0 offline image install - Error code: -125083
  • error log attachment

Based on some other forum posts it sounds like this is a package dependency issue and not a connectivity issue.  Since this happens on LV RTE and VISA with the same / similar error I'm guessing this isn't specific to either of these installs and may be a more general issue.

-Andrew 🤓

[Scott_Richardson]

Andrew, the Package Manager logs suggest the error 2705 from the MSI. I suspect that those that can help debug this issue will need you to follow the steps in the below KB to obtain the MSI logs and share those on the forum.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P6FcSAK&l=en-US

[Andrew.D.Owens]

Update:

NI tech support helped me rule out some of the common pitfalls based on Error Occurred While Installing a Package in NI Package Manager knowledge base.  These were the quick steps.

* Windows Update (Skipped due to offline system)

* Deactivated Firewalls

* Deactivate Virus Scans / Software

* This was the latest NIPM

* NI Service Location / Config Mgr. were not to be found

These didn't see to fix the issue.  I tried the same RTE 2020 offline install now with the MSI log enabled.  I've included a section from the log with what appears to be the first real error (highlighted in red below).

---

MSI (s) (14:30) [14:19:44:117]: Doing action: NIMUPersistPartRegInfo.91D5760B_F9E8_4332_BFB1_38A4CB799A3E
Action ended 14:19:44: ValidateProductID. Return value 1.
MSI (s) (14:F0) [14:19:44:118]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI441.tmp, Entrypoint: NIMUPersistPartRegInfo
Action start 14:19:44: NIMUPersistPartRegInfo.91D5760B_F9E8_4332_BFB1_38A4CB799A3E.
NIMUPersistPartRegInfo: Version=20.0.0.97
NIMUPersistPartRegInfo: Build date=2/27/2020 12:38:35 PM
NIMUPersistPartRegInfo: Starting action...
GetNIMUComponentFeature: Entering subroutine...
MSI (s) (14!70) [14:19:44:127]: PROPERTY CHANGE: Adding NIMUMainFeatureName.91D5760B_F9E8_4332_BFB1_38A4CB799A3E property. Its value is 'NIMUFeature'.
GetNIMUComponentFeature: Created Faux ComponentId {07298687-c518-4981-9ae1-6e62273bf43a}
GetNIMUComponentFeature: Created feature "NIMUFeature" for component to go under.
GetNIMUComponentFeature: Leaving subroutine.
NIMURegPartInfo: Starting action...
NIMURegPartInfo: About to get properties
NIMURegPartInfo: Registering ProductCode {07298686-C518-4981-9AE1-6E62273BF43A}
NIMURegPartInfo: Complete!
NIMUPersistProdList: Starting action...
WriteNIMUProductList: Entering subroutine...
WriteNIMUProductList: Recording Part ProductCode: {07298686-C518-4981-9AE1-6E62273BF43A}
WriteNIMUProductList: Leaving subroutine.
NIMUPersistProdList: Complete!
NIMUPersistPackageInfo: Starting action...
WriteNIMUPackageInfoInternal: Entering subroutine...
WriteNIMUPackageInfoInternal: Leaving subroutine.
NIMUPersistPackageInfo: Complete!
NIMUPersistDepends: Starting action...
GetDependsTableRev: Entering subroutine...
GetDependsTableRev: Found 1.1 dependency information - done.
WriteNIMUDepends: Entering subroutine...
VerifyNIMU11DependsTableGood: Entering subroutine...
VerifyNIMU11DependsTableGood: About to check if both 1.1 NI depends tables match up on the Dependency key column.
VerifyNIMU11DependsTableGood: No dependency mismatches found -- very good!
VerifyNIMU11DependsTableGood: Complete!
WriteNIMUDepends: Writing row 1 for Feature_ = Core.MIFMUI
WriteDependsRow: Evaluated condition '' to 1
WriteNIMUDepends: Writing row 2 for Feature_ = Core.MIFMUI
WriteDependsRow: Evaluated condition '' to 1
WriteNIMUDepends: Wrote 2 rows of dependency information.
WriteNIMUDepends: Now writing out the parent UpgradeCode and Version.
WriteNIMUDepends: Leaving subroutine - complete!
NIMUPersistDepends: Complete!
NIMUPersistPatchTargetReg: Starting action...
NIMUPersistPatchTargetReg: Complete!
NIMURegisterMUCustomExecute: Starting action...
NIMURegisterMUCustomExecute: Complete!
NIMUPersistMdfClientAdeInfo: Starting action...
NIMUPersistMdfClientAdeInfo: Complete!
NIMUPersistPartRegInfo: Complete!
MSI (s) (14:30) [14:19:44:184]: Skipping action: NIMUSetReinstallProperty.91D5760B_F9E8_4332_BFB1_38A4CB799A3E (condition is false)
MSI (s) (14:30) [14:19:44:184]: Doing action: CostInitialize
Action ended 14:19:44: NIMUPersistPartRegInfo.91D5760B_F9E8_4332_BFB1_38A4CB799A3E. Return value 1.
MSI (s) (14:30) [14:19:44:185]: Machine policy value 'MaxPatchCacheSize' is 10
Action start 14:19:44: CostInitialize.
MSI (s) (14:30) [14:19:44:186]: PROPERTY CHANGE: Adding ROOTDRIVE property. Its value is 'C:\'.
MSI (s) (14:30) [14:19:44:186]: Note: 1: 2705 2: Directory
DEBUG: Error 2705: Invalid table: Directory; Could not be linked as tree.
MSI (s) (14:30) [14:19:44:188]: Product: NI Uninstaller 20.0.0 -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2705. The arguments are: Directory, ,

The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2705. The arguments are: Directory, ,
Action ended 14:19:44: CostInitialize. Return value 3.
Action ended 14:19:44: INSTALL. Return value 3.

---

---

@Andrew.D.Owens wrote:

Hello forum peeps,

I encounter an install error during LabVIEW Runtime Engine (RTE) 2020 / 32 bit offline installer. 

I am attempting to install LabVIEW Runtime Engine 2020 (32 bit) on a new Windows 10 Pro PXIe controller.  Note this is a new installation of 'Windoze' 10 Pro.  My end goal deployment involves a compiled LV executable with the LV Runtime | VISA | PXI | NI Switch etc. drivers all installed offline due to access restrictions for this isolated system.

Here's what I have tried:

• NIPM 20.1.0 offline install - no issue
• LabVIEW RTE 2020 offline image install - Error code: -125083
  • See screenshot and NIPM error log attachment (from <USER>\AppData\Local\National Instruments\NI Package Manager\Logs>
• VISA 20.0.0 offline image install - Error code: -125083
  • error log attachment

Based on some other forum posts it sounds like this is a package dependency issue and not a connectivity issue.  Since this happens on LV RTE and VISA with the same / similar error I'm guessing this isn't specific to either of these installs and may be a more general issue.

-Andrew 🤓

---

[Andrew.D.Owens]

Update / Possible Solution:

I ended up doing a new Windows 10 x64 install on a separate machine and the NIPM & LabVIEW Runtime Engine 2020 both installed successfully!  I then went back to the original machine and duplicated the OS reinstall and NIPM install process with success!  Here's some notes on the differences:

• New OS install / Re-downloaded OS disk image (not likely the issue imo.)
• No Windows Updates pushed (did completely offline)
• Additional Windows Settings Changes
  • Windows has lots of Virus & Threat protection.  I had 'Real-Time' (threat) protection disabled and other virus scans disable; however, I did not have all of the 'Rep. Based Protection' disabled (see screenshots)
• Made sure NIPM was installed separately first with 'Run As Admin.'
  • I may have ran the LabVIEW RTE installation first and/or without 'Run As Admin' on my first problematic attempt. 
  • The only general errors I saw were not updating feed errors due to lack of connectivity.

Again not necessarily an exact solution.  Hopefully this will help someone down the road or narrow the problem-solution space 🤔 🙂

[Andrew.D.Owens]

Thanks for the MSI log tip.  I've attached the MSI log file and the two other ones showing general info.

[Scott_Richardson]

Andrew -

When installation failed, i.e installing LabVIEW RTE first, you said that you might not have "Run as Admin". Questions:

1. Can you be more specific as to how you are performing your installation with and without "Run As Admin"?
2. When you just run the NIPM or LabVIEW installation, does the OS prompt you to elevate, or are you required to manually select to run as administrator?
3. Do you have your system set in some way to not prompt for elevation?

[WesW]

Hi Andrew,

I took a loog at the MSI logs as well (thank you, very helpful) - and the problem on the original machine is that something is wrong with the Windows "COMMON_DOCUMENTS" location. That location is: "The file system directory that contains documents that are common to all users. A typical path is C:\Documents and Settings\All Users\Documents."

It's either missing, the permissions are incorrect, or it's mapped somewhere that is not accessible (like if it's mapped to network location, and you're not connected to that network). 

Just sharing how I determined that, looking higher in that log, there is this line:
SHGetFolderPath(CSIDL_COMMON_DOCUMENTS) failed with error 2147942402

which is the Windows standard error for "The system cannot find the file specified.". This location is the root of some files in that installer, so since it couldn't be found, that's why we see the later somewhat obscure Windows Installer engine failure of: "Could not be linked as tree". 

Making that location accessible would likely fix this issue.

[Andrew.D.Owens]

Scott,

I typically use the right-click menu to 'Run As Administrator' for installers.  I may have double clicked the main executable file during the first attempt of the LabVIEW RTE installer.  Subsequent installation errors were from using the 'Run As Administrator' right-click menu.  The LabVIEW RTE launched from double-click or from the 'Run As Admin.' menu both result in the same elevation with the locked screen dialog titled 'User Account Control'. 

It's interesting that even when the right-click menu is used with 'Run As Admin.' the OS still prompts an elevate with a locked-screen 'User Account Control' window.  If you double click say the NIPM installer application the OS provides a 'Open File - Security Warning' that doesn't lock the entire screen (see attached image).  I tried a custom project created LabVIEW VI executable installer and it elevates using the locked screen prompt.

I typically put the installer resources on a root directory, e.g. "C:\PXIe_Install_Files\...", to be able to have access across multiple Windows user accounts.  As part of this debug we tried launching the installer from three locations including root directory, mounted virtual disk (for iso image), & user directory (desktop) that all seemed to result in the same error (even for copied files from an iso image). 

Re system settings, this is a mainly a new default Windows 10 x64 install.  I'm using the first user account that has 'admin' rights.  I don't think there are any weird settings except for disabling Windows Update from within the services menu and from the group policy editor (computer wide scope).  I have disabled all the seemingly problematic virus scans and the application security under the security section under the 'App & Browser Control'.  I did leave the hardware exploit monitoring enabled (Core Isolation & Security Process).

-Andrew

[Andrew.D.Owens]

Wes,

Thanks for the details on this.  I checked the installation directory and the SYSTEM | Current User | Admin Group all have the same permissions ('Allow' for all items except special permissions that is left unchecked).  This is a sub-directory of the root of the disk.

I wasn't able to find the common documents folder on the C:\ directory even with hidden folders enabled.  Is there a shell script or some type of command to enable these?  I wonder if this is created after some kind of first use or other application request.  This is essentially a new OS install.

Andrew

[WesW]

Andrew,

Exactly how you launch the installer as admin shouldn't matter, and that you are installing files directly to a sub-folder of C:\ shouldn't affect this either. It's that one of the packages included in your feed is referencing that COMMON_DOCUMENTS folder.

Sorry for the misdirection, looks like that location in newer Windows versions has changed since that MSDN source was published. On Windows 10, it's typically: C:\Users\Public\Documents

The value for your system I think can be read from the registry here: 
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders, Common Documents

This key and folder should exist on a fresh Windows 10 install - not sure why it wasn't in your case?