Hi Duncan,
I understand that troubleshooting Rhino problems is hard. Unfortunately, there are very few people experiencing it.
Fortunately, another customer is also experiencing this problem. I’ll work with him to try to troubleshoot and understand it. I’ll also look into your crash report and see if we can understand what’s going on there.
Two people have independently reported that this problem has magically resolved itself. My speculation is that a Windows Update broke and then fixed this. Is anybody still having this problem?
Sorry I’d never updated in this topic after our PM exchange.
The problem has indeed disappeared the same way it came. I also suspected some Windows 10 nastiness along the lines, yet it did appear to be concerning Rhino specifically as well to some extent, as other applications didn’t have a save problem. Yet they also don’t have the “Rhino file dance”, I suppose.
Let’s hope this doesn’t come back anymore.
I too have not seen the error again after the recent 1903 update to Windows 10, but we did notice it in other software. InDesign CS6 would often crash during saving to our file server, which never happened before and doesn’t seem to be happening any longer. Let’s hope that was it.
… and the error is back… in RH6.34 and RH7.7.
It actually are two different issues, both ONLY appearing when saving to an SMB network share.
1.) Is the above described error “Parameter is incorrect” - Rhino becomes completely unresponsive and has to be killed via TaskManager, file gets not saved
2.) Saving kills that Rhino window, though the file gets saved - ususally
3.) Saving locally works fine, so it strongly feels like an network/SMB issue
4.) SafeMode sometimes helps the issue, but not reliably
No other application takes issue with loading/saving from the network, and everything else seems to be nominal.
Anyone ever figured out what exactly is happening here?
Could the devs give us a list of things that would result in that parameters error? Or a description of the “Rhino file saving dance” that was mentioned in one of the earlier posts?
I believe the current dance is something along the lines of:
Having the same error here, after save, rhino becomes unusable. Only for files on a server. Some files when double clicked to open from the server crash before opening, however will open when dragged and dropped into a new file instance of rhino. Same issue in safe mode without plugins.
We also have this issues while overwriting Rhino files on the server with smb connection.
The saved files seem to be ok, but after saving, rhino is unusable or crashes.
Rhino 6 and 7.9 same problem.
I made a procmon log of this process.
I will upload the log file to Rhino - Upload to Support.
-Henning
I worked with another customer on this problem today, and here’s what we learned.
We’re exploring whether an update or downgrade of the NAS firmware will fix this.
How to test this theory
In the case above, the Accessed Date was January 22, 1975 at 2:55 PM. Once we tried to open the file in Rhino, the Accessed Date changed to Noon (no date). These kinds of date inconsistencies happened on all file types, not just Rhino 3dm files.
We are exploring what we can do to mitigate this problem in Rhino, and the fix looks difficult and fragile.
The best option is for you to us a NAS that reliably reports file dates.
Interesting. Definitely not the problem in our case, as we have a Mac file server, but get the same problem now consistently when saving any file to the file server directly. You get the wrong parameter warning, then have to force quit Rhino as it gets “stuck”. Only way to mitigate: save to desktop first, then copy to the file server.
This was not an issue the last 7 years or so of using Rhino, but only started happing like within the last year. The file server has not changed at all and is still on the same OS X version as it always was, so nothing has changed there.
Saying that I will take a look at the permissions and/or access dates for the files and report back.
I just checked the permissions and there is a difference between local files and those on the server, which is to be expected:
What is strange is, that those permissions work fine with literally all other software. It is only Rhino that is by now basically unusable with files on the file server, even though that was never the case before. Since our file server hard and software has not been updated at all for several years (don’t fix, what ain’t broke) it must have been a change in Rhino causing this.
The dates on the files are all correct.
We appear to have this issue as well. We have three licenses for Rhino 7, 6, 5 respectively. I have tested Rhino 7, and 6 and have repeatable error.
Our Rhino 7 is SR13, and Rhino 6 is SR35, and we work off of a TrueNAS server. There are multiple servers and pools, which use SMB to share with windows, and ACL permissions. I have gone through ACL permissions, and tested numerous settings, including sharing with Windows 10 direct login, and giving blanket freedom for ‘Everyone’ with identical results.
The issue seems to be only true when the file is “OPEN” by Rhino. If you make a new file in Rhino and save as any version except current, it will directly save to network share without crashing. You can indefinitely override the save file with an updated save file as long as the version is other that current. (ie. in Rhino 6, you can save as Rhino 5 file, and then override with save as long as it is Rhino 5 file)
Now, if you double click the Rhino5 save file with Rhino 6, it crashes on loading. And if you OPEN the Rhino5 save inside Rhino 6, you can work on file, however now you cannot save over this file as you could previously, or you will crash as previously. You can make another copy save, and continuously override that file, until next open.
Opening the file seems to be causing the save issue. Saving as previous version, doesn’t open the file saved, so can be used as a workaround.
This ‘Parameter is incorrect’ only occurs in Rhino, and is present for all other design applications we use.
Also, working from local disk has no issues.
It seems that everyone who is describing this problem is either working with NAS servers on the network or with a Mac server, correct? Does this problem also occur when working with a Windows Server?
I’ve got a TrueNAS system and Rhino 5 and am having the same issues on this thread. I restarted the computer while it was still open and when it came back it gave me this error. Anyone have any luck yet? Maybe Rhino uses more than the user permissions to make files? Until this gets resolved I guess it’s the “rhino saving dance” for me.
@brian how can we proceed here. It seems like the problems you described with the NAS are not the same as everyone elses.
Having to save locally and copy to a server later is not a satisfactory workaround. No other software is impacted by this, so the error must lie either in Rhino or in a rhino plugin. The error also was not there for many years before, so must have been introduced by an update of Rhino or a plugin.
Hi Armin -
Having read through the complete thread once again, it seems like different issues have been reported over time. I think it might help to get very specific about the current issue at this time.
On your system, is the problem only related to saving files? If so, do you have the advanced setting WriteLocalTempFileWhenSaving set to true or false and does changing this make any difference?
-wim
How do I get to the advanced settings?
found it, sorry. i was trying to enter it as a command.
Currently it is set to false.
Just set the option to true and the error did not appear when saving to the server. Let me try a few files and report back.
Well, that was short-lived. Opened the file again, changed the renderer to Vray, saved file and Rhino just crashed.
No, actually. Once a file shows the “incorrect parameter” warning during saving, when you open that file, it shows the same message and Rhino becomes unresponsive.
If you copy the file with the incorrect parameter to your local drive and then open it, the warning does not appear. But I once more move the file back to the server and open it, Rhino crashes straight away with no error message. The only working way seems to be to save to a local drive, then copy to the server.
The permissions of the file are identical for any other file type on the server, yet non of the other files cause any error when opening (like grasshopper files for example).
