Attempted to read or write protected memory when running RhinoCore inside Revit 2026.
We’re launching RhinoCore from a .NET add-in, and it was working fine in previous versions of Revit, including 2025, but in 2026 we consistently hit this error, right after calling new RhinoCore().
var args = new List<string> { "/nosplash" };
if (Resolver.Version == 7)
{
args.Add("/netfx");
}
if (Resolver.Version == 8)
{
if (App.RevitVersion >= 2025)
{
args.Add("/netcore");
}
else
{
args.Add("/netfx");
}
}
RhinoCore = new RhinoCore(args.ToArray(), WindowStyle.Hidden, Autodesk.Windows.ComponentManager.ApplicationWindow);
Anyone from McNeel aware of this? Any known workarounds or things to check?
We’re using RhinoCommon through Rhino.Inside in our own plug-in, BEAM.
If Rhino.Inside.Revit is installed, we detect and use that without any issues.
However, if the user doesn’t have RIR installed, we need to be able to start RhinoCore independently, and that’s where we’re running into trouble, especially in Revit 2026.
I understand your point, but that’s not really an option for us.
We don’t want to enforce Rhino.Inside.Revit.
Not only do we check if Rhino.Inside.Revit is installed, but even before that, we check if RhinoCommon is already loaded to avoid any conflicts from our side.
Honestly, I’d expect most developers to follow a similar approach!
What’s puzzling is that everything works fine in Revit 2025, and we’ve done everything needed to make sure it runs there. But with the same setup, Revit 2026 fails.
We’d really appreciate some guidance on this, what’s changed in 2026 that could be causing the issue?
Rhino.Inside.Revit enables any AddIn to call RhinoCommon without any other change than reference RhinoCommon Nuget.
Doing that from your side you are making the other AddIns that are currently using it more complex and breaking existing ones.
Why is not an option to require it?
Would it help if we help you streamline the installation programmatically?
May it help if we include it on the Rhino installer?
We could look into that yes, if McNeel makes it easier to have it available generally, it won’t harm!
Still, I kind of have to insist that having a fallback that can run independently would be great so we can always make it work so users can carry on working.
We have a few thousand users relying on this daily, with very few issues, and if foremost important for us to have less points of failures as possible.
Was it a big change for you to make it work? I understand it might be hard to help with this issue here on the forum.
Done, your AddIn can call RhinoCommon without conflicting other AddIns the user want to install.
The other way around is, every AddIn has its own startup mechanism that is much harder to support for everybody.
Just some nice numbers, lets say there are 10 AddIns, on your way of doing there are 10x10 = 100 possible situations that may end up on a conflict. With Rhino.Inside.Revit installed there are just 10 possible conflicts on this specific aspect.
The other approach does not scale.
It may end up on a lot of support from our side and much more chances that the experience of users using RhinoCommon based AddIns is worst.
I would suggest the same to any other developer to lower the chances it conflicts with your AddIn as well.
That said, I respectfully disagree with the issue you’re suggesting. If another add-in is set up the way you recommend, then:
When they call RhinoCommon methods, RIR will activate, launch Rhino, and everything works as expected.
Our plugin detects that Rhino is already running through RIR and doesn’t attempt to start it again, we only initialize Rhino ourselves if RIR is not installed and, most importantly, not at statup.
If RhinoCommon is already loaded (either by RIR or by us when RIR isn’t present), there shouldn’t be any issue calling Rhino APIs. So the only conflict would happen if an add-in requires RIR but doesn’t install it, which seems like a setup problem on their end.
I was mostly hoping for some hints or guidance, especially since this same setup works fine in Revit 2025, but breaks in 2026. Still, I appreciate the response, it might be to complex to support.
The order Revit starts AddIns is not documented and may change.
So lets say your AddIn starts before RiR.
It starts RhinoCommon on its own then the rest of the AddIns included RiR fail to load.
The current setup allows any order, some AddIns may decide to make its first call to RhinoCommon an hour after Revit started, until then no Rhino license is picked.
I see your point, but I can assure you our setup already takes all of that into account and does not cause issues. We don’t launch Rhino at startup. It only starts when the user clicks a button to trigger a specific feature, by that point, Revit, RIR, and all other add-ins have fully loaded and we can check.
That said, we’ll keep investigating. I’ll take a closer look at the RIR GitHub repo to see if anything stands out. I just hoped you might have a high-level idea of what changed in 2026 compared to 2025 that could be causing this.
Imagine a situation were RiR is not installed and two AddIns do the same as you suggest.
The second AddIn will fail to work correctly, specially if it needs to show the UI or run Grasshopper.
My point is that two AddIns that follow the same approach you are after will have to solve their conflicts one by one between them.
I’d need to ship RIR with my install at this point then? I want to avoid asking the user to install when using the app, that would be disruptive. Also I am having issues with the latest version 1.31, it works but I don’t see the buttons in the ribbon and it’s not installing for 2026.
To avoid all these issues is why I wanted to have a system to launch it natively.