0x80000003 Real-Time exception

[CarmineS]

All,

I have a RT program (LabView RT 2011) that has been running fine on a PXIe-1062Q chassis. When I run the same code on a second identical chassis it crashes. I have identified the vi that causes the crash, but it only does it when a second vi is loaded.

So if I don't load the second vi the first does not crash.

Again the same code has been running on another chassis for 6 months with no issues.

Any ideas?

thanks

Carmine

[Kilometers]

Hi Carmine,

Is the VI that causes the crash a built in LabVIEW function, or one of your own design? What is this VI doing? Are you using the same controller between these two chassis or no? The controller is usually the primary point of concern for real time programming rather than the chassis. Do you have the exact same software installed on the two controllers if there are two different controllers? Can you take this VI back to your original chassis with it's original configuration and have it not crash still, or does the code no longer work on either chassis? 

[CarmineS]

Hi Miles,

The controller is the same (PXIe-8133).

The vi is a custom one using FIFO's

Same software on both, Copied from the 1st to the second and compiled independently (i.e.. the code is compiled on each chassis and run)

Original chassis works fine.

Thanks,

Carmine

[Texas_Diaz]

Error 0x80000003 is a BUGCHECK error, which happens when the OS is asked to do something it cannot do without causing fatal harm to the running system.  There are multiple situations where we throw the bugcheck, but the vast majority of them happen when using user-created DLLs that blow the limited function stack or cause MSVC to call ExitProcess().

Sometimes when 0x80000003 gets issued, an rtlog dump is created - this file will exist in /ni-rt/system and will be named rtlog.txt.  Can you look to see if this file exists?  This can help us determine what happened to cause this bugcheck to be issued.

-Danny

[CarmineS]

I found the file and it looks like it keeps appending data to it.

I did see one thing in the memory statistics that may be a problem. The "Free RTOS heap memory:" is zero.

How can I evaluate the rest of the log?

thanks

[Texas_Diaz]

"Free RTOS Heap Memory" is a "legacy" item - depending on the platform it could be nonzero, but on any controller newer than a PXI-8106 the "Free RTOS Heap Memory" is zero because we don't use the "legacy heap" any more.  We kept that output so we'd know which memory manager we were using under the hood.

You are correct, the file is appended.  You unfortunately aren't meant to evaluate the log - National Instruments doesn't publish the format or contents of the log file; that log is intended to be given to National Instruments to help determine what happened.  However, anyone who's ever looked at dump files in a debugger can probably make sense of the file fairly quickly - it contains a few important pieces of information such as a list of loaded modules, a stack trace of the crashing thread, and other helpful information you can use to debug crashes (if you have the proper tools and symbol files, which are not published).  

The log files do not expose any user code or IP, so they're safe to attach to a public forum.  Do you mind attaching the file (if it's small enough to attach)?  I can at least give you a quick "back of the napkin" root cause if you can post the file.  If it's too large, delete the file and cause the crash to happen again, and post the new file.

-Danny

[Carmine[S]]

Well, the answer was memory. The code deploys fine but crashes because of insufficient memory. After the memory was increased thru HyperVisor Manager it now runs.

Thanks to all who responded.

Carmine