Rhino crashes while opening big file

Without specific details I’m guessing, but there are two likely possibilities:

  • AMD Graphics - In Rhino Options > View > OpenGL, make sure the “GPU tessellation” box is unchecked.

  • Plug-ins - In Options > Plug-ins, change the list filter to “Plug-ins that do not ship with Rhino”. Disable all of them and restart Rhino. If The file opens, then systematically enable the plug-ins, one at a time, restart, and determine which plug-in is causing the problem.

Good luck

It could be a driver issue on the bigger machines, but is hard to tell.
Can you send the _SystemInfo for these machines?
a few questions and things to try:
Are the machines up to date with their drivers?
Do the files open in SafeMode?
Do they open well when you import the files into a new file?
Are the models you open in Rendered mode when you open them, or other mode(s)?

Hello John,

THX a lot for your fast response…it’s very appreciated!
We started immediately today with to test with these tipps:
The Checkbox was already unchecked and, in the Plugins,-List was nothing we could disable. So only standard Plugins on this machine.

We still tried to enable and disable it, but nothing changed. Maybe you have another idea ??
Please also read the answer to the other comment…THX and happy Christmas-Time from Vienna :wink:

Peter

Hello Gijs,
to you also a BIG THX for your fast support answer - it’s very appreciated also :-). the answers:
1.) The machine is more or less 1 month old and fresh installed…so YES, there are the newest drivers from Graphic Cards etc.
2.) When opening this specific File in the Rhino7 Safe-Mode is the same result - unresponsive circling probably forever :frowning: .
3.) When Rhino is opened and choosed to import this File into a fresh one, is also the same result…
4.) No, we disabled everything

If we can provide more information to track down this issue, we are happy todo so. Because in the moment, this breaks our full workflow. Its the first time ever, where suddenly half of the team can’t continue to work on an important project we are currently working on, and they must search weaker machines where they can continue…it’s…“Grrrrrrrrrr”.

and lastly here is the SystemInfo:

Rhino 7 SR25 2022-11-22 (Rhino 7, 7.25.22326.19001, Git hash:master @ 2a680490f96a04550d1f39158b859c4f7739d024)
License type: Commercial, build 2022-11-22
License details: LAN Zoo Network Node

Windows 10 (10.0.19045 SR0.0) or greater (Physical RAM: 64Gb)

Computer platform: DESKTOP

Standard graphics configuration.
Primary display and OpenGL: NVIDIA GeForce RTX 3080 Ti (NVidia) Memory: 12GB, Driver date: 12-5-2022 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 527.56
> Accelerated graphics device with 4 adapter port(s)
- Windows Main Display attached to adapter port #0
- Secondary monitor attached to adapter port #1
- Secondary monitor attached to adapter port #2

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)

Anti-alias mode: 8x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 12-5-2022
Driver Version: 31.0.15.2756
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 12 GB

Rhino plugins that do not ship with Rhino

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 7\Plug-ins\Commands.rhp “Commands” 7.25.22326.19001
C:\Program Files\Rhino 7\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 7\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 7.25.22326.19001
C:\Program Files\Rhino 7\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 7.25.22326.19001
C:\Program Files\Rhino 7\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Program Files\Rhino 7\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 7\Plug-ins\RhinoCycles.rhp “RhinoCycles” 7.25.22326.19001
C:\Program Files\Rhino 7\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 7.25.22326.19001
C:\Program Files\Rhino 7\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 7\Plug-ins\Displacement.rhp “Displacement”

Again…BIG THX to you and also greets from Vienna
Peter

Hi Peter,

are these custom built machines or stock from a named brand?
What I would try to sort out the issue is to find which hardware item is causing it.
E.g. swap out the graphics card and see if the problem persists.

Edit: I see there are two three monitors connected, any difference when you only connect one?

Hi Peter -

Please use the following instructions to provide us with a manual crash dump from a machine that Rhino is hanging on - Manually Creating a Memory Dump (DMP File) from an Unresponsive Rhino for Windows [McNeel Wiki]

You could also try to perform a clean install of the drivers:

-wim

