Drag-and-Drop Bug with Rhino 7 on Windows 10 and 11

Hello everyone,

I’m encountering a frustrating bug with Rhino 7, and I was wondering if anyone else has experienced this or has a solution.

System Information:

  • Rhino 7 (latest version)
  • Windows 11 (but also experienced this on Windows 10)
  • [Additional system info, like RAM, CPU, etc., if you think it’s relevant]

The Issue:

Whenever I try to drag a file from Windows Explorer to another application and hover over the Rhino window during the drag-and-drop operation, both Rhino and Windows Explorer freeze. This requires me to forcibly close both programs using Task Manager.

Has anyone else experienced this problem or have any suggestions on how to resolve it?

Thank you in advance for your help.

Hi Nicolas -

I haven’t heard about this problem before.
Just to make sure, you are picking a file that Rhino can’t open (e.g. an Excel file) from Explorer to an application that can open that file and cross a Rhino viewport that is between Explorer and that application?
That works just fine here.

You might want to run the Rhino SystemInfo command and copy-paste the result here but this sounds like something very system-specific to your setup.

Yes, that’s exactly what I do. I drag a file from one explorer to another application by hovering over the rhino window. In my case, it was a zip, to an email to paste an attachment.
FYI, the explorer is open in a network folder, if that helps?

So I’ve just done another test, and I didn’t get any freezes.
But it’s been happening to me fairly regularly for several years. Maybe since version 7 of Rhino, I don’t remember having this problem before?
I’ve come to the conclusion that it doesn’t happen all the time, because I have to make this movement quite regularly, without realising it, and without it bugging me.
As I have several screens, it’s quite regular for me to move a file to another application by hovering over another one.
I blamed it on my old PC (win10), but it happened this morning on my new computer (win11).
To explain the bug in more detail, it’s as if Rhino catches the drag event and enters a blocking function that waits for the drop - it’s like an infinite loop. And Rhino turns grey, it doesn’t respond any more. When I kill the Rhino process, I still have the file icon following the mouse movement (even though I’ve clicked in the task manager to kill Rhino), and the file explorer is no longer frozen.

Rhino 7 SR32 2023-8-9 (Rhino 7, 7.32.23221.10241, Git hash:master @ 3d9c816c4cd57561d12d8f53246bce304f314ba2)
License type: Commerciale, version 2023-08-09
License details: Cloud Zoo

Windows 11 (10.0.22621 SR0.0) or greater (Physical RAM: 64Gb)

Computer platform: DESKTOP

Standard graphics configuration.
Primary display and OpenGL: NVIDIA GeForce RTX 4070 (NVidia) Memory: 12GB, Driver date: 6-23-2023 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 536.40
> Accelerated graphics device with 8 adapter port(s)
- Windows Main Display attached to adapter port #4
- Secondary monitor attached to adapter port #5
- Secondary monitor attached to adapter port #6

Secondary graphics devices.
NVIDIA GeForce RTX 4070 (NVidia) Memory: 12GB, Driver date: 6-23-2023 (M-D-Y).
> Accelerated graphics device with 0 adapter port(s)
- There are no monitors attached to this device!

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: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 6-23-2023
Driver Version:
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 12282 MB

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.32.23221.10241
C:\Program Files\Rhino 7\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 7\Plug-ins\RhinoRenderCycles.rhp “Rendu de Rhino” 7.32.23221.10241
C:\Program Files\Rhino 7\Plug-ins\RhinoRender.rhp “Ancien rendu de Rhino”
C:\Program Files\Rhino 7\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 7.32.23221.10241
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.32.23221.10241
C:\Program Files\Rhino 7\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 7.32.23221.10241
C:\Program Files\Rhino 7\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 7\Plug-ins\Displacement.rhp “Displacement”

Hi Nicolas - I cannot reproduce this here either, so far. One thing to try:

Open Windows TaskManager
Make the bad thing happen, and if the machine is responsive enough to interact with TaskManager, find Rhino 7 in the list, right-click and choose ‘Create memory dump file’

