Severe Freeze in Revit When Using RhinoInside (Rhino 8)

Rhino.Inside Revit
1

I’ve recently encountered a serious issue when using RhinoInside.Revit.
Whenever I open a Revit file and then launch Rhino (even without opening Grasshopper), Revit completely freezes the moment I try to delete or modify any elements connected to ductwork. The entire application becomes unresponsive and can only be closed forcibly.The issue only occurs with duct-related categories; other MEP categories are unaffected.

I tested this extensively with:

  • Multiple versions of Rhino 8 (all minor versions)

  • Multiple versions of RhinoInside.Revit

  • Multiple versions of Revit (including 2020)

The problem appears consistently across all combinations.

Interestingly, this issue does not occur when using Rhino 7 with RhinoInside.Revit — only Rhino 8 triggers the freeze. This makes me suspect the root cause may be related to some internal changes between Rhino 7 and Rhino 8.

Any insights, suggestions, or discussions from experts in this area would be greatly appreciated.
Thanks in advance!

2

Hi Jimmy, this sounds like a plugin conflict. There are different troubleshooting methods depending on what version of Revit you are running. In 2025+ there is a plugin manager. In previous version you can use this addin.

3

Thank you very much for your reply, Japhy.

I disabled all other add-ins and tested with only RhinoInside.Revit loaded, but the issue still occurs.
However, when using Rhino 7, the problem does not appear even with all plugins enabled.

It seems this is not caused by any third-party add-ins.
I’ve attached a simple Revit 2020 file for you to test whenever you have time.

DUCT_test.rvt (5.3 MB)

4

What version of Revit are you targeting & what is your grasshopper file doing?

5

I’ve tested this in Revit 2020, 2022, and 2024, and the behavior is the same in all versions.
Also, this issue occurs even when Grasshopper hasn’t been opened at all — simply launching Rhino 8 is enough to trigger the problem.
If I don’t start Rhino 8, everything works normally.

6

This is 2024.3 and the latest Rhino 8. I’ll try another version or two but so far everything about the file is fine.

Please run SystemInfo in Rhino 8 and post the results. Thanks

image
image2139×692 96.3 KB

7

It’s not an issue caused by doing anything inside Grasshopper — the freeze happens when I manually delete or modify elements directly inside Revit.
I also just tested this in Revit 2023, and the same problem occurs there as well.

Here are my system and version details:

Rhino 8 SR25 2025-11-10 (Rhino 8, 8.25.25314.11001, Git hash:master @ 305475a429872768e321960d34ed215b72a0da18)

License details: Stand-Alone

Windows 11 (10.0.26100 SR0.0) or greater (Physical RAM: 64GB)
.NET 7.0.0

Computer platform: DESKTOP

Standard graphics configuration.
Primary display and OpenGL: NVIDIA GeForce RTX 3080 Ti (NVidia) Memory: 12GB, Driver date: 8-14-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 560.94

Accelerated graphics device with 4 adapter port(s)

  • Secondary monitor attached to adapter port #0
  • Windows Main Display attached to adapter port #1

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
GPU Tessellation is: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 8-14-2024
Driver Version: 32.0.15.6094
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 12 GB

8

How about Grasshopper Plugins? something loading .netcore into your Revit 4.8 runtime environment?

9

Hi Japhy,

I tried launching Revit with all GH plugins removed, but the problem persists. Everything only works normally when I switch back to Rhino 7.

However, I really need to use Rhino 8 because I rely on the GHPlayer window persistence feature.

Have you been able to reproduce the issue where air ducts can’t be deleted on your end yet? Or do you think there might be other possible causes for this?

Thanks for your patience!

10

Everything looks fine in your file in various versions. Seeing that Rhino 7 works fine, it does look like a Rhino 8 plugin of some sort that is using .netcore, which wouldn’t be compatible with Revit 2024 & below. Have you tried Revit 2025 or above?

11

I haven’t tested it in the 2025 version yet, but your analysis makes a lot of sense.

What I still can’t figure out is why this issue only happens with duct elements in Revit.

How are they different from other categories? I just can’t wrap my head around it.:thinking:

13

I tested it again using Rhino 7. Even with GH loaded without any plugins and just opening the GH interface without doing anything on the canvas, the issue still occurs.
Deleting all duct elements at once works, but deleting just a single segment causes Revit to freeze.
If I load Rhino 7 without opening the GH interface, no this problem.

14

Let’s open grasshopper from the Rhino command line with GrasshopperLoadOneByOne and try to isolate the issue.

15

I also tried using GrasshopperLoadOneByOne to load GH without any native or third-party plugins, but the problem is still there.

16

Very odd that you are having issues in Rhino 7 & 8 with different Revit versions with 0 Revit addin and 0 gh plugins.

Lets get as much info as possible, please provide a screenshot of your RiR about info

Can you try opening RiR using the shortcut described here (opens a new instance of Revit with no other addins)

17

I tested it this way, but the issue is still the same.
There’s a new finding though: if I open Revit and draw a duct first, then any delete or edit operations won’t freeze Revit anymore.

I’ve tested this on five desktops and two laptops used by different people.
Below are the version details installed on my current laptop.

image
image473×180 4.4 KB

18

Ok, I was able to repeat per the instructions in Revit 2020, thanks for reporting!

19

Hi Japhy,

Any progress on the issue above? RiR is essential to our team—using Rhino as a backend for geometric calculations is incredibly powerful. It enables us to run custom analysis (clearance, clashes, etc.) that AI simply can’t handle yet.

Looking forward to your update. Cheers!

a1a59d38d394626a131480d849e3ec4a
a1a59d38d394626a131480d849e3ec4a1565×617 153 KB

20

Hey Jimmy. The issue is still marked as still open. I’ll bump it at our next dev meeting.

21

Additional info (I can reproduce this reliably)

Environment: Revit 2020, RIR built from source, tested with both Rhino 7 and Rhino 8 (.NET Framework 4.8.1).

Symptom: Same as reported — editing/deleting an existing duct freezes Revit. With Rhino 8 it happens as soon as RIR is active; with Rhino 7 only after Grasshopper is loaded (even just opening the Player file dialog and cancelling — no .gh file needs to be opened or solved). Journal shows:

REGEN_DOC_CONTEXT_INFO: Changing wrong atom in regeneration
REGEN_DOC_CONTEXT_INFO: Document is changed in regeneration while it is not supposed to

What I tried: Individually disabled and rebuilt with each of these removed: Idling/DocumentChanged handlers, the active-view refresh loop, PreviewServer registration, ActivationGate.Enter/Exit, CanvasCreated (which also prevents the RIR .gha component library, including the Element Tracking/IUpdater system, from ever loading), and the GH solution TransactionGroup wrapping. None of these changes had any effect — the freeze still happens even with essentially no RIR-authored handler active.

Debugger findings: Attaching to the frozen process, the main thread is stuck at the exact same spot every time (a true hang, not a slow computation):

FittingAndAccessoryCalculationManaged.dll!..._clsASHRAEDuct...CreateInstance

This is Revit’s own native COM module for duct fitting calculations, not managed RIR code. No other thread shows any RhinoInside/Grasshopper frames at the time of the freeze.

My current guess: This isn’t caused by any specific RIR event subscription — it looks tied to RhinoCore being loaded in-process (or Grasshopper being loaded via PlugIn.LoadPlugIn), independent of any GH document being opened. The hang itself is inside Revit’s native COM object creation, which suggests a low-level conflict (COM apartment / message pump) between the embedded Rhino runtime and Revit’s native calculation module.

Happy to share more debugging details if useful.