From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
02-18-2009 02:50 AM
I just upgraded to LV 8.6.1 on Windows Vista, and all my DAQmx routines fail to load with the message:
Error loading "nilvaiu.dll"
A dynamic link library (DLL) initialization routine failed.
Based on some old posts, I tried to add write permissions to all folders in C:\Program Files\National Instruments, but that didn't help.
I also uninstalled DAQmx - LV 8.6 Support and reinstalled it but that had no effect.
I also tried running "regsvr32" on the DLL, but that failed with a similar message.
Is anyone else experiencing this?
Is there a solution?
Jason
Solved! Go to Solution.
02-18-2009 04:22 PM
Jason,
I was able to find a KnowledgeBase Article on this, but I am guessing that it may not do you much good as it seems as though you have gone through the steps already. There is also another KnowledgeBase article attached about how to tell if a DLL has all dependencies attached. Also, what version of DAQmx have you installed with 8.6.1?
Error with nilvaiu.dll or MAX Splash Screen Crashes After Installing NI-DAQmx
How Can I Determine If a DLL Has All Required Dependencies?
03-02-2009 02:42 PM
Hi Jason,
Did you have any luck solving this problem? I removed ALL NI software from my system (it had 7.1 installed) and reinstalled everything from scratch...LV 8.6 package. I still cannot get MAX to startup and if I try to load a previous program I receive a "nilvaiu.dll" error. I tried that little program but it didn't tell me much.
Thanks,
Teri
03-02-2009 03:10 PM
Teri:
No, I haven't. I have been able to get my work done for now without executing DAQ stuff on my development machine, but I still do need to fix this. My coworker says the Dependency Walker does not find the problem because only static dependencies are found. He recommended I try WinDbg, which can trap the runtime DLL dependencies, but I haven't had time
WinDbg comes from Microsoft.
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Good luck, and in case you are faster than me, please let me know how it goes.
Jason
03-02-2009 03:54 PM
Thanks for the info...I'll give it a try and let you know what I find. My service agreement expired recently and I cannot justify $1500 to get a question answered! It seems to be never ending with NI, everytime something is upgraded I have to jump through hoops to get it to work how it's supposed to!
Thanks,
Teri
05-19-2010 05:34 PM
I encountered the same nilvaiu.dll error after reinstalling LV2009SP1 and NI drivers from 2010-DS1 DVDs. While working through the error with me, Ben from NI Support found this resource: "NI Software Failure When PAE (Physical Address Extension) is Enabled on Windows Operating Systems". (Document ID 54D9I6M6). This turns out to be the root problem of both my "nidevmon.exe" failure on boot and "nilvaiu.dll" failure on DAQmx load: recent DAQ libraries are incompatible with physical address extension enabled.
I am running Windows Server 2003 with 4 GB of RAM. PAE is enabled by default with Server 2003. (Look at System -> General to see if PAE is enabled: it is right below the RAM.) As Microsoft recommends that PAE not be disabled because it provides execution security, I followed the second of the two suggested methods.
I edited the boot.ini file (System-> Properties -> Advanced -> Startup and Recovery ->Edit), added /maxmem=4096 to the startup command and rebooted. Both nidevmon.exe and nilvaiu.dll errors were corrected with this change.
System -> General now reports 3.25 GB of RAM (vs 4.00 before) so I have lost a bit more memory than anticipated. I may look into using the /burnmemory switch, which Microsoft recommends over /maxmem because maxmem "does not account for memory holes". I'm trying /burnmemory=16 now.
-Rob
05-20-2010 09:01 AM
05-20-2010 10:08 AM
Although it didn't work for me, Ben from NI said driver corruption is the most common cause of this problem. He recommended the following steps to force re-installation of DAQmx and NI-VISA from your original disks:
You'll have to have the original disks for all installed versions of LabView, since it will be re-installing version-specific copies of the LabView wrappers around DAQmx.
...
Following up on my earlier post, setting /burnmemory does not work. I found a blog post on /maxmem by the always terrific Raymond Chen that explains this. What /maxmem=4096 really tells Windows is "don't even look at a physical addresses above 2^32". The top 0.5 GB of address space is assigned to hardware by default, so with /maxmem set to 4GB, only 3.5 GB of RAM will be available. With PAE enabled, the processor can map driver memory somewhere else and make use of additional RAM, but 32-bit DAQmx can't handle getting remapped in this way and refuses to load.
DAQmx 8.9.5 and later is suppose to run on 64-bit Windows, so I am assuming that this issue does not arise on Microsoft's 64-bit operating systems with more than 4 GB of RAM running DAQmx 9.0.2.
05-20-2010 05:30 PM
I just wanted to check if this issue has been resolved. I see that there is a post marked as an accepted solution but the following posts lead me to believe that the issue is still not resolved.
Tanya V
05-21-2010 09:17 AM
Hi Tanya,
My issue has NOT been resolved...still trying to get an answer from NI, it's been over a week now. It looks like Rob's issue was resolved, but I don't see where jdunham's was...don't know why it's marked resolved.
I actually have another thread going with the same/different issue, the problem originated with CAN/XNET error and then I discovered that DAQmx will not work. Frustrating.
I'll update both posts, hopefully with a solution!