Various glitches RhinoCAM 2 + Vista 64

Mitch Heynick · Post by **Mitch Heynick** » Wed Jan 21, 2009 8:34 am

I am getting the MOps with what look like Japanese or Korean characters... I think this has been reported before...

I also get an expanded MOp that will suddenly collapse again. I looked further, and both of the above happen when I have another Rhino file open and I copy some geometry out of the other file and paste it into the first. It happens exactly at the moment you hit Ctrl+V to paste. (perhaps this will help you track this down)

Also, I am currently having the problem that if RhinoCAM is open, no new files get saved to the MRU (most recently used) file list. They show up while the file is open, but once you close RhinoCAM, they do not stay in the list. I wonder if, since these things are getting written to the registry, some Vista permissions thing is disallowing the registry mod. This does not happen when RhinoCAM is not loaded...

Thx, --Mitch

Mitch Heynick · Post by **Mitch Heynick** » Wed Jan 21, 2009 10:28 am

OK, I'm beginning to get a clue as to what's happening with the MRU issue mentioned above... Unfortunately, it seems like it's a symptom of a bigger problem.

What is going on is that Rhino with RhinoCAM loaded on my system is not shutting down correctly. Rogue Rhinos are staying in the task manager (I just discovered 6 instances + the license manager). So if Rhino is not shutting down correctly, the MRU doesn't get written to the registry, I guess.

As soon as I unload RhinoCAM, Rhino starts shutting down correctly, and the MRU is updated... Any experiences with RhinoCAM 2 + Vista 64? I have two more machines with this OS that have just arrived...

( --Mitch

Mitch Heynick · Post by **Mitch Heynick** » Sat Jan 24, 2009 2:48 pm

Back at you... Having now installed RC 2.0 and Rhino on my fixed Vista workstation and done some brief testing, Rhino appears to be shutting down correctly on this unit... Which is both good and bad news. The good news is that it's not a generalized Vista/Vista 64 problem. The bad news is something on my laptop is hanging the process up... I need to go about finding out what is causing the problem... Something else I've got installed in the way of Rhino plug-ins (I haven't installed all on the new unit)? Some stupid HP laptop add-on? Or something system related, like a driver or something... ? I have no idea where to start or how to diagnose...

Any clues here?

--Mitch

Post by **MecSoft Support** » Sun Jan 25, 2009 1:07 pm

What do you mean by "my fixed Vista workstation"?

Do you have the problem when RC 2.0 is not loaded (Installed but not loaded) ?

There are so many variables here that if you can definitely isolate it to a RC 2.0 problem we can take a look at it. We have tested this on XP 64 bit with no issues. We have not done testing on Vista 64 bit, however.

Mitch Heynick · Post by **Mitch Heynick** » Sun Jan 25, 2009 4:29 pm

What do you mean by "my fixed Vista workstation"?

By "fixed" I mean not portable - to distinguish it from my laptop. I can call it a desktop, I guess (although it's UNDER my desk

). The problem occurs on my laptop, not on the desktop unit.

Do you have the problem when RC 2.0 is not loaded (Installed but not loaded) ?

No. If RC is installed but not loaded there is no problem.

Thanks, --Mitch

Post by **MecSoft Support** » Mon Jan 26, 2009 2:28 pm

So as a summary

1) Rhino does not shut down properly on one of your 64 bit Vista machines when RC 2.0 is loaded
2) Rhino shuts down properly in your "fixed" (non-mobile) 64 bit Vista laptop when RC 2.0 is loaded

As you conclude this is something in the first laptop that is causing the problem. Since RC2.0 is involved we will get a machine in the week or so to perform our independent testing and let you know if we also run into this problem. In the meantime please try see if there is any other variable that you can identify that could be a factor.

Mitch Heynick · Post by **Mitch Heynick** » Sun Mar 01, 2009 4:00 pm

Any progress on this? Nothing I can find helps here, nor am I able to track down the problem.

I uninstalled the program and installed the latest version in the hopes that it would help... nope. That was a mistake. It's worse.

Since it doesn't close correctly, I can't even get the splash screen to not come up (you know the big fat one that you can check "don't show at startup") and none of the settings I make stick, the install is back to 0 every time I open it. It is not writing its settings to the registry (as Rhino is not fully closing) so it's like nothing is set.

This now makes it completely unusable.

--Mitch

Post by **MecSoft Support** » Mon Mar 02, 2009 10:34 am

We just got the OS software in-house. We will install this week and test and let you know.

Mitch Heynick · Post by **Mitch Heynick** » Mon Mar 02, 2009 10:59 am

OK, hang on just a bit, I may have some news on this front, but I have to go home now - I will test something later and report back in a couple of hours. --Mitch

