Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Crash in mxsout.dll after powering up cDAQ

Hello everyone,

I have an equipment[-controlling application (Windows7-64bit/Visual Studio 2012/C++/DAQmx), which can toggle the power turning the hardware on/off. It works fine, but what happens as soon as the power is turned on, is the miserable application crash due to the notorious access violation error. The debugger points out at the mxsout.dll, Somehow it gets loaded automatically even though the application loads the NI driver "manually" - using LoadLibrary()/FreeLibrary() API - and at the time of the crash the driver itself is unloaded. The mxsout.dll (and mxs.dll & Co) though seem to be loaded despite the application's attempts of controlling the loading process - and cannot be unloaded (can it?) by request.

I would not care how this library gets loaded, unless the crash occurred... therefore the questions:

1. Am I correct assuming that powering cDAQ up may cause the application crash if the mxs*.dll is already loaded into the application space?

2. If the answer is "yes" how to fight this problem?

3. If the answer is "no"... I do not even know how to get beyond that crash report reference to mxsout.dll.

Thank you!

Mike

0 Kudos
Message 1 of 15
(4,695 Views)

Hello Mike, 

 

What version of DAQmx are you using and what controller/chassis are you using? And what's the specific violation error you're getting? 

0 Kudos
Message 2 of 15
(4,670 Views)

Hi Haley,

thanks for your response and interest.

1. DAQmx version is 14,1

2, Device connected is cDAQ-9174 with two modules in it: 9205 and 9263.

3, Unless I make special provisions in my program in order to avoid calling any DAQmx functions, the mxs.dll as well as mxsout.dll get loaded as soon as I call that sort of function. If at that time the chassis is powered off, the program just does not return any meaningful answer, which is OK - this situation is assumed to be valid. But as soon as I press a "Power" button, the app. crashes. It throws a message like in the attached screenshot Screen1, and when I choose the "Break" option, it throws the message shown in the "Screen2". If I guarantee though that as soon as the device is powered off, no calls are issued, everything works fine...

Best regards,

Mike

Screen1:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Screen1.jpg

 

 

Screen2:

Screen2.jpg

0 Kudos
Message 3 of 15
(4,664 Views)

Thank you for additional information.

 

It looks like your screen shots did not get attached to your post.

 

Also is this new application for is this existing application that worked before. Additionally, are you closing references in your code?

0 Kudos
Message 4 of 15
(4,623 Views)

Thank you for additional information.

 

It looks like your screen shots did not get attached to your post.

 

Also is this new application for is this existing application that worked before. Additionally, are you closing references in your code?

0 Kudos
Message 5 of 15
(4,620 Views)

Hi Miro,
the screenshots can be visible right inside my reply, despite an accidental gap between the text and images after the text (at least I can see them when I open the thread).

The application is old, but we started using the cDAQ recently while we used plug-in (PCI or PCIe) boards before. As a result the communications routine had to be changed - and that is when the problem seemed to appear.
What do you mean asking about "closing the references"? Could you explain this in more detail?

Thank you in advance,

Mike

 

0 Kudos
Message 6 of 15
(4,616 Views)

Hi Miro,

just in case you are still unable to see the screenshots:

1. The first is a "regular" Visual Studio notification stating "Unhandled exception at <address> in <App>: 0xC0000005 :Access violation reading location <address>;

2. The second screenshot shows the window, which pops up when I choose a "Break" option in the previous notification. It says: "mxsout.pdb is not loaded". Module information: Version: 14.00.1.49152 Original Location: C:\Program Files\National Instruments\MAX\mxsout.dll

Not much, actually...

Mike

0 Kudos
Message 7 of 15
(4,614 Views)

I am not sure if this is the answer but i am curious if the code is allowing enough time for the device to intiate and boot up.

 

Is it possible for you to include some wait time before the code executes?

 

Does the problem go away if you remove on/off functionality from your system?

0 Kudos
Message 8 of 15
(4,582 Views)

Hi Miro,

the thing is that at the time it crashes my code is doing nothing. I start the app, it checks the DAQ presence, and cannot locate it (the cDAQ is unpowered). During this attempt it loads mxs.dll and Co. At this time everything seems to be fine. What I do next is powering on cDAQ, while the program sits idle - and BOOM! it crashes the way I described previously. If I avoid making the check using additional means allowing me to figure in advance whether the board is powered or it is not, then no crash happens.

Thank you,

Mike

0 Kudos
Message 9 of 15
(4,579 Views)

The best practice is to have hardware ready and loaded before you run any application. To be honest with you I have never worked with application that runs before HW initiates. Every DAQmx code has some form of HW initiation so I am wondering if your code is idling after HW initiation and therefore it is causing this crash after actual hardware gets detected.

0 Kudos
Message 10 of 15
(4,556 Views)