Std::__non_rtti_object unhandled exception followed by crash

Recently I have been experiencing intermittent crashes of Rhino while running one of our commands for a specific case.

When debugging in .NET, I get an uncatchable SEHException with error code -2147467259, which is 0xFFFFFFFF80004005. Looked this up, but no more information than E_FAIL/Unspecified.

When debugging in the Rhino debug version, the error also occurs, but Rhino does not crash. Instead I get the callstack and message about std::__non_rtti_object exception (see below). It seems that a dynamic_cast fails???

Do you guys have any idea what is going on? Can you decipher the callstack to rhcommon_c functions to see what is going on?

The screen shot isn’t too useful. Is Rhino generating a .dmp file (on your desktop)? Is there a way we can repeat the crash?

I’ll try to see if I can make this repeatable. So far it has been intermittently crashing. As this is while one of our commands is running, for you to repeat the crash would be difficult (having to install our plug-ins including a license file).
I’ll dig some more into this on Monday. For now: TGIF :smile:

There is indeed a RhinoDotNetCrash.txt file on my Desktop with the following content. I will investigate further…

System::AppDomain::CurrentDomain->UnhandledException event occured

SENDER: Name:DefaultDomain
There are no context policies.

EXCEPTION: System.Runtime.InteropServices.SEHException
MESSAGE: External component has thrown an exception.
SOURCE: RhinoCommon
   at UnsafeNativeMethods.CRhCmnUserData_Delete(IntPtr pUserData, Boolean only_if_no_parent)
   at Rhino.DocObjects.Custom.UserData.Dispose(Boolean disposing)
   at Rhino.DocObjects.Custom.UserData.Finalize()

@stevebaer, does this mean anything to you?

I can speculate. The error is occurring during a garbage collection routine and involves custom user data. Other than that, I can’t really figure out what is causing the problem without a little code.

I’ve been looking at this today and I suspect a thread timing issue with GC. I seem to have solved it by moving the dispose code out of the threaded part of the code.