Python ctypes cannot import nicaiu.dll

[lazzarello]

I would like to program a cDAQ with Python. I began with the example python scripts in the documentation for the Advanced Scripting forum post. They seem straight forward  and I'm familiar working with Python Ctypes. I also found the NI sponsored open source library nidaqmx-python. Installing that was simple. When I tried to call functions from python, I received the following exception.

C:\>python
Python 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 22:22:05) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import nidaqmx
>>> system = nidaqmx.system.System.local()
>>> system.driver_version
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python\lib\site-packages\nidaqmx\system\system.py", line 73, in driver_version
    return DriverVersion(self._major_version, self._minor_version,
  File "C:\Python\lib\site-packages\nidaqmx\system\system.py", line 108, in _major_version
    cfunc = lib_importer.windll.DAQmxGetSysNIDAQMajorVersion
  File "C:\Python\lib\site-packages\nidaqmx\_lib.py", line 166, in windll
    self._import_lib()
  File "C:\Python\lib\site-packages\nidaqmx\_lib.py", line 209, in _import_lib
    windll = ctypes.windll.LoadLibrary(lib_name)
  File "C:\Python\lib\ctypes\__init__.py", line 434, in LoadLibrary
    return self._dlltype(name)
  File "C:\Python\lib\ctypes\__init__.py", line 356, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: [WinError 126] The specified module could not be found

Perhaps this is because I haven't installed the NI-DAQmx drivers. How do I install the ni-daqmx software in a Windows Server 2019 environment without a GUI? The following are my results using four different techniques to install the ni-daqmx software.

The procedure documented in Customize and Automate Installation of a Single Installer failed to install any software with the following command

setup.exe /q /AcceptLicenses yes /r:n

This command returned instantly with no output.

I noticed the spec file in the shipped installer USB disk. I passed that to the installer after modifying it like so

[Features]
; NI-DAQmx
niDAQmxCorei.NIDAQMXCOREI=Local

; NI-DAQ Trad
NIDriver.DAQ01=Local

The results were the same as the previous technique.

I found another document titled Automating an Online or Offline Installer. Following the instructions did not result in my system having any installed software. I'm lost and would be grateful for any help. The following is the output and error code for the Offline installer procedure. Notice the unusual error code?

C:\installers>dir
 Volume in drive C has no label.
 Volume Serial Number is 3621-54B0

 Directory of C:\installers

04/22/2019  05:55 PM    <DIR>          .
04/22/2019  05:55 PM    <DIR>          ..
04/01/2019  12:27 PM        12,326,320 autorun.exe
04/01/2019  12:27 PM             1,436 autorun.inf
04/22/2019  05:55 PM    <DIR>          bin
04/22/2019  05:55 PM    <DIR>          feeds
03/05/2019  06:04 PM           550,920 Install.exe
03/05/2019  06:04 PM            90,672 InstallCHS.dll
03/05/2019  06:04 PM            93,744 InstallDEU.dll
03/05/2019  06:04 PM            93,232 InstallFRA.dll
03/05/2019  06:04 PM            91,696 InstallJPN.dll
03/05/2019  06:04 PM            91,184 InstallKOR.dll
04/01/2019  12:26 PM    <DIR>          meta-data
04/01/2019  12:27 PM            23,978 patents.txt
04/22/2019  05:55 PM    <DIR>          pool
04/01/2019  12:27 PM           136,625 readme.html
04/01/2019  12:27 PM           133,584 readme_chs.html
04/01/2019  12:27 PM           140,679 readme_deu.html
04/01/2019  12:27 PM           143,709 readme_fra.html
04/01/2019  12:27 PM           142,172 readme_jpn.html
04/01/2019  12:27 PM           139,146 readme_kor.html
              15 File(s)     14,199,097 bytes
               6 Dir(s)  246,295,621,632 bytes free

C:\installers>start /wait Install.exe --passive --accept-eulas --prevent-reboot

C:\installers>echo %errorlevel%
-2146232797

[jonathanadalin]

Could you try the below arguments with your setup.exe so we can see if there's any console output? Also, just  as a sanity check, you're in the directory with the DAQmx installer, correct?

setup.exe /qf /AcceptLicenses yes

[jonathanadalin]

On second thought, the basic call might be more suitable to prevent the post-install GUI elements.

setup.exe /qb /AcceptLicenses yes 

DAQmx installation usually takes a while, so seeing the progress bar might help give an idea of what's happening.

[lazzarello]

Hi! Thanks for the response. Neither of these options work and they do not produce any error output. Fortunately, I think I accidentally discovered the problem late yesterday.

The quiet mode for setup.exe calls GUI functions from Windows core libraries.

I believe this is true because my installation target is a Windows Server 2019 Docker container, so I can create an image that ships with all the DAQ software drivers. When I ran the same installer options on the host OS (also Windows Server 2019) it appeared to fail in the same way (program returns instantly with no output). I put the window in the background and went onto other work. Then I noticed that the window was flickering, the mouse pointer would change into an hourglass at seemingly random intervals, and GUI windows would pop up and install individual components then disappear.

I suspect that this quiet mode is not intended for a headless server installation. Docker containers running Windows do not have access to any GUI elements and cannot draw windows. This would explain the mysterious silent failures I've encountered.

What do you think? Is it safe to say the NI-DAQmx drivers (and C API) cannot be installed within a container?

[PahlM]

I think that is safe to say. Installing the drivers to the right place with the right permissions is very important.

PahlM

[lazzarello]

Installing DAQ drivers in a container would be a wonderful feature to enable. I've looked into running an RDP server in a container to work around the limitation of all NI packages requiring a GUI but that feature is currently disabled in the Microsoft distribution of Docker images.

[lazzarello]

My last resort is to run a script to install every single .msi in the vendor USB flash drive from within the container, then take a registry snapshot. From there I can use NirSoft's registry diff tool to discover what keys have changed between the host and the container.

Flying blind here but this seems reasonable.

[JoeSavage]

I ran into the same problem trying to install NI-VISA into a windows server docker container.  I've made some progress using NI Package Manager but still running into a showstopper that prevents me from going any further.  But perhaps this approach will be of use to you or anyone else trying to use Docker.

NI Package Manager is how we're doing scripted installations on our physical PCs, so I was hoping it would be useful within a Docker container.   However, the installer for NI Package Manager itself doesn't seem to support a completely headless environment, as it still pops up a window briefly when using the '/Q' command line option (or the "--passive --accept-eulas --prevent-reboot" option needed for NIPM 19.6).  So when running in a docker container, it fails silently with no useful error message.

I have gotten around this by simply copying the NIPM binaries from a PC that has it installed already.  Fortunately it seems that all is needed is to copy the entire C:\Program Files\National Instruments\NI Package Manager tree, and you can run nipkg.exe without any other dependencies.

This allowed me to at least kick off the installation of ni-visa-runtime through the following Dockerfile commands:

RUN nipkg feed-add https://download.ni.com/support/nipkg/products/ni-v/ni-visa/19.5/released
RUN nipkg feed-add https://download.ni.com/support/nipkg/products/ni-v/ni-visa/19.5/released-critical
RUN nipkg update
RUN nipkg install ni-visa-runtime

This actually gets pretty far, all the way up to the installation of ni-visa-shared-components, where I run into the problem I can't yet get around.

The installation of ni-visa-shared-components fails with error 1603, with the following context:

Error -125083: An error occurred while installing a package: ni-visa-shared-components (5.12.0.49152-0+f0)

Additional error information:
Error -125441: The executable returned error '1603' after running the custom execute command 'path='"C:\Users\ContainerA
dministrator\AppData\Local\Temp\nipkg-0f5e-0b34-3183-d03d\data\VisaSharedComponentsInstaller.exe"', arguments='VisaShare
dComponents64.msi''.

Digging a little deeper by running msiexec with logging enabled to install VisaSharedComponents.msi , I found that the error stems from the installation of the ausbtmc.inf driver, which happens as a custom action of the MSI installer:

DIFXAPP: ENTER: InstallDriverPackages()
DIFXAPP: INFO: 'CustomActionData' property 'DIFxApp Version' is '2.1'.
DIFXAPP: INFO: 'CustomActionData' property 'UI Level' is '2'.
DIFXAPP: INFO: 'CustomActionData' property 'componentId' is '{89E61DBB-EB14-5DB1-B273-ED36AFA029A4}'.
DIFXAPP: INFO: 'CustomActionData' property 'componentPath' is 'C:\Program Files\IVI Foundation\VISA\IVI USB Staging\b841aa80\Windows\'.
DIFXAPP: INFO: 'CustomActionData' property 'flags' is 0x17.
DIFXAPP: INFO: 'CustomActionData' property 'installState' is '2'.
DIFXAPP: INFO: 'CustomActionData' property 'ProductName' is 'VISA Shared Components 5.8.0 (64-Bit)'.
DIFXAPP: INFO: 'CustomActionData' property 'ManufacturerName' is 'IVI Foundation'.
DIFXAPP: INFO: user SID of user performing the install is 'S-1-5-93-2-1'.
DIFXAPP: INFO: opening HKEY_USERS\S-1-5-93-2-1\Software\Microsoft\Windows\CurrentVersion\DIFxApp\Components\{89E61DBB-EB14-5DB1-B273-ED36AFA029A4} (User's SID: 'S-1-5-93-2-1') ...
DIFXAPP: INFO:   ENTER:  DriverPackageInstallW
DIFXAPP: INFO:   RETURN: DriverPackageInstallW  (0xD)
DIFXAPP: ERROR: encountered while installing driver package 'C:\Program Files\IVI Foundation\VISA\IVI USB Staging\b841aa80\Windows\ausbtmc.inf'
DIFXAPP: ERROR: InstallDriverPackages failed with error 0xD
DIFXAPP: RETURN: InstallDriverPackages() 13 (0xD)
CustomAction MsiInstallDrivers returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

So the root of the problem is that error 13 (0xD) is returned from the OS when ausbtmc.inf is installed.

This error is also evident in c:\windows\inf\setupapi.dev.log, confirming that it is thrown by setupapi.dll:

>>>  [Setup Import Driver Package - C:\Program Files\IVI Foundation\VISA\IVI USB Staging\b841aa80\Windows\ausbtmc.inf]
>>>  Section start 2020/02/07 13:21:56.556
      cmd: C:\Windows\System32\MsiExec.exe -Embedding 19E14B11EB999325746448E434ECF763 E Global\MSI0000
     inf: Provider: IVI Foundation, Inc
     inf: Class GUID: {A9FDBB24-128A-11d5-9961-00108335E361}
     inf: Driver Version: 08/14/2013,16.3.17614.0
     inf: Catalog File: ausbtmc.cat
!!!  sto: Failed to call to import driver package. Error = 0x0000000D
<<<  Section end 2020/02/07 13:21:56.556
<<<  [Exit status: FAILURE(0x0000000d)]

 This is also reproducible if you just copy the driver files over (ausbtmc.inf+ausbtmc.cat+amd64/ausbtmc.sys) and run 

pnputil /add-driver ausbtmc.inf

Code 13 / 0xD is ERROR_INVALID_DATA, which doesn't really provide any useful info.

Looking at the ausbtmc.inf file, nothing seems out of the ordinary.

One thought I had was it was something to do with driver signing, but I haven't gotten too far with experimenting on that thread.

Anyways, hopefully something in this post will be useful to you or someone else trying to do similar things.   And if anyone has a clue about the error above, please let me know.

Joe