The case of Sendori64.dll and the Softimage startup crash

In this case, a Softimage user reported that on a machine where Softimage had worked on consistently for years, XSI.exe was now crashing at startup with the “Failed to save scene before system failure” error. He’d done all the troubleshooting steps, but still hadn’t found a solution.

It’s hard to resist a challenge like that, so I got my hands on the Process Monitor log, and it turned out to be a bit of an easy case. I went through the Process activity, and just before the crash (you can tell the crash point by where XSI.exe does a ProcessCreate on senddmp.exe), I took a look at the DLLs loaded by XSI.exe. Usually you’re looking for something that doesn’t belong, and when I saw Microsoft, Autodesk, Flexera, Apple, Apache, and…Sendori??? I thought I might have something.

The Google results for Sendori were a bit sketchy (a DNS redirector, yikes), so we removed it, and that fixed the startup crash.

The case of McAfee antivirus, VBScript, and the Softimage startup crash

As I’ve mentioned before, Softimage cannot run without VBScript. You won’t get any errors with xsi.exe, just a crash, usually sometime after the splash screen. But xsibatch will give you some errors that tell you what the problem is:

C:\Program Files\Autodesk\Softimage 2013\Application\bin>xsibatch -processing -script %TEST%\test.vbs
Autodesk Softimage 11.0.525.0

ERROR : 2000 - Failed creating scripting engine: VBScript.
ERROR : 2000 - Failed creating scripting engine: JScript.

It turns out the problem is related to McAfee antivirus, which for some reason has overwritten some important VBScript and JScript registry values.

To fix this, you need to get back the VBScript and JScript registry entries. I haven’t had to do this myself, but I think this page gives a good explanation of the problem and what to do:

You’ll find a number of other pages on the Web about this. For example, here’s a thread on Note that fixing just VBScript is probably sufficient to get Softimage to start, but you’d still be missing JScript.

Related post: The case of the missing vbscript

Checking the Softimage 2013 startup with Process Monitor

The other day, I ran Process Monitor to check out the Softimage 2013 startup.

After a restart of my machine:

  • Softimage 2012.SAP took about 44 seconds to start up.
  • Softimage 2013 took about 42 seconds to start up.

The process activity for 2012.SAP and 2013 look pretty much the same, except that 2013 does all its file and registry activity sooner, rather than later. I don’t know if that’s signficant (my 2012.SAP is an existing install that’s been there for awhile, while I just installed 2013 the other day).

One interesting thing I noticed is the Read Bytes info in the File Summary for Softimage 2013.
Notice how ICE compounds are at the top of the list. Softimage 2013 loads about 53MB of .xsicompound files.

Here’s a look at how the size (in MB) of the factory ICE compounds has grown by release:

2013 55MB
2012.SAP 49MB
2011 SAP SP1 33MB
2010 SP1 13.3 MB
7.5 13.1 MB
7.01 14.5MB

Troubleshooting 101: runonce.bat

Basic troubleshooting for when you cannot start Softimage, or you get strange errors at startup, or you cannot perform basic tasks such as creating primitives or duplicating objects. Or for fixing Softimage after you run a registry cleaner.

Run runonce.bat to re-register the Softimage DLLs and SPDL files (SPDL files describe the parameters of objects and operators in Softimage).

runonce.bat does a lot of what happens during installation and it is a lot faster than removing and then reinstalling Softimage.

runonce.bat mentions on xsibase, si-community, the AREA, and the XSI list

User locations for 32- and 64-bit Softimage

If you have both 32- and 64-bit Softimage installed, both versions will use the same User location. If you want separate User locations, you could modify the XSI.bat file that launches Softimage.

For example, setenv.bat defines an XSI_CPU environment variable, so you can check that and then reset XSI_USERHOME:

@echo off
call "C:\Program Files (x86)\Autodesk\Softimage 2012.SAP\Application\bin\setenv.bat"
if "%XSI_CPU%"=="nt-x86-32" set XSI_USERHOME=%XSI_USERHOME% (x86)
start "" "C:\Program Files (x86)\Autodesk\Softimage 2012.SAP\Application\bin\XSI.exe" %*

This will give you a User location like
C:\Users\blairs\Autodesk\Softimage_2012_Subscription_Advantage_Pack (x86)

The case of the missing anchors

In this case, a customer reported that the Add to Menu list in the Command Wizard was empty. Normally, Add to Menu lists all anchor points for menus where you can add a custom command, but now it had just one entry: None.

The SDK wizards are JScript plugins, so it wasn’t hard to track down where things were going wrong. The Add to Menu list is built by parsing a header file (xsi_decl.h):

var oFSO = new ActiveXObject( "Scripting.FileSystemObject" ) ;
strFactoryPath = Application.InstallationPath( siFactoryPath ) ;
strDeclFile = XSIUtils.BuildPath(XSIUtils.Environment("XSISDK_ROOT"),"include","xsi_decl.h") ;

Based on this, it didn’t take to long to figure out the problem: the customer was starting Softimage with a shortcut to XSI.exe, so setenv.bat was never called, and XSISDK_ROOT was never set.

XSI.bat is the way to start Softimage. XSI.bat calls setenv.bat to set all the required environment variable, and then starts XSI.exe.

Setting workgroups at startup

Here’s a simple, low-tech way to connect to specific workgroups at startup:

Instead of xsibatch -w or xsi -w, you could modify setenv.bat to create another .xsipref file in %XSI_USERHOME%\Data\Preferences. Whatever is in that file will override what is in default.xsipref.

