I’m not seeing any crash reports from your eMail address in our systems. Are you sending those in?
If you are, it looks like they might be getting misplaced or something, and I was wondering if you could make Rhino crash again, and before clicking the Send Now button, find the dmp file on your desktop and upload that to use with mentioning the url to this thread in the comments field. Perhaps a developer can find more information in that file…
-wim
I’m not sure. Vray sometimes shows a warning when opening a file that some data needs to be updated to the latest version. Not sure if it is related, but I thought I’d mention it.
I have uploaded the crashdump file through the upload form now.
It somehow it is also worse now. To open a file I have to copy it back to the local drive first. We used to be able to at least open the file from the server. But if I do that now, Rhino crashes immediately when opening the file.
We have a TrueNAS server with TrueNAS-12.0-U5 installed and are dealing with the same issue. The ‘incorrect parameter’ only occurs when trying to save a file to the server. The odd part is that the file saves correctly, it’s just that rhino becomes unusable and you have to manually shut it down through the task manager. Rhino is the only software with this issue. This occurs with Rhino 6 and Rhino 7.
We are dealing with nearly the same issues. We are using a Mac server with the same saving problems. Is everybody here using Windows PC workstations for Rhino? I think it is a problem with Rhino on Windows connected to a NAS- or Mac-Server. Maybe the SMB protocol has changed with a Windows update on the workstations. But nevertheless it’s a Rhino problem because every other application is running and saving normally. The only way we could solve this problem was to set up a Windows Server 2019 virtualized on a Mac Pro test machine. There we could save Rhino files without any problems.
So my conclusion is: NAS-/Apple-Server in conjunction with rhino and Windows workstation = saving problems. When using Windows Server the problem does not occur.
But as I said, every other application is running quite well this issue is limited to Rhino.
And the question is, what is happening at the end of the saving process? Because the saved files are well and working just Rhino crashes/hangs at the end of the saving process, because of what…???
I spoke with a McNeel tech specialist a couple months ago. We are using PCs and a TrueNAS server with TrueNAS-12.0-U5 installed. 15 people are using Rhino and sharing the same Rhino files. The McNeel tech said because of the special file dance that Rhino does to save, it won’t save to a NAS. It is because of the lack of quality in the saving process on a Windows Server (because of the MSC application and how Windows writes?)– so McNeel designed their saving process to definitely work on all windows servers and to save locally….BUT as a result, this design commonly does not work with NAS servers. When asked why it worked with FreeNAS earlier version but then did not work with the TrueNAS update – he simply said we were lucky it was saving to the FreeNAS and that any update most likely would have triggered this issue.
He indicated that McNeel has no plan to make it work with NAS servers. He said our options are to:
save locally and drag it over. (That sure does create a lot more room for human error when multiple people collaborate on one Rhino file.)
Put all Rhino work on a Window server share (not practical as all other project files would be on the TrueNAS server)
All, there’s a very specific thing that seems to cause this problem: the “Access Time” setting on files coming from the servers. Here’s something to try:
Open Windows Explorer
Browse to your NAS share
Right-click any file, and then click Properties
In the Properties, what is the “Accessed” date?
For the NAS servers I’ve experienced, the Accessed date is coming back 0 or null or just plain wrong. This is causing Rhino to crash.
I encourage you to see if this is the case, and if so, enable the proper saving and display of “Accessed Date” in your NAS.
I also see that newer versions of Windows Server (2019 in my case) have this setting disabled.
This article might be useful for servers running Windows Server:
How can we proceed here to get to the bottom of this. The things you posted are not the case for us. We use a Mac as our file server and the access times are correct and things have gotten really bad now. Now Rhino just full on crashes unceremoniously when opening certain Rhino files directly from the server.
Just to re-iterate: our server hardware and software has remained unchanged for the last few years, literally I have not come across any other software (including Grasshopper) that displays that behavior and it has only been a problem in the last few versions of Rhino.
Thanks for letting me know that Accessed Date is not apparently the problem in your environment. I looked at your crash report, and it seems to be crashing in the same place as the rest of the crashes we’ve seen.
File I/O in Rhino was written a very long time ago, and is built around an equally old Microsoft technology called MFC. In turn, MFC is checking the file access time when inspecting the file, for some reason. It’s ALWAYS crashing when checking the file access time.
Can we fix this, yes, of course. But to do so is an exceedingly huge pile of work. And is prone to introducing other problems in Rhino. We just don’t want to risk that.
What’s really interesting here is that while you say “our server hardware and software has remained unchanged for the last few years” - that’s equally true for this part of Rhino.
When you say “the last few versions of Rhino” do you mean “the last few service releases of Rhino 7” or “since Rhino 5”?
I’ll DM you a link to Rhino 7.0 - presumably it used to work for you? If it crashes now, that might give us important information.
Thanks for the thorough explanation. It’s understandable that reworking the entire I/O is a bit of a large task for such an obscure bug. It is definitely there though and did not used to exist, as we have been using Rhino since version 5 and basically keep all our data on the file server.
I tried installing Rhino 7.0, but it would mean having to uninstall current Rhino 7, which might mean having to reinstall plugins, setting everything up again, etc.
But I just did another interesting test using Rhino 7 Safe Mode. It would appear that one of the plugins, probably V-Ray, is at fault. Take a look at the recording:
Interestingly Rhino 7 in Safe Mode also crashes if opening files locally, if I load all the plugins. So maybe something else is at fault. But I think it might give some clues.
I will try disabling some plugins in normal Rhino 7 and report back with my findings.
Uninstalling Rhino 7 and installing Rhino 7.0 should not require you to install plug-ins again. My guess is that this problem will exist in your network with Rhino 6.0, too, but that’s pure speculation.
What is strange and why I think that Rhino is at fault and not our server, is that the Parameter incorrect warning comes during first SAVING to the server, so no file already exists on the server. I just save the file and the warning comes up. After that Rhino is unresponsive and has to be force quit.
It’s identical behaviour in Rhino 6, Rhino 7 and Rhino WIP. But those are all the latest versions. I will try installing the Rhino 7.0 version you sent.
It seems that a) it makes a difference if I double-click a file or open it in Rhino and b) if I use Windows’ remove all attributes, I can open the file and save as and it works fine.
It would appear that during saving Rhino adds some attribute that is invalid in the context of the server, maybe something Windows specific? (remember it’s a Mac file server using AFP, but shared with SMB). Once the file is “tainted” and you Save as… it copies those wrong attributes. If you remove the attributes and then Save as… it also doesn’t re-add the wrong attributes. Maybe it helps.
In the mean time, we now actually have a new Mac Mini M1 as our server, but the problem is exactly the same.
I assure you Rhino is nowhere near sophisticated enough to set those properties (in fact, I never even knew they existed).
In the “Remove Properties and Personal Information” dialog, can you please select “Remove the following properties from this file” and then remove properties one at a time? Is there one property that seems to make this work? I can’t actually tell if selecting the properties in that dialog control what gets removed.
I know this is frustrating. I don’t know how to make it better without a massive amount of work on our end.
Out of curiosity, since you’re running a Mac file server, why aren’t you using a macOS for your CAD work and running Rhino for Mac? I bet it plays nicely with your file server.
Can you tell me how you set that up? We have some Mac Mini’s we can try setting this up on. Are you connected via a VPN, or are you connected via local network?
Here’s what I have:
a Mac Mini with M1 called macbuild_m1
I opened System Preferences > Sharing
I shared the “Documents” folder
I clicked Options in the Sharing page, and then selected the user account to work properly with Windows file sharing.
On Windows 10, I mapped the M drive to \\macbuild_m1\Documents
I can open, save, double-click, and otherwise deal with files on that drive from Windows 10.
So… I guess I need more guidance about how to specifically set up a network share that crashes Rhino.
I will try removing the properties one by one to hopefully find the culprit.
I am aware that it might mean a lot of work and quite honestly it’s understandable that you won’t replace it just for this bug. In addition to the server, we are now (literally since today) syncing to Dropbox as well for more easily working from anywhere. We tried VPN, but it’s not worth the hassle just for file sharing.
When we were doing architecture projects we used to all work on iMacs, but nowadays with heavier Grasshopper and real-time 3D rendering, we are mainly on beefy PCs. To be honest the server has worked pretty much flawlessly for the last 8 or so years. I would restart it maybe once a year. I can’t really recall it ever letting us down in any software (and that used to include Rhino for many years), you could read and save to it at the maximum network speed of around 100MB/s. We have a Pegasus R4 drive connected to the Mac Mini. It is connected to our LAN by a bog-standard Gigabit Switch. The files are shared using MacOS’ built-in File Sharing and OS X Server before that shares via the SMB protocol. In Windows 10 we have it mapped as a Network Drive.
Regarding AFP, you’re right - after just checking I see the external drive is actually in MacOS Extended (Journaled).
I am more than willing to chase down this bug in the code if we can repeat it. Once we can repeat the issue, we’ll have a much better understanding of what is going wrong and we can figure out how much effort will be involved to fix it.
We began experiencing this issue on Monday after installing a security and firmware update on our NAS. We have always worked off of various NAS boxes across our network and have until Monday had no issues.
This issue need to be fixed, not “worked around” by the user. Nothing in Rhino’s system requirements states that Rhino is incompatible with NAS environments.
One interesting note: Our NAS (Qnap TVS-h1288X) is capable of hosting virtual machines. If I create a shared folder on the virtual machine hosted by our NAS, we can open and save files to that shared folder with no problems. But adopting this workaround would cause us a significant disruption and time suck of our established work methods.
