NI Package Manager (NIPM)
Error installing package NI CompactRIO
Hello,
I have a problem installing the CompactRIO drivers onto a Win10 measurement PC. LabVIEW itself installed correctly but when I try to install the compactRIO drivers I do get the following error.
I have installed LabVIEW on numerous machines and have never seen this error before, anyone have any ideas ??
Below (and attached) part of the errorlog.txt
[10/02/2022 09:46]
===== 2022-Feb-10 08:50:06.781296 =====
Exception in ni::pkgclient::TransactionBase::StartInternal. Error code: -125083
Request type: 30
-125083: An error occurred while installing a package: ni-usbvcp (6.7.6.49152-0+f0)
File: source\nipkg_client\pkgclient\PluginInteraction.cpp
Line number: 258
Additional error information:
-125530: An error occurred while installing the MSI at 'NI-USBVCP64.msi'.
File: E:\dev\_r\7\nipkg\source\shared_agents\WinInstall/ErrorHandler/ErrorInfo.h
Line number: 102
Thanks for reading
Hey Floris,
I just confirmed on a fresh install of Windows 10 Enterprise 21H2 that I am able to install LabVIEW 2021, then CompactRIO 21.0 successfully. I was unable to reproduce your specific problem.
This type of failure is bizarre and I've not personally seen it happen before. Several more questions/steps come to mind:
- Can you check out your SetupAPI device log for anything pertaining to the failed driver installation? It will usually contain more detailed failure information than the NIPKG or MSI logs when driver registeration/installation is failing. Here's a guide for where to find it: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/setupapi-device-installation-log-e...
- Does your company have any specific windows group policies around installing drivers? This is not an issue with a plain Windows 10 Enterprise install and I think that's going to be where the trouble is.
- Have you tried installing any other NI drivers? Most of our drivers will install a kernel driver, which is what this is failing on. I'm curious to see if any kernel drivers can be registered on your system. DAQmx contains several, and it is part of the CompactRIO Device Drivers Installation, so I'd be curious to see if it installs properly.
- Can you run `driverquery` from a command prompt and see if you see any ni drivers already registered on the system? They would usually start with `ni` and look like these:
- Have you ever been successful installing CompactRIO onto your system? Did a previous version install successfully?
Hopefully some of that helps zero in on the source of the problem.
Your setupapi.dev.log showed that you might have a corrupted certificate or certificate path on your machine. The log file indicated that the failure was due to 'A certificate was explicitly revoked by its issuer.`
I'm not sure what has caused this on your system. There are legitimate reasons for this to occur, but in this case, I'm thinking it might be a corrupt certificate on the system that has caused it to be in the 'Untrusted Certificates' on that machine.
Can you check your certificate manager on that machine and post a screenshot of your untrusted certificates list? It should ideally be empty like this:
To get there, just >>Run 'certmgr.msc' and navigate to 'Untrusted Certificates'.
Also, I was looking back through the history and I see we didn't specifically talk about what version of CompactRIO you're having issues with or what medium you're installing it (offline installer or through NI Package Manager). Could you clarify that as well?
Further inspection of your setupapi.dev.log shows that the issue is occurring when your system attempts to validate the driver's INF with its CAT file. The CAT file is Microsoft signed and I'm wondering if on your system it shows further details on what might be going on here.
Hopefully the installer left the .cat file on your system. Can you check your file system and see if you have this file:
- "C:\Program Files (x86)\National Instruments\Shared\USBVCP\slabvcp.cat"
If so, double-click on the 'slabvcp.cat' file. Then 'View Signature' then 'View Certificate' then navigate to the 'Certification Path' tab. It should look something like this:
I think the root of the issue might that this driver is sha1 signed in 2017 and there's some group policy on your system that prevents sha1 signatures from being installed to your system. The signed certificate should still be a valid signature even though Microsoft is deprecating allowance of new sha1 signatures.
I don't know group policies well enough to say specifically which one might cause this, but the fact that this installation works on my Enterprise 21H2 machine and not yours tells me maybe that's what's going on. Could you look around in your Local Group Policy Editor and see if you see any defined and active policies that might affect sha1 signature validation?
