To answer the other questions:
I guess it somehow tries to convert old data to new format.
It's possible this is what happened, though I'm not sure *how*. I use the same machine, same labview version for everything. All of the clusters I use are typedef'ed, and theres nothing weird like "class being instantiated by loading XML data from text file" that could cause this.
Try to force recompile class VIs and caller VI - Ctrl+Shift+Click Run arrow.
Did this, crash still happened. Was hoping it was just a compiler issue...
Does it happen when running VI or opening VI in dev environment?
I tried to reproduce when running with Highlight Execution, and also with lots of probes and breakpoints, but was unable. I'm guessing this means it may have been a race condition of some kind, but a highly reproducible race condition.
Are there any dynamic VI loads (by template that have not been updated for example)?
Nothing dynamic in the sense of "open VI reference from runtime-generated string", nor any VI templates going on. The application consists of almost 2500 VIs, many of which are dynamically dispatched from parent classes.
Is there manual data transformation from some generic form (string, variant, etc).
There is. All of my queues and user events have a single variant for data fields, but everywhere I have a "variant to data", I also have appropriate error handling and logging. I didn't see anything anomalous about this in my logs, though.
Will simple test vi that calls the class fail?
Well, there are probably 10 different main class objects in this VI that run simultaneously (sort of like a bunch of queued message handlers). From what I could tell of basic testing, nothing was misbehaving, although I was only running simple unit tests, and not integration tests. Before I ran integration tests (they take a while), I reinstalled, and that fixed the problem.
Can you delete that element from class data, will it make it work?
Tried it, still crashed. Very strange, I know.
