Debug Grasshopper plug-in that (for some users) crashes when loading

Hello,

I have a question regarding my Grasshopper plug-in Pug:

Apparently some users are not able to load the plug-in. Rhio crashes without any error message:

Hi, does anyone know of a fix for this plugin crashing Rhino when I try to load Grasshopper? It sticks on loading Pug, then entirely closes. Thanks!

Does someone know what the reason for this may be? How can I debug this since I am not able to replicate the problem? Anyway it happens before the user loads any component into the canvas, so it should not be related to the code itself to my inderstanding. Perhaps some conflicts with the dlls?

You may ask them to look for crash events in the Application section of the event viewer. Sometimes there would be useful information.

e.g. Application Error / Application Hang would give you in which module the program fails and .NET Runtime would provide reasons or managed callstack, if the crash happens in the .NET domain.

I have decompiled your plugin and I would also guess maybe some people’s system configuration conflicts with ConfuserEx because it decrypts method bodies on the fly (module .cctor). :stuck_out_tongue: Maybe not protecting the Tensorflow libraries would help, since their code are publicly available on the Internet.

Besides, your plugin utilizes Tensorflow.NET so something may happen during PInvoke, although less likely.

2 Likes

btw if you still want to know how to do operator overloadding in Grasshopper, you’ll need to implement GH_QuickCastType and use Reflection to inject into the operator map of operator components. The division operator won’t work, though.

e.g.

In Grasshopper 2, there will be official ways to overload operators.

3 Likes

Hello Keyu,
thank you very much for your replies. I uploaded a non-confused version of the tool to food4rhino and then the user was able to load it without Rhino crashing. There is still an error related to a dll poping up, but it looks not so difficult to figure out. And thanks also for the tip regarding the operator overloading in C# plug-ins.
Kind regards,
Diego

1 Like

Hi,

For software with more than 3 expected user, I would always implement a logger. I usually use NLog together with the Microsoft ILogger interface. And of course I do log a lot. I could solve tons of issues on user machines, when asking for a log file. And this is the main purpose of it. Locally you just attach with a debugger, that would be rather redundant. But if you have no clue why something is throwing on a users system, a log file is the only valuable source.

Some years ago, I also protected my GH plugins with ConfuserEx, but nowadays I think a bit different. For a skilled reverse engineer, this is just some extra noise to get around. What prevents people for reversing software is size and complexity, not obfuscation. If you basically just build a small wrapper, a obfuscator is doing nothing more than making your system volatile and harder to debug.

1 Like