exception C0000005 in niNIESR100 tAllImmediateTapSupervisor

[kbowers1]

My test setup controls 2 ECUs per PC.  Each PC has 1 6024E PCI DAQ card.  The problem occurs when both applications are running.  If the name is indicative of what is happening at the time of the crash, one (or both) of the applications is trying to do something with the analog input.  As I mentioned before, the failure occurs after several days of execution (my application is an .exe).  I haven't tried to run it in debug mode due to the length of time it takes to crash and the fact that debug mode is too slow for my application.

I had gone through all my code after 7.1 of NI-DAQ was released and converted it from easy-io calls to DAQmx.  The result has been disappointing.  I definitely haven't seen any performance impovements and have had to add in a lot of extra code to prevent my two applications from accessing the card at the same time.  This was achieved with success in version 7.0 of LabWindows with version 7.3 of NI-DAQmx.  Now with 7.1 of CVI and 7.5 of DAQmx, I'm getting crashes that I can't track down.  Maybe if you could tell me what DAQmx functions call the tAIImmediateTapSupervisor::~tAIImmediateTapSupervisor I might be able to locate where in my program the crash occurs.  Anyone who has experience with multiple threads simultaneously accessing DAQ hardware might be able to help as well.  At this point in my code, I always check if the hardware is available and then I reserve it until the current task is complete.  I was under the assumption that this would prevent multiple access.

Ken

[Otis]

Hi Ken,

I'm currently trying to find out what that particular command does and why you are getting problems with it.  At this point I don't know if there is going to be a really quick fix, but I'll try to let you know what I can find out by the beginning of next week.

Regards,

[kbowers1]

Otis,

I went back to my old code (generated in CVI 7.0) which, to my surprise, behaved in the same manner as the problematic code generated in CVI 7.1.  I proceeded to remove the CVI 7.1 runtime engine and replace it with the CVI 7.0 engine.  So far, everything is working okay.

I'm not sure if this will help you narrow down the problem or not, but I am definitely concerned as I now can no longer develop new variations of my code since anything I develop in 7.1 requires the 7.1 RTE which will inevitably cause this problem.

Ken

[Wendy L]

Hello Ken,

Do you remember if you were using the CVI 7.1 runtime engine or the 7.1.1 runtime engine?  We're trying to isolate in which codeset the problem could possibly be, the DAQmx driver or a particular CVI function call.  The problem is that we have minimal documentation on this problem occurring before.  The last time it occurred, it was associated with a DAQmx call, but the fact that you mentioned this error does not occur with the CVI 7.0 RTE makes the problem that more evasive.  If you were using the CVI 7.1 runtime engine, would it be possible to try the CVI 7.1.1 runtime engine to see if the problem still exists in this version?

Thanks.

[kbowers1]

Wendy,

I was using the 7.1 RTE.  I will try the 7.1.1 patch but it may be a few weeks--now that the test is running I don't want to stop it.

Ken

[Otis]

Hi Ken,

I had a chance to speak with some other people about your issue and they had a few more questions that needed to be addressed so that they can get a better overview of what is happening.

Could you give me a little more information on how you are seeing this error?  A screen shot from Dr. Watson or something?  Also, if you can post your code, so we could take a look to see how you are getting to this line.  If you do post the code, please make sure that you give us all of the information concerning what hardware you are dealing with and what the basic overview of what it is that the code is supposed to do, so that we can best understand how you are using everything.

Basically, you should not be seeing this message, so we need to understand why you are seeing it and exactly how.

Thanks,

[kbowers1]

Please see attached document for the details from the event viewer for the Dr. Watson event that results in termination of the application.  There is no error message that pops up when the error occurs.  The application just shuts down with no notification.  If I go to the event viewer, I find the message given in the attachment.

As of submitting the code, I don't see any point in doing that until you can tell me what type of function calls could result in this crash.  That way I only need to send you what is pertinent.

Ken

[Otis]

Hey Ken,

I will pass this information along and see what other information I can find on it. 

Thank you for your patience,

[Otis]

Hi Ken,

I had a chance to talk with some of our developers and they had a few more questions for you:

This error appears to occur during the destruction of a task.  Are you doing single point DAQ operations?  There is a possibility that you are not synchronizing the threads correctly and that something in the CVI 7.0 RTE masked this problem.  Regardless of what happened we need some additional information

1. Are you doing error checking in your program?  It's possible that there is a missing resource reservation error or something which is causing this problem.  Can we see this portion of the code?
2. How are you synchronizing the tasks?  How is he preventing both threads from communicating with the card at the same time?  Can we see this portion of the code?

If you could help us figure out what is going on in these steps it would help quite a bit for helping us figure out what the root cause of your issue is.

Thanks,

[kbowers1]

See code exerpts attached for all analog inputs performed during software execution.  Task creation and destruction is done at a higher level but does not include any synchronization.