Moho Forum

jezjones29 wrote:chucky, here's the link:
https://www.animestudiotutor.com/script ... ps_script/
I've updated the script to fix two bugs a few weeks back.

I wasn't aware of this 'COM surrogate' bug and haven't experienced it, even though I use Moho a lot on Windows and Mac. Lets hope Smith Micro fix it soon.

Chhers Jez!

For anyone having problems successfully saving files on Windows, I've written a script that might help. If saving gives you trouble, try using this menu script and then trying to save again.

https://sites.google.com/site/synthsin/ ... ects=0&d=1

This script just kills every instance of the problem COM Surrogate (dllhost.exe) task, so this should at least save people from needing to do this manually from the Task Manager.

If this works for most people, I can create a Save button script, so people could reassign their File>Save shortcut (ctrl+S) to the button.

And I could incorporate this into my auto-save script.

Thanks for the initiative, Wes! Does the script check for and delete COM surrogates BEFORE executing a save?
But a major part of the problem (for me at least) is that when using "Save" and it goes wrong (due to say a running com surrogate), Moho does not tell you so. Only when using "Save as..." Moho replies back if the save didn't succed. For the same reason the jj-save script is dangerous to use: one can't be sure if the save actually have been performed.
BUT now the story has taken a turn. Some days ago there was a really big Windows 10 update (#1803), and at the same time I had copied the content of my Moho scene file over into a new scene file and saved that with a new name. Which of these things that might have had influence I don't now, but up until now at least, the save problem has gone away!
So I keep my fingers crossed. None the less I will take your script into use, for extra safety. Thanks again!

Tore wrote:Thanks for the initiative, Wes! Does the script check for and delete COM surrogates BEFORE executing a save?
But a major part of the problem (for me at least) is that when using "Save" and it goes wrong (due to say a running com surrogate), Moho does not tell you so. Only when using "Save as..." Moho replies back if the save didn't succed. For the same reason the jj-save script is dangerous to use: one can't be sure if the save actually have been performed.
BUT now the story has taken a turn. Some days ago there was a really big Windows 10 update (#1803), and at the same time I had copied the content of my Moho scene file over into a new scene file and saved that with a new name. Which of these things that might have had influence I don't now, but up until now at least, the save problem has gone away!
So I keep my fingers crossed. None the less I will take your script into use, for extra safety. Thanks again!

Well, the first version I posted just killed COM Surrogate, but here's one that does that and then saves the file: https://sites.google.com/site/synthsin/ ... ects=0&d=1
So if you put it in your scripts>tool folder, you can change the shortcut for File>Save to this button script.

Since I haven't had this problem, I can't really test if this entirely solves the problem. So please verify that this consistently does the trick before relying on it exclusively.

Exellent! Something similar to this should be built into Moho's save command as standard! Thanks a lot!

Funny I've been wrestling with this in 11 as well.

My inelegant solution: after re-starting Windows, open AS (Moho) and leave the program on.

This works pretty well, but make sure you save in case of an automatic update.

Thanks for the tip! A bit unpractical, though - for me at least, as I use several heavy graphics programs, that all fights for memory. And propably it not even ensures safe saving. The uncertainty if Moho did or did not actually save your file is the real nasty thing about this bug (sometimes the save seems to have worked as nothing pops up to say otherwise, but if I check the supposedly saved file, it is not the one saved, but the previously saved one). Plus the fact that it appears in such an unpredictably and sporadic manner.
Until Smith Micro gets to grip with this bug, the only way I will feel safe to save my work in Moho is by using "Save As" and save new and continually numbered files every time, OR by using Wes' script.

Tore wrote:Until Smith Micro gets to grip with this bug, the only way I will feel safe to save my work in Moho is by using "Save As" and save new and continually numbered files every time, OR by using Wes' script.

I don't think any of the animators where I work are seeing this issue (knock on wood,) but we run incremental Save As frequently out of habit and for peace of mind. For extra security, we also use Windows' built-in Previous Versions feature.

Just curious but what are the known conditions for this error? Does it happen with only a particular OS or platform? At work, we're running with Windows 7, and for my personal stuff I'm using Windows 10 but I haven't seen this problem at home either. I'm not saying it hasn't or won't happen here, I just haven't noticed it yet. Thanks for any info.

Greenlaw wrote:

Tore wrote:Until Smith Micro gets to grip with this bug, the only way I will feel safe to save my work in Moho is by using "Save As" and save new and continually numbered files every time, OR by using Wes' script.

I don't think any of the animators where I work are seeing this issue (knock on wood,) but we run incremental Save As frequently out of habit and for peace of mind. For extra security, we also use Windows' built-in Previous Versions feature.

Just curious but what are the known conditions for this error? Does it happen with only a particular OS or platform? At work, we're running with Windows 7, and for my personal stuff I'm using Windows 10 but I haven't seen this problem at home either. I'm not saying it hasn't or won't happen here, I just haven't noticed it yet. Thanks for any info.

Here's one of the former devs explaining how this likely happens: http://lostmarble.com/forum/viewtopic.p ... 01#p157301

Seems the COM Surrogate process used to generate file thumbnails on Windows is hanging, keeping subsequent saves from working. I haven't seen this problem in Windows 8.2, so it sounds like its a machine specific problem, rather than happening for everyone on one particular OS. Anyway, sounds like my script fix is working, until the devs get around to it.