DWarn 0xC1EAEA9C Internal error 2 occurred

[sfrosty]

My application that is running on a cDAQ 9135 embedded LINUX system gets the following error:

"DWarn 0xC1EAEA9C: Internal error 2 occurred" and the application stops.

What does this error mean? Thanks!

[Jacobson-ni · Accepted solution]

I found a few old bug reports but most of the problems are fixed and pretty generic (similar to memory access violation) so we probably won't be able to guess the root cause without seeing any code. Is this a crash that just recently started to happen? What changed from when there was no crash to the current state of the system? Does this happen immediately on startup or at a specific code path in your application?

Taking a shot in the dark there was a recently reported issue with using classes on Linux RT targets so if you are doing that it might be worth looking into what is going on in that bug report.

[sfrosty]

It started happening after transferring the code from a Windows 7 embedded cDAQ to a LINUX cDAQ. I never saw the error with the Win7 embedded system. Not saying it never happened, but don't remember seeing it. It's been awhile since I ran that system and it was development also.

The timing appears to be random. Earlier it ran for about a half hour before stopping, recently it ran for an hour and a half. I'll start bypassing functions and loops and see if I can pinpoint. Not using classes.

Just increased the sample rate of one of the acquisition channels and got a "acquisition can't keep up with hardware acquisition" error; investigating. What's interesting is that the 2 acquisition buffers, which are output to indicators, appear to be emptying normally so wouldn't expect the error. I just eliminated the wait functions in the loops to see if they may be having an affect.

I have 2 acquisition loops feeding a data transfer loop. One acquisition loop acquires data from a 9322 module with microphone input, converts to 1/3 octave bands from 20 to 20K Hz and the other loop acquires data from five 9320 modules with 15 accelerometer inputs, and converts outputs to peak values. Both loops then output data through queues to a loop which outputs the data through a CAN 9826 to another cDAQ 9132 with CAN module input and displays the engineering values. 

[sfrosty]

---

@Jacobson-ni wrote:

I found a few old bug reports but most of the problems are fixed and pretty generic (similar to memory access violation) so we probably won't be able to guess the root cause without seeing any code. Is this a crash that just recently started to happen? What changed from when there was no crash to the current state of the system? Does this happen immediately on startup or at a specific code path in your application?

Taking a shot in the dark there was a recently reported issue with using classes on Linux RT targets so if you are doing that it might be worth looking into what is going on in that bug report.

---

CODE GENERATING ERROR DEPICTED ABOVE

[sfrosty]

---

@Jacobson-ni wrote:

I found a few old bug reports but most of the problems are fixed and pretty generic (similar to memory access violation) so we probably won't be able to guess the root cause without seeing any code. Is this a crash that just recently started to happen? What changed from when there was no crash to the current state of the system? Does this happen immediately on startup or at a specific code path in your application?

Taking a shot in the dark there was a recently reported issue with using classes on Linux RT targets so if you are doing that it might be worth looking into what is going on in that bug report.

---

It was a memory issue involving a queue. I had an open ended queue gathering data but never being read. Thanks for your help! Another participant (wiebe@CARYA) had found it in another thread I had posted Re: "Application stops for no apparent reason".

Thanks again!