Revit 2026 hangs after upgrading a family

[cadferret]

We have been observing an easily reproducible problem with Revit 2026 where it hangs while trying to upgrade family files (.rfa) created by older versions of Revit.

Detailed information about reproducing the problem is in the attached zip file.

Could you please pass it on to the developers?

[jeremy_tammik]

Nope, sorry. This forum is for discussing your programming issues making use of the Revit API in your own add-in. Your case is more appropriate for end user support. Please raise it in the larger and more generic Architectural forum. I believe they provide end user support there.

[cadferret]

Jeremy,

Thanks for replying. But, could you please clarify, why exactly is this case not appropriate for this forum?

This situation occurs specifically when using Revit API (as described in the attached zip file), and affects applications (addins) that are using that Revit API function (Application.OpenDocumentFile).

[jeremy_tammik]

I only read your message, not the zip file. If you are using the Revit API yourself, then, of course, this place is perfectly appropriate for the discussion. Sorry, please excuse me. 

[cadferret]

No problem. So I hope this case can be forwarded to the appropriate people? There is a very detailed technical description of the problem in the zip file.

For those interested who don't want to open the zip, Revit 2026 often hangs while using Application.OpenDocumentFile on a family created with an older Revit version followed by a call to any .NET function that would internally try to wait for the finalizer thread to do its work. This is possibly related to message processing done while temporarily showing the upgrade dialog. (It cannot be completely excluded that some very widely used 3rd party component could be responsible, but Autodesk developers would probably be in the best position to see if it's "their" problem or not, at least.)

[TripleM-Dev.net]

I guessing the calls to GC.** is the cause.

[cadferret]

Why would you think so? (In any case, of course, they aren't. The use of those functions in the demo code is only a way to expose the problem, make it easier to reproduce. Any .NET function that internally waits on the finalizer thread will lead to the same problem.)

[TripleM-Dev.net]

Use Dispose where available (document as IDisposable) or Using for managed code?

"Expose the problem", so a memory issue is why Revit "Hangs" and WaitForPendingFinalizers forces the issue?, Does revit crash?, Does Revit keep CPU running or is it idle?

What have you tried to narrow the issue (Revit, Windows, Network etc...)

- Examined the Revit Journal, does it provide some clue?

- Try the actions in Addin in the UI manually, does that work?

- Any issues with one or more families (Catching the Revit warnings / errors related to families?)

- Does it work in R2025 (or earlies versions) without the R2026 issue?

- What happens if R2026 families are used, so no upgrade is needed?

- etc...

Remark to the sample code:

All families are loaded in one loop, howmany are opened? For 100, of 1000 families this can be a memory issue (don't know if Revit can handle 100 open families in a session)

Then the GC calls

And then closing of the families...without saving

I would suggest loading the families one at a time and close in same loop.

[cadferret]

> Use Dispose where available (document as IDisposable) or Using for managed code?

How is it relevant here? (Not in general, but for this particular case for which sample code is available)

> "Expose the problem", so a memory issue is why Revit "Hangs" and WaitForPendingFinalizers forces the issue?, Does revit crash?, Does Revit keep CPU running or is it idle?

No, the problem is that finalizer thread is blocked forever (trying to cleanup an RCW, which requires it to call to the main STA, and never getting response) after the call to Application.OpenDocumentFile, if the family file passed to it was of an older version and needed an upgrade.

Explicit calls to GC are needed only to demonstrate the problem (show in an easily underestandable way that the finalizer thread is blocked):
- GC.Collect puts the RCW to the finalizer queue if it was not there yet
- GC.WaitForPendingFinalizers simply waits for the finalizer thread to finish calling pending finalizers (in the way that allows incoming calls to the current apartment, so it itself can't cause the deadlock that way)

> What have you tried to narrow the issue (Revit, Windows, Network etc...)

It's been reproducible by everyone who tried it so far, in plain Revit 2026 without any 3rd party addins etc. (As I mentioned earlier, I can't rule out an effect of some widely used 3rd party component like DirectX, for example, but it's much more likely that Revit is responsible, naturally. At least, it would be much easier for Revit developers (than for us) to at least see that f. ex. they are not accidentally dropping messages used for cross-apartment COM calls somewhere)

> - Examined the Revit Journal, does it provide some clue?

Yes, nothing relevant there.

> - Try the actions in Addin in the UI manually, does that work?

Revit is not responding, as described. (In the real life case it is also not responding in a basically the same way, since many .NET functions internally wait for the finalizer thread to finish, f. ex. Join() functions, so it's enough to call one on the main thread, and Revit hangs.)

> - Any issues with one or more families (Catching the Revit warnings / errors related to families?)
> - Does it work in R2025 (or earlies versions) without the R2026 issue?

Any family (created with Revit 2025 or older) can be used to reproduce it, so it's not a problem with a specific family.

> - What happens if R2026 families are used, so no upgrade is needed?

The problem does not occur (as described).

> Remark to the sample code:

> All families are loaded in one loop, howmany are opened? For 100, of 1000 families this can be a memory issue (don't know if Revit can handle 100 open families in a session)

One. As mentioned in readme.txt, one family is enough to reproduce the problem.

(The loop is only to make it easier to use, no need to specify the name of the family etc., just put any families you want to test into that directory, and the test code will find them)

[cadferret]

In fact, GC.Collect() is not needed there either. So in the simplest possible way it can be reproduced just like this:

app.OpenDocumentFile("c:\\test\\anyfamily.rfa");
GC.WaitForPendingFinalizers();

But if I would post a demo like that, someone would certainly say that I'm not doing proper cleanup etc. 🙂

[cadferret]

As I suspected, during family upgrade, Revit does certain things with COM cross-apartment messages, and it does those things incorrectly. The problematic function is located inside RevitMFC.dll, and starts at the offset of 0x95970 from the beginning of the module (at runtime) for version 26.0.10.8. The code needs to be updated to properly recognize the messages of interest; the method it uses now is wrong (possibly outdated, or was never correct in the first place), and now it prevents the messages from being properly delivered to their destination and forces the sender in another apartment to wait forever.

I hope this can be communicated to the responsible developers?

I can provide any additional information if needed.

(Also, a simple temporary workaround can be made for this problem; if someone is suffering from this problem and needs a temporary fix, my contact info is in the zip file in the first message)

[jeremy_tammik]

What version are you using? Did you upgrade to Revit 2026.0.1?

[cadferret]

Yes, I'm using 2026.0.1

[jeremy_tammik]

I asked Gemini to create a summary of this thread to report to the development team. Can you please check what it comes up with to verify and confirm that it does indeed capture the gist of your intent? Thank you!
    

• https://g.co/gemini/share/16ffa2ea188b

[cadferret]

Yes, it looks good. Thanks!

[jeremy_tammik]

Oh I see you already noted the update version. I also already passed on the report to the development team.

[rensalicense]

@cadferret @jeremy_tammik is there any update on this issue? I am facing similar kind of problem.

[cadferret]

I haven't tested it myself, but I have received reports that it is fixed in the latest Revit updates (2025.4.3 and 2026.3).