Something strange with licensing in 3/14/17 WIP

I get this for about 40-45 seconds immediately on opening the latest WIP:

It happens every time. Also on the second last WIP - I didn’t install the last one.
Rhino 5 64bit gets right to it, no delay.
This is on a standalone installation with no internet access - Win7 up to date.

Even more interesting is that after Rhino eventually fully starts for the first few times after installation, if I open licenses in Options nothing shows up for several seconds and then I get a popup window that says something about “in use by other program” and a second minimized instance of Rhino shows up on the Windows task bar at the bottom (double Rhino icon). When I opened the snapshot tool to capture it the popup window and the 2nd instance disappeared. The license info finally showed up in the options screen. After a couple of iterations of this it seems that option-> license populates immediately. By this I mean closing Rhino, re-starting it, waiting the 40 seconds plus for Rhino to fully start, then doing the license request.

Pretty mysterious to me. Should I call an exorcist?

Hi Al - not sure about that last bit - but- can you try the next WIP and see if any of that looks more reasonable? I think there’s one due out today or tomorrow. So far as I know there have been no other reports of this…



@pascal I tried it with the 3/21 WIP and it still takes around 40 seconds to look for the license every time I start it up. Also spent 40 seconds opening the viewports. Then the first time I try to see the license via tools->options->license I get the message box I mentioned:

along with the second Rhino instance showing up as a second tool tray icon behind the first. It went away when I did the snip. I tried closing and re-opening Rhino a couple of more times and it still took 40 seconds for finding the license and viewports but when I asked to see the license through the option entry it came up right away.

Again: this is on a Win7 64 bit Xeon machine on a LAN with no internet access. And BTW, the 40 seconds on the first start after install is after the initialization screen completes.

@pascal Here’s a report on the latest (4-4-17) WIP:

The strange behavior with the Tools>license menu item is apparently resolved. It produces the correct answer with no delay, even on the first attempt after installation.

The 40-second search for a license is still there. I’m starting to think that Rhino doesn’t know it’s installed on a machine with no internet access and goes ahead and tries to contact some server and waits 40 SECONDS before it decides to try the alternative method for satisfying it’s license need. The time interval is that consistent. I think the installer should figure out if there’s internet access, even if it asks the user to confirm it, and set a flag so Rhino will know to skip the network look at startup. @brian Maybe I’m way off base here and it’s something else but I sure wish it could be fixed.

Thanks Al, I’ve logged this as Logged as RH-38807 - I missed it before.

RH-38807 is fixed in the latest WIP

@brian @pascal It is indeed. Now 4 seconds instead of 40. Less would be even better, but 4 will do.

There is still another issue which is splash screen related, but may not be related in any other way:

Rhino spends one minute “Preparing Viewports” every time I start it. The most interesting thing is that it only takes that long when I run it as an administrator. When I run it as an ordinary user it takes practically no time at all. (NB: I install as administrator and run it to do the setup for the administrator account and test the installation. I normally run as user.)

I wish I had more information to offer, but this is it.

Note also the abstract pattern of the viewports which occurs during startup every time. It eventually goes away, but isn’t particularly cosmetically pleasing - kind of suggests a lack of tidiness on the part of the programmers.


If you normally run as an ordinary user (as everyone should - there’s no reason to run as admin) then this doesn’t seem like a bug worth investigating.

@brian I mentioned it on the chance that it might be symptomatic of something that is worth investigating. Since administrators normally have more security access than ordinary users I would be a lot less surprised if it was the other way around. It seems like it’s another time-out thing since the length of time it takes is quite consistent.

IMHO it might be worth fanning out to the appropriate developers in the hope that a light bulb goes on with one, but you’re the boss. I’d do it but I don’t know who the right folks are.

It might be. If we get more reports of it, we’ll definitely do so. Right now, I can’t even reproduce the problem - you seem to have built a network that puts Rhino’s code into some interesting corner cases.

Sure. We’ve got another several thousand bugs that fit that description, and we prioritize based on several factors including problem severity, frequency of occurrence, load on us to support the problem, and availability of a workaround. Given that this problem currently ranks low in all four means it’s not going to float above others that rank higher - yet.

I’ve logged it as RH-38972 should it rear its ugly head somewhere else.