This will create a massive file - it tells you where when it creates the file. Zip this file and upload it with a link back here in your comments. Note very large uploads not infrequently fail, so it may take a couple of tries. I do not know if there will be useful infomration in this file for our developers but there is a chance.


I’ve had the bug several times, including once when the file was confidential, so I launched an empty rhino, and after 2-3 attempts, I had the bug again, on this empty rhino.

So I had time to make a memory dump.
I need your email address to send the dump.

In fact, after a few minutes (2-5) Rhino was back under control.
Then I have the file icon, which moves with the mouse…

Hi Nicolas -

The upload page will auto-complete with the tech@mcneel.com address.

Do you also run into this when using only one screen?

I’ve just uploaded the dump file.
I can’t reproduce it on a single screen, as it doesn’t happen all the time, so I don’t know if it’s representative.
Otherwise, whatever happens, Rhino changes the mouse icon as soon as you drag a file onto its window, which means that Rhino has detected the event. And when it freezes, it unblocks after a few minutes (2-5min, I haven’t timed it), maybe there’s a timeout?
I should point out that I don’t release the file on Rhino, and that my mouse doesn’t seem to lose the click.

Hi Nicolas -

From the memory dump, it looks like Rhino is checking the contents of the zip file as you can drag and drop zip files onto Rhino to create PBR materials.
I’ve tried zipping a few files and dragging that zip across Rhino to a new mail but that didn’t trigger anything bad here. But I don’t have a network nor multiple monitors to test with, though…

Could you upload one of those zip files through that upload page? When I get that, I’ll write up a YT report for a developer to check further.

Sorry, but I can’t give you these zip files as they contain confidential files.

Now that you mention analysing zip files when dragging, I can add as information that they contain IGES, STEP and PDF3D files.
I can also add the fact that I no longer have access to the file, so I can’t drag it onto Thunderbird, only Rhino and Explorer freeze.
As I said earlier, rhino works again after a few minutes.

Regarding the zip, I’m not sure that Rhino is looking inside the zip, because when I click on a zip, it suggests that I select the texture, even though the zip contains IGES.

In any case, this bug is not systematic. So my NAS server (synology) is pretty responsive, but it’s true that sometimes there’s a little lag when displaying a folder.

I had the bug again, in normal use.
All the files are saved in a shared directory (samba) on the network such as: H:\XXX\YYY\230901 - ProjetRhino
I saved my Rhino file, for backup, and I made IGES and STEP exports of different models in a folder 230901 - export.
I zipped this folder, and dragged it over Rhino, and I got the bug.
After a few minutes, Rhino became operational, I dragged it again, and I didn’t get the bug.
I tried to reproduce the same protocol, but with non-confidential files, and I didn’t get the bug.

I think that Rhino, when dragging, is trying to do something with the file, which seems to be available, but that the server takes a little time to respond. Rhino enters a blocking function, which freezes it. Maybe Rhino has a safety net to take control, a kind of timeout?

How old is the zip system for PBRs? Perhaps this coincides with the arrival of this bug in my case? I’d say after the release of Rhino 7? I don’t remember having this problem at the start of Rhino 7.

Hi Nicolas -

I’m afraid that makes this issue very peculiar.

At any rate…

Can you also reproduce the issue when dragging a zip file from a location on the local disk?

Sorry to resurrect, but I am having the same problem occasionally. It happens when I am working in SolidWorks with “pack and go” ZIP files.

While trying to attach the zip file to my email, I click “attach” in my outlook web email (Chrome Browser) and I usually select the file and click “attach”, but sometimes I drag and drop the pack and go ZIP file into my email out of habit. If I accidently hover over Rhino 7 while dragging the ZIP file, the Rhino session and Google Chrome freeze up.

Edit: I forgot to mention, if I leave Rhino 7 in the unresponsive state, it usually becomes responsive after maybe 30 minutes to an hour of waiting.

Hi -

This behavior was fixed in 8.4 (RH-78280).