Saving Failure

@kevin3 are you still experiencing save errors?

If you follow the steps below, do you also get an error message?

If you want the latest RC, it’s 7.12, and you can get it from Rhino - Download - Rhino 7 for Mac

Hi Steve!

Sorry but no: no antivirus Beyond Defender…

Hi @stevebaer,

I typically work with WriteLocalTempFileWhenSaving=True, along with saving uncompressed files, to gain savig speed. The files are saved on the local network server. I was experiencing the writing error problem with these settings every now and then, without a visible specific pattern. Maybe the only clue is it would work fine for a while, 20-30 saves, and then it would throw an error, the original file would disappear and I only could save the file if I turn off the LocalTemp saving. And until Rhino gets restarted, I can’t go back to the LocalTemp=True setting.

I just saw this thread today and as soon as it happened again I ran the TestLocalTempWriteDebug command, here is the result:

Error found: MoveFileExW returned false (err code = 1450)

If it helps with anything, I am running TrendMicro antivir, and have ‘live’ Carbonite backup going.
Maybe that helps to isolate the error.


Hi @stevebaer

I’m afraid to say that, apart the old network saving problem is not solved (unless unchecking the famous “fast saving” option) now, even worse, there’s another saving problem: a NEW one.

It happens when trying to export an .STP (in my case I tryed only .STP format) to a network drive.
I translate here the attached screenshot of the alert that appears:


Impossible to save as “F.\ …etc… .STP”
Plug-in file writing operation failed.

This happened in the last days, after one of the last updates. The months/years before I exported to a network drive HUNDRED, or maybe THOUSAND of times and it never happened.

PS: I’ve seen someone have a similiar issue, at this post:
File Writing plug in failed
There’s @pascal working on it…

Hi Gianpietro - I take it you can save locally, say to the desktop, correct?


Yes, correct @pascal

What I have to do is saving locally, i.e. to desktop, and then copy the file to its position in the network drive, via windows explorer.

_ Gianpietro

@tim - do you have an idea what might be going amiss here? My understanding is there is now a temp file created for step export, which used not to be the case, but that in general this works on networks…?
@gian - can you please copy and paste the output from the commandSystemInfo in Rhino?

Yes, of course.

Rhino 7 SR12 2021-11-2 (Rhino 7, 7.12.21306.15001, Git hash:master @ 5b29f2d5cf917d92f3e5e04559fbfbfdd15696ac)
License type: Commerciale, build 2021-11-02
License details: Cloud Zoo

Windows 10.0.17763 SR0.0 or greater (Physical RAM: 16Gb)

Computer platform: LAPTOP - Plugged in [100% battery remaining]

Hybrid graphics configuration.
Primary display: Intel(R) HD Graphics 4600 (Intel) Memory: 1GB, Driver date: 10-29-2018 (M-D-Y).
> Integrated graphics device with 3 adapter port(s)
- Windows Main Display is laptop’s integrated screen or built-in port
- Secondary monitor attached to adapter port #1
Primary OpenGL: NVIDIA Quadro K1100M (NVidia) Memory: 2GB, Driver date: 4-23-2019 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 425.45
> Integrated accelerated graphics device (shares primary device ports)
- Video pass-through to primary display 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: 4-23-2019
Driver Version:
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24 bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 2 GB

Rhino plugins that do not ship with Rhino
C:\Users\gian\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\iris\0.6.6\Iris.WinR6.rhp “Iris”

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 7\Plug-ins\Commands.rhp “Commands” 7.12.21306.15001
C:\Program Files\Rhino 7\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 7\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 7.12.21306.15001
C:\Program Files\Rhino 7\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 7.12.21306.15001
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.12.21306.15001
C:\Program Files\Rhino 7\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 7.12.21306.15001
C:\Program Files\Rhino 7\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 7\Plug-ins\Displacement.rhp “Displacement”

PS: This thing happens also on my desktop workstation. Now I’m not at office, but if you like I can reproduce the issue there as well, sending you the system details about it tomorrow.

Ok - thanks - meantime, it would not hurt to update your gpu drivers… (unrelated to this saving problem)

“Driver date: 10-29-2018”


Yeah I know about the drivers.

Actually the ones to really update are the NVIDIA ones, which are old as well, even if newer (2019).

I use my PC just for professional purposes (no gaming) and thus I usually update video drivers only when it’s strictly necessary (i.e. some software/app update/upgrade doesn’t work aymore with the old ones). That’s beacaus in the past, with MS Windows, video drivers were the ones creating the biggest problems and BSODs.

Step export writes a temp file to a user writeable directory first. This is mostly because the version of StepTools we use right now will only accept a char path. After the temp step file is written we use ReplaceFileW to move the file to it’s final destination with a wchar_t path. The incentive to do this was mainly for the sake of better handling of wchar_t paths but a potential positive side effect (apparently in most cases) was better handling of writing step files to network/cloud drives.

@tim does this means that this situation will not be fixed to keep the advantages versus side effects ?

Ah! One important detail also for @pascal and @stevebaer : one file is actually written in the correct place and with the correct name (even when the alert says the process failed), but it’s an empty 0 Kb file.

Hope it helps.


It means that so far, you’re the only one that has had a negative impact, at least that I’m aware of. It could be that not very many people use step export or it could be that it’s working ok for others. I guarantee if it was a large scale problem I’d be hearing about it. Is this happening for all of your exports to step or only with particular models? For instance, if you make a very simple model, like a box, and export to step, does it still have the problem?

@tim this is the same technique that I wrote for saving 3dm files to network locations and couldn’t turn the feature on by default because of unknown failures for systems like Gianpietro’s.

We should probably key your file writing technique off of the same advanced setting as I am using.

1 Like

Hi @tim

thank you, first of all. To answer to your questions:

YES, it happens also with VERY simple geometries (i.e. a single BOX)


NO, it doesn’t happens with other formats I export frequently, like STL or OBJ (I didn’t test many other formats aside STP, STL and OBJ though)

OK. This is the YT issue to track this. I’ll start in on it today.

1 Like

Thank you @stevebaer , this would be a great help, again! These saving issues are a big big hassle, I reckon!

And @tim , I think I was not the only one with these kind of problems in saving 3dm files…and now I suppose not to be the only one facing the same problem in exporting STPs, sincerely.
The problem started with one of the last updates, by the way, so maybe (maybe!) there’s other people, experiencing the same behaviour, which did not reported it yet.

PS: thank you to you too @tim !