Earlier, I went to shutdown about 15 slaves. Awhile later I visited the rack room and 10 of them were still on. When I went and visited their desktops via RDP, there was an identical error on each system (see attached image). The slaves had been rendering both MAX2014 passes as well as CS4 AE comps.
These slaves are all XPx64, MAX2014.
Any idea what’s triggering these?
Thanks!
Hi Mike,
3dsMax is not supported on Windows XP as of release 2014 anymore. Max2013 is the last version to have official OS support for XP. It’s Win7 or newer from now on…I’m not using XP anymore, but you could try installing the recently released Max2014 Service Pack 1 and ensure you have the latest version of Backburner installed and all your network configuration is good. (your error message relates to Backburner going bang!)
Thanks for the ideas.
I am fully aware that MAX2014 is no longer supported on XPx64 (it is running great). I can not install MAX2014 SP1 as doing so breaks MAX2014 on both workstations and render slaves and MAX will not run… (thank you Autodesk).
These errors are related to Deadline6… not Backburner2014.
I can take a simple test net-render scene (teapots moving across the screen), feed it to BB and it renders flawlessly with no error whatsoever on any slave. Since these slaves have no BB created errors, I have no problem shutting down or restarting these systems remotely. I can then take the same test scene and feed it to Deadline6 and all the slaves will render the job and 9 or 10 out of 15 will throw these errors and the machines can no longer be shutdown or restarted… they have to be powered down completely. Deadline5 did not throw these errors on the same slaves running MAX2014 prior to installing Deadline6.
(As an aside, this simple 300 frame animation renders far faster on BB than D6 using the same slaves for both (All slaves)… which I am also not particularly happy about. Ideally, I would want them to render in approximately the same amount of time. This slowness could be due to errors that Deadline6 is displaying which I will post in another thread).
Thanks again.
Hi Mike,
We really didn’t change how Deadline communicated with Max between versions 5 and 6, so I’m not sure why this error would start cropping up after upgrading Deadline.
At what point does the error popup? Is it during the first task that machine picks up, or is it after a random number of tasks?
Do machines other than these 15 render max 2014 jobs without problems? If so, is there an obvious difference between the machines that work and the ones that don’t?
Can you try using the 3ds Command plugin to test a command line render through Deadline to see if the same problem occurs?
thinkboxsoftware.com/deadline-6-3dscommand/
The additional information from these questions/tests should be helpful.
Cheers,
Ryan,
Sorry it’s taken awhile to get back to this… deadlines. (The client kind… not the software kind).
I turned OFF the Run Sanity Check item in the configuration of the 3dsmax plugin in D6 (and in RPM submit), and then did a test net-render and these errors do not occur on the slaves anymore. (As an aside, this 300 frame render seemed to render fast… finished in about 3-4 minutes).
I did a test net-render using the 3dsmaxcmd function per the setup on the page you linked, and it threw the errors (I had Sanity Check OFF in the submit dialog and plugin setup). (And it took a long time to render using the same slaves as before… 15 minutes and it was only 40% complete… I killed it).
The error is thrown on the first frame that a slave renders.
The farm is setup like this:
MAX2014 on all systems (running great - No SP1)
1 workstation (XPx64 SP2)
1 slave (WinServer 2003x64 - Deadline Repo)
13 slaves (XPx64 SP2)
1 slave (Win7)
With Sanity Check ON via submitting from RPM… some of the 13 slaves produce the error (that makes it impossible to shutdown or restart the machines without a powerdown). With Sanity Check OFF via submitting from RPM, no errors occur (and the machines can be controlled as normal). The WinServer 2003 slave never has the error. (In addition, when these errors occur, they do not stop additional jobs from being rendered from MAX or AE, etc… just cause difficulty in controlling the machines shutdown, restart, etc.).
All these 13 systems have the same OS, same MAX2014, same plugins, etc.
Nothing has changed on any of these systems since Deadline 5.2 was running without error using MAX2014. I assume that Sanity Check was by default running at that time as well. (I don’t really deliberately set it’s use so I don’t know).
So turning OFF Sanity Check seems to stop the errors (and makes the job render fast) but leaving Sanity Check ON throws the errors (and the slaves seem to render the job very slowly). Submitting via 3dsmaxcmd (with Sanity Check OFF) also throws the errors.
Thanks!
Thanks for running these tests and reporting the results! This would imply that the problem is specific to 3dsmaxcmd.exe, and not Deadline. Backburner doesn’t use 3dsmaxcmd.exe, so that also explains why the problem never appeared when using Backburner. Glad to hear that disabling the sanity check worked around this problem for you!
Cheers,
FYI.
Not sure if this helps or hinders…but I believe I’ve got to the bottom of this thread issue, which is also related to Mike Truly’s other thread here:
viewtopic.php?f=11&t=9859
I think it all comes down to installing 3dsMax2014 in a directory/path other than the default one provided by Autodesk, ie: “C:\Program Files\Autodesk\etc…”
So in Mike T’s case it’s: “C:\3dsMax2014_64\3ds Max 2014\3dsmaxcmd.exe”
Although in previous versions of 3dsMax, ie: 2013 and earlier, this wasn’t too much of an issue, I think something has changed in this recent build. As we also have done something similar in our Max2014 deployment, I’m going to take a closer look tomorrow. I’ll report back if I find anything to prove my ‘gut feeling’.
HTH,
Mike
Thanks for the ideas Mike. Yes, I always install MAX at the root level of whatever drive (Usually C Drive). (And I always have UseUserProfiles=0 so that all INI files, etc. end up in that root MAX folder. Makes it far easier to manage plugins, INIs, etc. rather than having them spread all over the file structure).
At least I know how to use Deadline now without having these errors. What is Sanity Check doing exactly? When one has Sanity Check ON, is it using 3dsmaxcmd.exe but when it’s OFF it’s using 3dsmax.exe to render?
Thanks again.
“Run Sanity Check”, I believe, runs the “3dsmaxcmd.exe” to ensure 3dsMax is valid and installed correctly, before attempting to run up a copy of 3dsMax, connect the Lightning.dlx plugin and hence, open the Max file, start rendering, etc.
From the bottom of this web page on the Thinkbox site: thinkboxsoftware.com/deadline-5-3dsmax
Very busy today, so will probably get to my tests I mentioned, tomorrow possibly…(I have someone installing and configuring the software as I write now…)
Yup, that’s correct. In most cases, if 3dsmaxcmd.exe doesn’t run properly, 3dsmax won’t render properly.
Cheers,
FYI.
Looks like Autodesk are going to fix Max2014 running under XPx64:
Kelly Michels @Kelly_Michels 26 Jul
#3dsMax 2014 SP2 coming soon! It primarily has a fix for a XP x64 error on launch. While XP is unsupported we did make this specific fix.
Worth following Kelly on Twitter for the latest product updates 
Thanks very much for this update Mike! Glad to hear that Autodesk is willing to fix this problem even if XPx64 is no longer supported. I really appreciate it.
Thanks again.