Hi Gijs,
No, the machines are NOT stock but BUILT machines (with good Hardware).
Yes, figuring out what causes the problem is my normal way, but here I don’t find any solution. When I take only one screen nothing changes. When I half or change the RAM, nothing changes. And even when we change somehow to other PC’s the problem stays. These other PCs are for example not Intel but AMD CPUs, different RAMs (DDR5 vs DDR4) and also other Graphic Cards. The only thing I noticed, is that all these PCs have '80 or '90 nvidia Cards and the “weaker” PCs (where the file can be opened) have 60 and 70 nvida Cards. → I can’t think of this to be the reason, but I will give it a try.
Is there maybe any other…uhm…Rhino LOG File or similar to check ? Because Rhino gets unresponsive → the Windows Eventlog stays clean :-(. THX Peter

How long have you waited to see if the file does eventually open?

What about the files makes them so big?

Did you also try the suggested clean install? Creating a memory dump file as suggested by @Wim is then the best next step do for now I think. This you can do while Rhino hangs, and this could give our devs a clue why it is happening.
Another thing to try is to move the new card to a pc that does open the file if that’s possible to see if you can find the issue the other way around. If you want I can also have a look at the file itself to see if I can repeat the issue at my end. For this upload the file here and link it back to this thread.

@Peter_Dornauer I’m seeing the file coming in, I’ll take a look right away.
edit: I thought you were sending the file itself, but I see now its the memory dump, so I will forward this to our devs.

Have you tried the Rescue3DMFile command. It is possible that it will go through and report what is happening in the open. This is where I would start.

A second option is to open a blank model that is all in default wireframe mode, then try and import the problematic model.

Also, is the file being run on a local drive? Make sure for testing that the drive is local. Certain situations network or cloud based drives can drastically effect performance, especially in ver large files.

@Peter_Dornauer the dmp file alone seems to be not enough to isolate the issue. Is it possible to send one of the files that shows the issue as well?

To rule out more possible issues, @scottd suggests a couple more checks:
Are there any (large) textures involved
Are these textures maybe directly accessible to the old computers but not to the newer ones. Are there any large, slower drives in the search locations.
Are the newer computers differently connected (eg wireless vs wired)

Again, sending a file will be best to help us find the issue.

Hello Gijs and all others of course ;-),

thx for your all the input.
Here some Infos regarding this topic:

1.) We upload the file, we talk about, like before the memory dump, to the McNeel Server → but please use it CONFIDENTIAL…this is real Work in progress files/data.
2.) No, there aren’t any large textures
3.) There are no connected textures involved or slow network drives (to be sure we copied over onto the local machine, but makes no difference)
4.) No, all PCs are wired only. The PC are different from the used equipment (like explained) and manufacturer, but all are built with good components.
5.) Info to the file; Basically, all layers are switched OFF and when the file is opening, we see just a blank screen and then we usually enable step by step the layers.

We start now with the UPLOAD of the issued file to the McNeel Server. Hope you guys can help us. THX A LOT - it’s VERY appreciated.

Peter

We already waited on some machines for over 2 hours.
The files are big, beacause we work architecture stuff together with an international setup → so there is NO way to change the workstyle, split up or any other idea.
But the point is, that on other PCs its working → so its about to find this particular culprit

Thanks for sending in, I will look at it right now, to see if I can repeat it or see something that catches my attention, and also send it to the developer that’s going to look into it.

1 Like

Peter, how long is this file taking to open on the machines that do work?

Hello Scott,
also THX for your input.
To be honest, we didn’t know this Rescue Command. We tried it right now and we saw the After reading in a certain number of objects - Rhino got unresponsive → :-(.
We then made some tests and managed to partially open this file, but in the end…we have too little experience in the moment to handle this command correctly. (Which cmd Options, what to do with the output, how to proceed). So, if you can give us a quick explanation or a link, to know how we can use this command…would be great.
But right now, we send you (McNeel Server) this file, 'cause we think you and your team will be better in evaluating this…

The second option we tried with no success and third - yes we copied it over, also with no success.

THX/Peter

Uhh…we didn’t measure the time and all the PCs are equipped with m2 NVME Drives, but if I may say so → it was ‘normal’ time (like 2,3 - 5 min).
If you need an exact time I can do a test for you.

Peter

no this is accurate enough, thanks,

fyi I am getting also an unresponsive Rhino, so I will make a dmp file too and send it to our dev. to look into. The fact that it’s not working here is kind of good news.

Is there a large mesh in this file? It gets hung up early on in an ON_Mesh. Trying to figure out if it is a really large mesh or it is a mesh that it is simply stuck on.

Since we are all having trouble getting it open are you sure the older machines still open it?