Post by **MecSoft Support** » Mon Mar 02, 2009 2:21 pm

Mitch,

Make sure you are running Rhino 4.0 on elevated mode.

Steps to run Rhino in elevated mode-
Right click on the Rhinoceros 4.0 shortcut located on your desktop and select Properties
Go to the Compatibility tab
Check Run as Administrator.
Click Apply and Press Ok.

Launch Rhino and check don't show at startup from the evaluation dialog.

Mitch Heynick · Post by **Mitch Heynick** » Tue Mar 03, 2009 7:15 am

Well, I was hoping to have some good news, but unfortunately, not...

Since RhinoCAM was unusable after the install of the latest SP, and it seemed like installing again would produce the same problem, I decided to do a system restore back to before I installed the update.

Joy - after doing that, not only did the Rhino not closing problem go away (temporarily) but the 2.0.1.13 remained "installed" - as a system restore does not actually remove the .rhp, it just restores the registry. However, I don't know if this will cause problems in the future, as I don't know what else the system restore changes... Mecsoft?

My joy was as short-lived as the next full shut-down and restart. The Rhino not closing correctly phenomenon came back.

So, back to square one. First, just for background, I have UAC "off". So normally as administrator, things run in "elevated" mode automatically. However, to be sure, all my Rhino shortcuts are "run as administrator". Doesn't help in this case. There is no change if I use the start menu and right click on Rhino and choose "run as administrator" either.

What I have been able to test is as follows:

I started "Rhino in safe mode". Then I loaded only RhinoCAM. The problem persists. Therefore I think this is not a conflict between RhinoCAM and another Rhino plug-in.

I went into Vista "services" and stopped all the HP-related services that were running (the ones that were in addition to my Vista desktop). No help. So I think it is not some service running that is causing the problem.

The problem does not happen the first time you load RhinoCAM from inside Rhino. If RhinoCAM is unloaded and I load it manually from inside Rhino, then close Rhino, it closes normally. It is only on the next opening that the problem occurs. On the other hand, if I unload RhinoCAM before closing Rhino, it does not close normally that time. I have to kill that one and restart Rhino (RhinoCAM unloaded) and then it's OK, the subsequent closings (Rhino only) are correct.

If I start WINDOWS in safe mode, then load RhinoCAM, Rhino exits correctly every time. I don't quite know what this means as a diagnostic - as two things are happening when you run in Safe Mode in Vista - 1) a bunch of drivers are not loaded, and 2) you run with full ownership rights to EVERYTHING, which is not the case even with administrator privleges in Vista. I have the feeling it is #2 that is making the difference, somewhere some Vista prevelige level on this particular machine is keeping Rhino/RhinoCAM from doing something at shutdown (writing to the registry?), and hence not closing correctly. In safe mode, there are no such restrictions.

So the question is, given the above results, how to proceed? I don't have any developer tools or knowledge to be able to track what Rhino/RhinoCAM is doing at shut down and where it hangs up... The only thing I know how to do is try changing various settings...

As I seem to be the only one who is experiencing this problem, I am sorry for the long technical description. I've posted all of the above for anyone who might be interested, or anyone who might experience this problem in the future (hopefully nobody).

--Mitch

Hirudin · Post by **Hirudin** » Tue Mar 10, 2009 10:57 pm

It sounds like you know your way around a computer, so I expect you've already tried this, but here goes anyway...

Do you have any antivirus/firewall software running? If so, shut it down as completely as you can (right-click the icon and exit, kill the process, do whatever you gotta do). I would suggest disconnecting your computer from the network while you do this. Does Rhino shut down correctly after this?

If it does somehow start working, go through the settings of you AV program and see if you can make it so Rhino can do anything it wants and/or have access to all files. Hopefully doing this will fix your problem. If it does, and you care, you could then start denying Rhino access to parts of your system that you don't want it messing with.

Also, it might be worth a shot to check out this site...
http://forums.anandtech.com/messageview ... id=2259974
It sounds like this person is having similar trouble, but with Microsoft Office. The fix very well may work for you, just replace all the instances of "Microsoft" with "Mechsoft" and "McNeal" and all the instances of "Office" with "RhinoCAM" and "Rhino". It's worth a shot...

Mitch Heynick · Post by **Mitch Heynick** » Thu Mar 12, 2009 2:00 am

I do have an AV/Firewall running (McAfee), and I did try shutting it off - no help there, unfortunately. I have the same McAfee running on my other two computers which do not exhibit the problem, so I guess that was to be expected.

The registry permissions thing may be an interesting lead, I will check that out and see if there are any permissions differences between the units that I have that work and the one that doesn't.

Thanks, --Mitch