I neglected to update this thread with the resolution of my problem. It was as follows:
We eventually isolated the issue to a very large enum. (1950 defined values and about 56,000 characters of associated character data.) In order to save a file on disk, the data structures must be serialized. I assume the process used is the same that is exposed in the Flatten To String G function. The serialized data format uses unsigned 16-bit integers as internal pointers, with the result that no single cluster or class can have type descriptor data longer than 64 kwords.
We knew we were fairly close to the limit but everything worked fine in LabView 8.6, so we had deferred addressing this. LabView 9 apparently made some changes in how data is flattened/unflattened (perhaps associated with versioning in classes) and it could no longer handle a class containing such a large enumerated type. (LabView 9 could load the enum by itself without problems; what it could not do was load the enum inside a complicated class.) Rather impolitely, LabView 2009 silently tanked on VI load rather than identifying the problematic structure. (This part is going to be addressed: NI employees see CAR #185348.)
This issue was quite difficult to isolate because of the cross-linked nature of LabView libraries and classes. Although I knew a particular class induced the crash, loading any method of a class loads every method of the class, as well as any parent classes and subclasses and any VIs present in any library used by the class. This meant that isolating the problem to "class x" really only reduced the scope of the problem to one of about 450 VIs and controls. I will avoid derailing this post with a rant about the nightmarish dependency issues introduced with LabView libraries, but suffice it to say that libraries have caused me many more problems than they have solved.
In the end was necessary to strip everything out of the class so that LabView 2009 could read the class, then add things back in until it broke. This was slow but ultimately successful. (I should remind everyone to use a source code control system: it would be unthinkable to do this kind of slash and burn debugging without one. We use subversion.) I want to thank applications engineer Mark Eadie at NI for working on this problem with me.
In the end we refactored the single large enum into a composite structure. This change had to be made in LabView 8.6. Once that change was made, we were able to load the project in LV 2009.
-Rob
