Visual Studio debug C#

Hey,
I’m having problems with the Visual Studio debugger.
I’ve written a simple C# component that I can both run and debug on my other computer, but when I tru to run the debugger from Visual Studio i get this message:

FatalExecutionEngineError occurred
Message: Managed Debugging Assistant 'FatalExecutionEngineError' has detected a problem in 'c:\Program Files (x86)\Rhinoceros 5\System\Rhino4.exe'.
Additional information: The runtime has encountered a fatal error. The address of the error was at 0x14ff0efa, on thread 0xe78. The error code is 0x80131623. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.

Which is also quite strange as Im running Rhino 5 and not Rhino 4.

I suppose this question is quite similar to Visual Studio Grasshopper Debugger , but I cant get it working just by setting up the /bin in GrasshopperDeveloperSettings, it seems something else is wrong too. I get the same error when I try to debug an empty GHA template.

1 Like

Hi @Jakob1

I would try re-installing VS on that machine (including all updates). Then, make sure that you have all Windows Updates installed, and that you have the .Net Framework 4.0 installed on that machine.

Please let me know and @-mention me if that does not!
Giulio

Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

hey @piac
Thank you for your reply!
I haven’t had the time to go into deth with this yet as Im reliant on external IT support at the moment. I can however see that I have .NET framwork 4.5 and 4.6 packages installed. Is this a potential problem? Does it need to be 4.0 or are later versions also compatible?
I’ll be looking into this more as soon as I get the chance, probably in the coming week or so.

Jakob

@stevebaer might be able to tell you more details. I think there was a time when 4.0 was needed.

Hi @Jakob1,
I experienced your same issue: one old installed assembly in GH library was causing that Error.
While opening Grasshopper, I got the same message from VS debugger. I solved basically removing that assembly all along the developing of my new component. It worked to me, at least.
Please note that the interfering assembly was causing issues only in the debug stage: running Rhino from outside VS everything worked properly (my custom components were in the shelf and perfectly working).

Hope this can help you.
Michele

1 Like

Here’s a couple things to try:

  • move all custom components out of the GH library folder to see if they are causing the problem. Once you’ve determined these are not the problem, you can put the components back in the folder.
  • Try debugging with the 64bit version of Rhino 5. This is just a shot in the dark as something to try

If GH is running at all, then I doubt this has anything to do with which version of the .NET runtime you have installed.

1 Like

I’ve now moved everything out of my libraries folder and now I get different but still disturbing error messages.
Any thoughts, tips or tricks on this is more than welcome. As the beginner I am, I’m truly in the dark here…

I get the following when attempting to debug an “out of the box” empty GHA template:

Managed Debugging Assistant ‘DisconnectedContext’ has detected a problem in ‘c:\Program Files (x86)\Rhinoceros 5\System\Rhino4.exe’.

Additional information: Transition into COM context 0x650818 for this RuntimeCallableWrapper failed with the following error: Det anropade objektet har kopplats från sina klienter. (Exception from HRESULT: 0x80010108 (RPC_E_DISCONNECTED)). This is typically because the COM context 0x650818 where this RuntimeCallableWrapper was created has been disconnected or it is busy doing something else. Releasing the interfaces from the current COM context (COM context 0x650760). This may cause corruption or data loss. To avoid this problem, please ensure that all COM contexts/apartments/threads stay alive and are available for context transition, until the application is completely done with the RuntimeCallableWrappers that represents COM components that live inside them.

…And when trying to debug a simple component I’ve written (and which seems to work fine on my other computer), I get this instead:

Managed Debugging Assistant ‘ContextSwitchDeadlock’ has detected a problem in ‘c:\Program Files (x86)\Rhinoceros 5\System\Rhino4.exe’.

Additional information: The CLR has been unable to transition from COM context 0x4b0760 to COM context 0x4b0818 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

EDIT

I turned of ‘Deadlock’ in the debug exceptions and now it seem to work just fine when trying to debug the component I’ve written. As it appears, it was elefront_2.gha that caused the issue in the first place. When I put that back into my libraries starting Grasshopper during Visual Studio debug does not work.

1 Like

Thanks for the hint on elefront_2.gha!

Hey,
I’m facing a similar issue which couldn’t be solved by uninstalling elefront_2.gha.

When in debug mode, Grasshopper crashes with this error:

Managed Debugging Assistant ‘FatalExecutionEngineError’ : ‘The runtime has encountered a fatal error. The address of the error was at 0x32e69be8, on thread 0x9784. The error code is 0x80131623. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.’

I’m running on net48 target framework and Grasshopper version= “7.13.21348.13001”.

While not debugging, I have access to the plug-in and everything works fine.

I’d be happy for any help!