So, for example, you could do this:

echo data_management.workgroup_appl_path	= C:\Users\blairs\MyWorkgroup >  %XSI_USERHOME%\Data\Preferences\workgroups.xsipref

or you could use an environment variable:

echo data_management.workgroup_appl_path	= %MY_XSI_WORKGROUPS%  >  %XSI_USERHOME%\Data\Preferences\workgroups.xsipref

This does require you to edit setenv.bat, which isn’t so useful if you have a lot of seats. In that case, if you use a network deployment, you could deploy a %XSI_BINDIR%\SiteDeploy.bat file and use that to echo out the workgroup preference.

Startup comparison for Softimage, 3ds Max, Maya

The other day I was using Process Monitor to see where Softimage spent its time during startup, and I was curious to see how Softimage compared to the big two. So, here’s some numbers.

I did this shortly after restarting my machine, so I didn’t have my usual kazillion different windows and apps open. Softimage didn’t have any workgroups, and Max and Maya were pretty much fresh installs.

Total Elapsed Time Total Event Duration # Logged Events
Softimage 34s 2.76s 817.4K
Maya 46s 38.7s 58K
3ds Max 2:03 81s 195K

Total elapsed time is the time from the first logged event to the last.
Duration is the sum of all event durations in the Process Monitor log.

If we look at the process activity timelines, we can see that:

  • Softimage uses the registry way more than Maya or 3ds Max.
  • Maya does more file i/o in terms of bytes, but Softimage has more file i/o operations. When a machine is more loaded up (more runnung processes), this is where Softimage spends more time.

Softimage startup times

Here’s a few things you can do to diagnose slow startups.

First, try starting Softimage in the factory-default configuration. The quickest way to do that is to simply rename your Softimage User folder. If you see a difference in startup times, then it may be due to workgroups or the addons and plugins you have installed.

You can use the XSI_LOG_LOAD_TIME environment variable to log the load times for libraries and plug-ins at startup. Add this line to your setenv.bat, or set it in a Softimage command prompt before you run xsi.exe:


That will get you something like this in the history log:

// Initialize Mental Ray: Elapsed time (ms): 563.28
// Load Command Definitions: Elapsed time (ms): 1293.66
// Project List Initialization: Elapsed time (ms): 53.00
// Load Views and Shelfs: Elapsed time (ms): 1453.46
// Scan for Custom SPDLs: Elapsed time (ms): 74.33
// Load Layouts: Elapsed time (ms): 356.29
// Loading User plug-ins: Elapsed time (ms): 239.25
// Loading User addon plug-ins: Elapsed time (ms): 0.28
// Loading Workgroup plug-ins: Elapsed time (ms): 0.00
// Loading Workgroup addon plug-ins: Elapsed time (ms): 0.00
// Loading Factory plug-ins: Elapsed time (ms): 2173.86
// Loading Factory addon plug-ins: Elapsed time (ms): 2611.39
// Loading setup plug-ins: Elapsed time (ms): 0.03
// XSI Init: Elapsed time (s): 31.92

Another thing you could do is run Process Monitor to capture a log of all XSI.exe startup activity, and then check the log for any “suspicious” activity. All the entries are time-stamped, and you add a Duration column to see how long activity took.

You can even filter on the Duration, to quickly check for anything that took excessively long (for example, Duration more than 0.02). The Tools menu also has some useful stuff, like a File Summary:

and a Process Activity Summary:

NOTE The time spent can vary from startup to startup, so I wouldn’t jump to conclusions based on just one log. I’d log multiple startups to see if there was a definite pattern. For example, one time I saw xsi.exe spend three seconds reading adlmint.dll, the next time it was less than .001s.

EAGAIN Resource temporarily unavailable for tmp/.X11-unix/X0

This post is for Softimage 2011.5 on Linux, and for Google (I’ve posted about this before, but I didn’t include the strace output that time).

If Softimage doesn’t seem to want to start, or if it is taking forever to start, and you see something like this in your strace log. Note lines 02,03, and 18:

connect(19, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 20) = 0
getpeername(19, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, [20]) = 0
uname({sys="Linux", node="homer", ...}) = 0
access("/var/run/gdm/auth-for-xxx-Q2I4go/database", R_OK) = 0
open("/var/run/gdm/auth-for-xxx-Q2I4go/database", O_RDONLY) = 20
fstat(20, {st_mode=S_IFREG|0600, st_size=50, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3360deb000
read(20, "\1\0\0\5homer\0\0010\0\22MIT-MAGIC-COOKIE-1"..., 4096) = 50
close(20)                               = 0     
munmap(0x7f3360deb000, 4096)            = 0
getsockname(19, {sa_family=AF_FILE, NULL}, [2]) = 0
fcntl(19, F_GETFL)                      = 0x2 (flags O_RDWR)
fcntl(19, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
fcntl(19, F_SETFD, FD_CLOEXEC)          = 0
poll([{fd=19, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=19, revents=POLLOUT}])
writev(19, [{"l\0\v\0\0\0\22\0\20\0\0\0", 12}, {"", 0}, {"MIT-MAGIC-COOKIE-1", 18}, {"\0\0", 2}, {"\367\371\200\336\321\\\37\4\22\0324\274\3356|\313", 16}, {"", 0}], 6) = 48
read(19, 0x27ae690, ) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=19, events=POLLIN}], 1, -1)   = 1 ([{fd=19, revents=POLLIN}])

then you probably need to put back our x11 patch.