Rhino 8 Computer hanging needs resetting

It is the 3rd time in the last 24 hours that Rhino 8 completely hangs my computer.
The computer becomes totally unresponsive, I can see the Rhino 8 model but cannot go to other programs or windows.
After waiting for quite a bit, nothing seems to be happening. I am working with remote desktop so I can’t do task manager or Ctrl+Alt+Delete. Luckly, for this session I am in the same room so I can physically press the reset button,

Did this happened to any one?

1 Like

??? Remote Desktop is just a remote access to the hardware, isn’t it? The software is running locally on the remote computer.

I don’t know whether you can’t do Ctrl+Alt+Delete because the admins won’t allow it or because you don’t know how to. In case of the latter, you use Ctrl+Alt+End.

It’s a bit more involved than that! Note that McNeel don’t say there that it doesn’t work, they say they don’t support it.

As you are in the same room, access the remote computer directly and run the same tasks on it to see if they work ok. If they do then you’ve demonstrated that the problem does lie with Remote Desktop. If they don’t you know it is down to the remote machine, the software or your model…

Remote desktop changes how the GPUs are used, and that is the not-supported bit. I think if you start Rhino first on the machine you want to remote into it will get regular GPU access.

I use VNC to remote into my Windows machine, as that doesn’t mess with the graphics from OS or software point of view.

When the hang happens again and you can still use the computer directly wtih access to the task manager you could create a memory dump of the Rhino process. Once that has finished zip it up and share with us at Rhino - Upload to Support - I can have a look into it begin of the coming week.

Well, what does that even mean? Compressing a video stream down to something that can run over a modest Internet connection is not a mean feat. it spawns a new virtual ‘monitor’ that it ‘powers’ using its own software video driver that’s absolute garbage for anything more demanding than Excel. Maybe Nathan’s workaround will work but yes it’s “unsupported” for a reason.

There are better “remote desktop” products that are made to play well with GPUs, like Parsec.

Parsec is crap, if you have a non QWERTY layout you’re out of luck. You get to guess where keys are. That is pretty much the same with Remote Desktop btw. Just awful.

RealVNC is the only one that properly works.

I have no idea what a memory dump is (or how to do it).
It just happened again. It never happened with Rhino7.

[just venting my frustration a bit, I hope this does not become like the previous situation, where everything was blamed on my system, which clearly did not have the minimum requirements but, although, slow worked fairly well. I then invested on a new computer, to find that most of the problems blamed on the system, persisted in the new machine.]

[just spent half an hour, disposing of the bodies of the ‘dead dynamic sections’, to hang again and having to start that gruesome and frustrating on its own merits]

[edit] After the computer directly, a not so easy task because of our step-up, I found out unsurprisingly that the computer was unresponsive and I could not even access the task manager. So I had to reset it manually (thank goodness for physical buttons). I’ll work for a while directly on the computer.
@nathanletwory Please let me know what do you want me to do when it happens again. Thanks.

Remote Desktop is not supported. Any times it worked in the past are dumb luck. It’s not made for 3D apps, full stop. Microsoft themselves know this, you can rent an Azure virtual desktop-in-the-cloud meant for “game development” that uses Parsec instead of Remote Desktop. There are other options that are free or cheap.

Thank you for your comment.
I realize now that I have then been dumb luck for year, and a company I work with has been dumb luck since the pandemic started.
In any case, it seems that it has been the arrival of Rhino 8 that broke the charmed life we have been living. It would be therefore perhaps useful to find out what power does it yields to break the spell.

Please follow these instructions: Manually Creating a Memory Dump (DMP File) from an Unresponsive Rhino for Windows [McNeel Wiki]

1 Like

@nathanletwory @JimCarruthers
Since our little discussion, I haven’t been working as intensely in Rhino, but whenever I did I have worked directly on the computer. It disturbed my normal workflow and set up, but I like to be proven wrong as much as I like to be proven right or viceversa.

Just now the computer has become unresponsive as the few times before. I was not working through Remote Desktop and therefore that seems not to be the problem, and if I may again vent my frustration: it is really annoying that problems get ignored when an unrelated flaw in the way other people work with the program is found.

Now, @nathanletwory I went to the link you sent and I may not have been clear in relation to the nature or extent of the unresponsiveness of the computer… it is completely frozen, mouse is unresponsive, keyboard is unresponsive, the screen shows the Rhino as it was in the moment of the crash. I cannot access the task manager or any other part of the computer. The only way to get it back in the past was to press the reset button.

Is there a way to create a DMP file after the fact? I will leave the computer until the morning and hopefully I get a message on return of mail.

thanks, N

Have you sent a SystemInfo report of your machine when NOT using the Remote Desktop nonsense? Run -systemInfo and post the results here.

