'System.AccessViolationException' occurred in Rhino3dmIO.dll, InstanceDefinitionGeometry

I am building a tool where I am accessing the geometry of block definitions and instances. These are InstanceDefinitionGeometry and InstanceReferenceGeometry respectively in Rhino3dmIO.dll.

When I start working with these objects, it seems I regularly produce a ‘System.AccessViolationException’ in Rhino3dmIO.dll which results in my application to crash. The full message is:

An unhandled exception of type 'System.AccessViolationException' occurred in Rhino3dmIO.dll Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

It appears to be happening in even simple cases of accessing one or two InstanceDefinitionGeometry. Sometimes my code will seemingly complete and then the program will crash without an error message.

For example, here I am iterating over InstanceDefinitionGeometry and identifying breps and meshes in an Instance as lists of File3dmObjects. I am not sure why this would be problematic… is there anything special I need to be doing when dealing with InstanceDefinitionGeometry that would make it different than dealing with, say, a normal File3dmObject that is not tied to a block?

            foreach (InstanceDefinitionGeometry inst in instDefs)
                string name = inst.Name;
                Guid[] objects = inst.GetObjectIds();

                List<File3dmObject> brepObjs = new List<File3dmObject>();
                List<File3dmObject> meshObjs = new List<File3dmObject>();

                // get File3dmObjects of block objects
                foreach (Guid g in objects)
                    File3dmObject obj = _rhinoDoc.Doc.Objects.FindId(g);
                    GeometryBase geo = obj.Geometry;
                    if (geo is Rhino.Geometry.Brep)
                    else if (geo is Rhino.Geometry.Mesh)

             // start working with collected File3dmObjects


Sounds like a bug in Rhino3dmIo that I need to fix. Do you have a small sample that shows this behavior so I can be lazy?

Thanks @stevebaer
I can’t really isolate culprit code. I don’t know where it is since it crashes without any stack trace or message. ‘System.AccessViolationException’ appeared only a few times after the code seemingly completed to give me something to go on and clue me in on that it is something to do with Rhino3dmIO.dll.

I zero’d in on my use of InstanceDefinitionGeometry to access block geometry because it is a new addition to my project. After getting the File3dmObjects from the blocks, I am exported them to separate files.My other workflows for using File3dmObjects (not from blocks) are all working as expected.

I’m going to also try changing up my order of operations to try and rule out some other things. The tool I’m making has Revit as the host app… and I think we all know how muddy the waters can get there.

I’m guessing that this crash is happening when the Visual Studio debugger is not attached?

@stevebaer This happens during a debug session in Visual Studio. I have try/catch on all methods used in my code. However, no specific exceptions are caught. The only message I’ve been able to produce is the “An unhandled exception of type ‘System.AccessViolationException’ occurred in Rhino3dmIO.dll Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.”

No line info is given which makes me think it has to do with something deep in Rhino3dmIO. I have similar code that operates on File3dmObjects like breps and surfaces. It is when I started working with InstanceDefinitions and InstanceReferences that things go haywire.

The “An unhandled exception of type ‘System.AccessViolationException’…”

Hmm… I wonder if an exception is occurring when a class is being freed up by the GC

Hi @stevebaer,
I worked up a simplified example of where I am encountering these types of errors. I am using Rhino 6 and the latest version of Rhino3dmIO.dll on NuGet.

I am testing with a file with 3 simple InstanceDefinitionGeometry. There are several InstanceReferenceGeometry in the Rhino model (block instances).

meshblocktest.3dm (127.2 KB)

This code below simply iterates over the document’s File3dmObjects. If the File3dmObject has geometry of the type InstanceReferenceObject, I am then getting information the transform data and the name of the parent InstanceDefinitionGeometry.

I can step through the code and watch the program successfully get the data I want here within the debugger. However, when the program completes I receive either a hard crash with no warning OR sometimes the System.AccessViolationException message.

Here is the code:

// Getting a list of Rhino File3dmObject by layer
List<File3dmObject> rhObjs = GetLayerObjects(setLayer);

// Loop over objects
foreach (File3dmObject rhObj in rhObjs)
  // Check if File3dmObject geometry is InstanceReferenceGeometry
  if (rhObj.Geometry is Rhino.Geometry.InstanceReferenceGeometry)
    InstanceReferenceGeometry geo = (InstanceReferenceGeometry)rhObj.Geometry;

    // Lookup the parent block definition
    Guid blockDefId = geo.ParentIdefId;
    InstanceDefinitionGeometry def = _doc.AllInstanceDefinitions.FindId(blockDefId);

    // block definition name
    string defname = def.Name;

    // transform data for block instance
    Rhino.Geometry.Transform xform = geo.Xform;

Thanks! I’ll take a look.

I can repeat this and am working on a fix.

The InstanceDefinitionGeometry is definitely where the problem lies.

Thanks for the sample, immensely helpful

I just committed a fix for this. Hopefully you’ll see this in the next Rhino3dmIO build

AWESOME! Looking forward to it! Thanks for the assist @stevebaer

If I may ask @stevebaer, when is the next Rhino3dmIO going to be available on NuGet?

I’m not exactly sure; everything is so automated now😀 @will may have a good idea on when the next nuget builds will become available

Packages for the latest 6.11 RC and 7.0 WIP are now available :mage:

Hi @will
I am looking now. It looks like Rhino3dmIO Nuget is still 6.10.18308.14011. Will the version with @stevebaer’s fix also be published soon?


Yesterday’s 6.11 RC release has the -rc prerelease suffix, so you’ll need to check the “include prereleases” box!

@stevebaer is 6.11.18323.19181-rc the correct one with your fix? It appears to be the latest prerelease for 6.11 on NuGet. I just installed it and I am getting the same crash behavior as before with the InstanceDefinitionGeometry code snippet.


@stevebaer disregard that last note… I had another plugin also loading that was using an older version and it was loading that one, I think. Seems to be running okay now. I’ll let you know if I run into any issues as I continue testing.

Thanks again!

@stevebaer Okay… so it seems as though my last note about 6.11.18323.19181-rc was correctly stated. It appears that my code completes but the crash is now more delayed than before (if that makes sense at all.).

My code appears to complete as expected but the program eventually crashes in the same manner as I was describing before with that InstanceDefinitionGeometry code snippet. If I have the wrong 6.11 RC installed, please let me know.