Saving Failure

Hi Steve!
Done what you asked for. Here you are the error code the command TestLocalTempWriteDebug returned to me:

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

Hope it helps…what you think?


Thanks for testing. I know I’m looking in the right spot now :). Windows is reporting access denied as the error based on this list of error codes

I’ll use this information to try and figure out what to try next.

Thanks again for helping out.

1 Like

I’m glad this info was useful.
Anyways: just ask, I’m happy whenever I can help out !


1 Like

@gian do you see the saving fail both when saving a new file to your network and overwriting and existing file on your network?

Hi Steve,

I see it only when I overwrite an existing one.

Hope this helps.

Hi @gian, do you happen to have an antivirus programs installed beyond Windows Defender?

@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.