Note that random crashes that are not being reported by others are usually the result of needing to update your video drivers, or some other sort of hardware issue.

Yeah pretty much, not sure why you think your anecdote is supposed to impress me when a basic Google search will say Remote Desktop is not fit for purpose for this. It’s also unsupported, so technically you’re on your own for any issues with it.


What makes you think the problem gets ignored?

I have tried my best to come up with ways for you to get me data that will help me figure out what the problem is.

If your machine seizes up then there’s a couple of things you could try to see if they have an impact:

  1. follow thermal info while working. Use something like hwmonitor from https://www.cpuid.com/ to follow that while working. I’m using the Pro version myself, but you should be able to use the free version as well
  2. If thermals rise blow out all fans, air intakes and heatsinks. This is something you should do regularly (say once, twice or more a year, based on the environment). Dust settles on fan fins and cakes onto heatsinks, which can decrease cooling performance quite a bit. Overheating can lead to random restarts, or just seizures of machines
  3. With the same monitor software check power consumption. When systems draw too much power for what their PSU can deliver it can lead to reboots. But I wouldn’t be surprised if it freezes some machines.
  4. Ensure your Windows is fully up-to-date. Apply all pending updates.
  5. Ensure GPU drivers are the very latest. If unsure reinstall drivers. Perform clean installs for them, which ensures no old parts are left lingering.

I’ll gladly fix issues when I have here reproducible cases that point to code. Until there is one I can only try giving pointers on what to do to gather more data.

1 Like

I hope for you that we can get to the bottom of this.

Sorry, Nathan. I was just venting some accumulated frustration. I have been using Rhino for 26 years and there is a pattern of blaming the hardware on some short fallings or unreplicatable issues (or unreplicatable with a simple three cubes and a sphere model).

Two examples:

  • for years there are complaints about camera clipping views, in my case often blamed on the hardware I used. I have much better hardware now and the issue still occurs.
  • recently I had the looping raytracing issue. To your credit, you asked for the model privately and you were at least able to replicate. But, if I understand, not at first and you had to push the sample count to an very high rate. I do appreciate that extra effort but it could have easily go unnoticed.

I realize that it is not easy to troubleshoot without being able to replicate. But it is also true that we probably work with much more complex models in poorer machines than what you are able to test. We also use it in strange, unexpected and ridiculously resource consuming ways. Considering this, to dismiss a problem on hardware limitations is frustrating, especially when there is a new version of a program that crashes, when the previous version (and other softwares) does not.
Granted this is a universe of three crashes, but considering that I am still mostly using Rhino 7 without this type of crashes, and that the crashes occur using Rhino 8, there is a natural suspicion that there is something related to Rhino 8.

Now, if there is nothing you can do, then there is nothing you can do. I don’t mean this is a dismissive or complaining way.
We plough on, hoping that in a future issue this gets fixed, either by accident or by design.

Thanks, N

1 Like

Please run SystemInfo (without using Remote Desktop) and post the results.

Random crashes ARE USUALLY OPENGL DRIVERS. Every new version of Rhino uses more OpenGL , so it becomes more important to keep them up to date, also to have minimum functional hardware.

I am not dismissing anything. The steps outlined are to rule out that it isn’t a hardware issue. It isn’t blaming hardware per se. Just a method. This is part of troubleshooting. When it can be confidently said that hardware isn’t a problem it becomes perhaps a bit easier than before to figure out what software issue is causing this. This is what I do to eliminate external factors and hopefully get a better picture.

You cannot compare Rhino 8 to anything else, not even Rhino 7 - lots of things have changed under the hood, equipment is pushed more than before. Since there is more demand of the hardware it is only natural to ensure that the equipment isn’t the problem. We need to do that through elimination process. Doing a clean driver install is often needed, especially after Windows updates when suddenly Rhino appears to be less stable. We have seen a pattern where recent Nvidia drivers from second half of 2023 cause crashes that stop when updated to the very latest of this year - with clean install.

Yes, there are absolutely bugs in Rhino that cause it to crash and we want there to be no crashes at all (nor any bugs).

So, I understand your frustration, but it’ll be more useful if you actually went through the steps to help rule out the hardware side if you haven’t already.

I have an AMD Radeon Pro W7800 I test with every now and then, but I can’t have it in my machine all the time, since with it in my desktop will just randomly reboot. I have lots of power in the PSU, consumption is tracked with hwmonitor, and cooling is in order temps are tracked with hwmonitor, memory has been checked, all connections pressed and not loose. It is probably a driver issue, but I am already on the latest available, with full clean driver install. It was an annoying process to go through, but at least I know this related to this particular GPU, be it driver or hardware. Taking it out my system no longer randomly reboots.