nixsrk.dll causing system to sporradically reboot

[Redrabbit]

I've been having issues with a couple of newer test stations spontaneously rebooting while executing tests.  These reboots don't happen every test nor do they happen at a specific time in the test sequence.  After looking at the .dmp file generated by Windows for the reboot event it seems to be pointing in all cases to some sort of error being generated in the nixsrk.dll (which after doing some research is a driver file for the M series boards).  My test station is running LV8.5 with the newest DaqMX package (8.6.1) using CDAQ hardware (NI9172 with a couple of modules).  Is there anything I may be doing that might have caused this?  The only concern I have is that in my program there are multiple parallel loops running where the status of digital bits are being read, could it be that two of these loops are trying to access the same hardware module at the same time and generating this exception?  Any ideas would be appreciated.
 
Thanks,
Randy
 
P.S. I've included a copy of the debug log file generated from one of the .dmp files

Message Edited by Redrabbit on 01-04-2008 07:24 PM

[Redrabbit]

Any ideas out there on why this error/crash is occuring?

Thanks,

Randy

[Ima U]

Hello Redrabbit,

You are correct, nixsrk.dll is part of the DAQmx driver files.  It sounds like your file is corrupted.  Sounds like you already have the latest version of the DAQmx driver installed on your computer.  My suggestion would be for you to repair your DAQmx driver.  If you have XP go to Start>>Settings>>Control Panel>>Add or Remove Programs>>National Instruments Software and click Change/Remove.  This will open a folder of all of the NI software on your computer.  Select NI-DAQmx and click on Repair.  You will be asked for your DAQmx driver CD.  This should repair the corrupted files.

I hope this helps!

[Redrabbit]

Ima,

Thank you for getting back to me on this...I'm wondering if there is a way I can check the integrity of this file since I've already done a complete wipe and reinstall.  Is there some checksum program that I could run to verify?  I've modified my code to eliminate the continuous monitoring of the digital inputs and this has seemed to clear up the issue but I'd really like to be able to monitor these inputs going forward (I just changed it to check my theory...in real life I need the status).

Thanks,

Randy

[Ima U]

Hi Randy,

I do not know of any check to verify the nixsrk.dll file.  It is extremely unusual for it to be corrupted and behave the way you experienced.  It would be just as common as any other of the files(NI or non NI) becoming corrupted and causing unusual system behavior.  Now that you have wiped your system clean of the corrupted file and re-installed the driver you should be able to add in the continuous monitoring of your digital inputs.

[Redrabbit]

Have tried reinstalling to no avail, system is still rebooting sporatically.  I disabled the attached portion of code which checks a couple of digital inputs every second and the system runs fine.  One thing to keep in mind is that my application actually is four of these loops created from a template running in parallel so when I disable one I'm disabling all four.  I'm going to try downgrading to 8.5f5 version of DAQmx to see if it is limited to this particular installation, any other ideas would be appreciated.

Thanks,

Randy

[Ima U]

Hi Randy,

I would like you to post your code.  It sounds like you may be setting up 4 tasks that use the same resource.  This normally would cause a error so I am curious to find out why your system sporadically reboots.

[ehecht]

Has this issue been resolved?  I am having similar problems (sporadic crashes with the dump file pointing to nixsrk.dll) using LabView 8.5, Ni-DAQmx 8.6.0f6, a NI PCI-6723 and a NI PCI-6255.  I tried repairing the driver as suggested, but the computer crashed after repair.

I have two tasks configured to read channels from the PCI-6255, but the error out from one read is wired to the error in on the next, which I thought should make it so they don't access the hardware simultaneously.

thanks,

Ethan

[tnek]

Hi Ethan,

I was wondering if you could provide some more information about your code. You mentioned two inputs tasks on the same board. Is one of them an analog task and one a digital task or are both tasks of the same type? DAQmx should not allow you to reserve resources for two types of the same type. If this is the case, you can refer to this article to get a little more information about the error you should be getting. If you could merge everything you need into one input task, this should clear the error. Let me know if this helps.

Regards,

Kent

Applications Engineer

[ehecht]

Hi Kent,

Both tasks are analog reads, but for one set I'm making differential measurements, and the other set are RSE measurements.  I'm not getting any error messages, and quite often the code runs fine, however every once in a while the computer freezes and I get the blue screen of death. 

I understood that when you have an analog read on its own that it will start and stop the task automatically...is this assumption correct or should the analog reads be bracketed by start and stop tasks to insure that the hardware is available?

After looking further at the link you provided, I guess the right answer is to combine the measurements into one task as is outlined here: http://sine.ni.com/devzone/cda/epd/p/id/899.

Ethan