Okay this is odd. I had this reproducing on a colleague's cRIO last week. I switched cRIO's and made sure I have versions 17 of everything installed (same as before). I was going to update my Open Device Protected, to make sure the RT application no longer crashes, but now when I run the RT main I get the attached error and thus can no longer reproduce the crash on this new cRIO 9066. Have you seen this error before? I haven't made any changes besides moving the dependencies and the RT main to the new cRIO.
Also attached is a screenshot of my project explorer.
That error is an expected one if the RT doesn't crash. The crash will show that it is disconnected from the target, a non crash will result in that error coming through because the helper loop (the one with the dequeue) quit before being issued a quit command. I was just ripping out the code from smaller test projects trying to minimize it for posting purposes and so I forced that helper loop to just quit on its own resulting in the error you see.
Well I do hope you can reproduce the issue. As I stated my target is a cDAQ-9132 and I attached the reports from MAX so you can see the configuration it has.
Awesome, I got it reproducing again and can verify that adding an obtain queue removes the crash. I will discuss this crash with some colleagues before submitting a CAR, and will post here with the CAR number when I have it.
There definitely seems to be odd behavior with the way invalid or absent references are being dequeued causing an RT crash. This definitely could be a bug since after speaking to colleagues it does not seem like this should be expected behavior, so I think the best option here is to file a bug report service request at ni.com/support. You can link this forum post in the problem description.
I don't mind going through and opening a service request, but the issue is reproducible, and you agree that an unexpected crash is not the correct behavior so why can't a CAR be generated here?
A service request can be more easily tracked by R&D and our AE department internally than a forum post. Also, just to be completely transparent, I am not familiar with LabVIEW OOP at all (did not even realize the project had OOP stuff until a colleague pointed it out end of last week), and thus a ticket opened with someone from our RT team that is more familiar with OOP would be better suited to address this potential bug and document the CAR. I'm sorry for the inconvenience, but I just want to make sure R&D has a contact from our support department that fully supports all the components of this crash.
Quick update. After some discussion a CAR was assigned to this, CAR #668124, which claims to have been fixed in XNet 17.5. I haven't updated and tested it yet but intend to.