CloudZooManager preventing application from closing

Rhino Developer
, , ,
1

Hi,

We have a WPF application running with Rhino.Inside, started with the following arguments:

RhinoInside = new RhinoCore(new string[] { "/nosplash", "/netfx" }, RhWindowStyle.Hidden, MainWindowWrapper.Handle);

The app then runs absolutely fine but when we close, despite attempting to clean up properly with the following:

protected override void OnExit(ExitEventArgs e)
{
    RhinoApp.Exit();
    RhinoInside?.Dispose();
    RhinoInside = null;

    base.OnExit(e);
}

There are a few threads that seem to continue running perpetually and therefore keep the application alive. Assuming they’re all part of the same stack, from the leftover threads it appears that the CloudZooManager is launching a Timer than runs indefinitely and is never cancelled. The Task.Delay in the image below never lasts for more than a few seconds so I assume the Timer must be re-upping it.
image

We’ve done a bit of fiddling to see if we can get something to resolve the issue and found:

  1. Closing works fine if we run the same app with Rhino 7 as the underlying instance.
  2. Despite being warned off it (Rhino.Inside Panels not Showing - #18 by stevebaer), I did a quick test with the -appmode flag and it appears to resolve the issue. However, we “definitely don’t want” to rely on that flag.

We believe this is a semi-new issue, we haven’t traced back when it was introduced, but we are pretty sure it worked once upon a time.

Any thoughts, suggestions? Or if I can provide additional information, please just let me know.
Thanks,
Seb

2

I wrote that CloudZooManager code 8-10 years ago. I do not know anything about how this code behaves with Rhino.Inside, but with “regular” Rhino it just calls Task.Delay which under the hood queues a timer at the OS level without using a thread that, when fired, schedules work on a .NET thread pool thread to be executed. This timer is essential for Cloud Zoo’s licensing code to work properly.

I could speculate what the problem is here, but I’ll let somebody else with more knowledge about Rhino.Inside chime in.

1 Like
3

Thanks for the speedy response Andrés.

Whilst the CloudZooManager is the thing keeping the application alive, I agree, I don’t think it’s actually the culprit. I suspect it’s the thing that’s supposed to close or dispose of that CloudZooManager (or maybe even a thing or two above that) which is bypassing the call in certain conditions. I, however, have absolutely no idea what those objects are because they aren’t left in the threads so I couldn’t pass the buck higher up the stack, sorry. And thanks again