11-06-2014 12:28 PM
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
11-07-2014 02:00 PM
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?
11-07-2014 02:51 PM
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:
Screen2:
11-10-2014 04:24 PM
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?
11-10-2014 04:25 PM
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?
11-10-2014 04:31 PM
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
11-10-2014 04:38 PM
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
11-11-2014 03:44 PM
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?
11-11-2014 04:00 PM
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
11-12-2014 12:47 PM
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.