ExtensibleStorage.SchemaBuilder.AddSimpleField() causes "ArchiveException 106"

[jason.earl634Z5]

This issue is triggered by a third party plugin. I'm hoping to find out what "ArchiveException 106" is or some sort of possible further troubleshooting to try.

Background information:

• The issue only occurs for 1 user, many users at the company are using the plugin and multiple users using the plugin are working in the same projects as the user having the issue.
• The user has 2 Autodesk accounts, the issue only occurs when they are using 1 of the accounts. The issue does not occur when they are on the other account.
• The issue occurs in all projects the user opens.

From the journal file the issue appears as,

An ArchiveException 106 is raised at line 661 of E:\Ship\2023_px64\Source\Foundation\Utility\Archive\DataDict.cpp

From the plugin debug log the issue appears as,

... - Autodesk.Revit.Exceptions.InternalException: A managed exception was thrown by Revit or by one of its external applications.
... -    at Autodesk.Revit.DB.ExtensibleStorage.SchemaBuilder.AddSimpleField(String fieldName, Type fieldType)

Troubleshooting steps tried so far,

• Deleting the extensible storage objects created by the plugin. The thought is perhaps the objects became corrupted so deleting them and allowing the plugin to recreate new ones may resolve the issue, this did not work.
• Audit the model
• Disabling the plugin. This resolves the issue but the problem to solve is having the plugin not causing the issue for this user, this issue does not and has never occurred for any other user of the plugin.
• Switching to a different Autodesk account. This does resolve the issue but project requirements require the user to use the specific account that has the issue.

[jeremy_tammik]

Wow. Thank you for the detailed description. That sounds pretty weird. I does sound pretty specific to the add-in being used. Have you discussed this with the add-in vendor? However, an internal exception does hint at an issue with Revit, so I also passed it on to the development team for you. Some significant extensible schema enhancements were implemented in Revit 2024.2:

• https://thebuildingcoder.typepad.com/blog/2023/11/revit-20242-update-with-uda-preview.html#3

I guess that won't help much in your case, though. Let's see what the development team comes up with.

[jason.earl634Z5]

The company I work for is the add-in vendor in this case (we are ADN members if that makes a difference). We have not seen this issue with any other customers. Thank you for passing this on to the development team!

[jeremy_tammik]

Brilliant. I assume you cannot move on to Revit 2024.2? So, can you confirm that the ArchiveException is something registered by Revit itself, not your add-in? Internal exceptions should be internal, so this should be enough to motivate the development team to take a closer look. Do you call the AddSimpleField method in many places, or is it isolated? Can you share all the relevant code snippets that might influence its behaviour? Oh, and by the way, could you correct the typo in the title of your post? Thank you!

[jfaulkner-evolve]

Hi Jeremy -

We support all versions of Revit currently supported by Autodesk, so currently 2021-2024. This particular customer's issue is when running in 2023.

To answer your questions, I have confirmed:

• We are not registering, throwing, or handling "ArchiveException" in any way within our code. In other words, this entirely bubbled up from Revit.
• There is only a single place in our code where we are calling "AddSimpleField" as it relates to how we are storing this type of data. More specifically all ExtensibleStorage (read and write) are handled through a common method which is used throughout the entire application. This logic has been unchanged for years.
  • We have (guessing) 20+ different schemas we are adding/using in our application which all ultimately execute the method in question. Some are project specific (all Revit users access the same schema) and others are user specific (each user has their own schema). This error seemingly only impacts the user specific schemas and for this user only.
• If the code needs to be shared, I cannot post it here (we can discuss separately if this is actually needed) as it is highly modular for reusability. In other words there isn't an isolated section I can paste here which is unique to where this error bubbles up - it bubbles up through the common method which all features share, but for some reason only in this case (hence the reason for this thread).

I hope this helps. If you need additional information, please let ask.

[jeremy_tammik]

Well, surprise, surprise, they came up with a plausible answer for you:

There is a known improvement logged in REVIT-156791. The issue is "the `fieldName` is too long". The current limitation in Revit is we only accept the field name with length less than 63. Why does the issue only happen on one specific user account? Please ask the user to check with the plugin owner about the `fieldName`. It is possible that this `fieldName` is generated based on the current user name.

Another issue that can occur, given the following code to set up 3 simple fields for the schema and set the documentation for those fields:

FieldBuilder theVersion = schemaBuilder.AddSimpleField(VERSIONFIELD, typeof (int)); // create a field to store the version number
FieldBuilder theData = schemaBuilder.AddSimpleField(DATAFIELD, typeof (string)); // create a field to store the data
FieldBuilder isZipped = schemaBuilder.AddSimpleField(ZIPFIELD, typeof (bool)); // create a field to store the data
theVersion.SetDocumentation("The version number of the schema of the stored data.");
theData.SetDocumentation("The data as XML serialized, possibly zipped and base64 coded string.");
isZipped.SetDocumentation("Whether or not the stored data has been zipped.");

The failure/crash comes on the first `SetDocumentation` call. The issue has to do with the way fields get added on each call to `AddSimpleField`. Internally, the fields are stored in a dynamic array and the return value of `AddSimpleField` is a pointer to the entry inside that array. Subsequent calls to `AddSimpleField` will add new entries into this array and return pointers to those. The problem is that each "add" is going to trigger the array to be "resized". This means that it is essentially reallocated and all entries moved to the new allocation. Thus, any reference pointers at that point are now pointing to the wrong/deleted thing. That can cause a crash as that memory has been written over to catch this case; release builds may seemingly work, but the memory is not the write (right) memory to place the string in.

In general, when working with schemaBuilder and adding fields, it seems best to add the field, set its properties, then continue onto the next field etc. The code above can be fixed as follows:

// create a field to store the version number
schemaBuilder.AddSimpleField(VERSIONFIELD, typeof (int)).SetDocumentation("The version number of the schema of the stored data.");
// create a field to store the data
schemaBuilder.AddSimpleField(DATAFIELD, typeof (string)).SetDocumentation("The data as XML serialized, possibly zipped and base64 coded string."); 
// create a field to store the data
schemaBuilder.AddSimpleField(ZIPFIELD, typeof (bool)).SetDocumentation("Whether or not the stored data has been zipped.");

[jfaulkner-evolve · Accepted solution]

@jeremy_tammik , thanks for the follow up and details.

It does appear that the field name exceeds 63 characters so that is likely the problem.

However, we are using the "AcceptableName" method the verify the name before we use it and it returns 'true' with the value which is failing, incidicating Revit should accept it. As you can see the documentation for this method (I have copied the Remarks section) says the field can go up to 247.

Is suppose this method cannot be fully trusted and we need to suppliment it with a "Length<63" check as well?

https://www.revitapidocs.com/2023/0ac1f229-14e3-6039-22f1-1d6b40a000de.htm

> For interoperability, names are required to be usable as C++ identifiers. The allowable characters are ASCII letters, numbers (except the first character) and underscore. The length must be between 1 and 247 characters.

[jeremy_tammik · Accepted solution]

Yes, sorry about that. Too many cooks spoiling the broth... Thank you for pointing it out!

[jeremy_tammik]

And yes, an additional test for length < 64 is probably in order here... or < 63?

[jeremy_tammik]

They confirm that there is a disconnect then with the allowable length of field names in Schemas and what the underlying Storage mechanism in Revit allows. The 63 character limit is in the names of items that get serialised and since field names map to that, they then should also follow that limitation, so either:

• Schema ValidateName gets updated and documentation updated to limit to 63
• Update the limitation internally itself