Autodesk ECSU 2015 installation failure, error codes 1603 & 1619

[walker.troy]

I tried several times to install ECSU 2015 this morning, and each time it would fail... rolling back all software in the suite when it would report only failing on the Softimage portion of the installation. (yes, it took a few hours of trying this to figure out what the problem was... 20 something GB installations getting rollback is a serious pain in the arse).

here's the last few lines of the log that shows the only error, and honestly it doesn't really say much:

2014/4/24:11:34:41 username username-PC Installing Autodesk® Softimage® 2015: TRANSFORMS="E:\DATACA~1\_AIA8BE.tmp\x64\Softimage\Softimage-standalone.mst" ADSK_EULA_STATUS=#1 ADSK_SOURCE_ROOT="F:\Autodesk\Autodesk_ECSU_2015_English_Japanese_Win_64bit_dlm\" INSTALLDIR="C:\Program Files\Autodesk\Softimage 2015\" FILESINUSETEXT="" REBOOT=ReallySuppress ADSK_SETUP_EXE=1 2014/4/24:11:39:43 username username-PC Install Autodesk® Softimage® 2015 Failed Installation aborted, Result=1603 2014/4/24:11:39:49 username username-PC Rollback mental ray® renderer for Autodesk® Maya® 2015 Succeeded 2014/4/24:11:42:08 username username-PC Rollback Autodesk® Maya® 2015 Succeeded 2014/4/24:11:42:25 username username-PC Rollback Autodesk® DirectConnect 2015 Succeeded 2014/4/24:11:42:25 username username-PC Rollback Microsoft Visual C++ 2012 Redistributable (x64) Update 4 Failed Installation aborted, Result=1619 2014/4/24:11:42:25 username username-PC Rollback Microsoft Visual C++ 2012 Redistributable (x86) Update 4 Failed Installation aborted, Result=1619 2014/4/24:11:42:32 username username-PC Rollback Autodesk® Revit® 2015 Interoperability for Autodesk® 3ds Max® and 3ds Max® Design 2015 Succeeded 2014/4/24:11:42:37 username username-PC Rollback Autodesk® Inventor® Server Engine For 3ds Max® 2015 Succeeded 2014/4/24:11:44:35 username username-PC Rollback Autodesk® Populate Data for 3ds Max® 2015 Succeeded 2014/4/24:11:47:24 username username-PC Rollback Autodesk® 3ds Max® 2015 Succeeded 2014/4/24:11:47:33 username username-PC Rollback Autodesk® Material Library 2015 - Medium Image Library Succeeded 2014/4/24:11:47:42 username username-PC Rollback Autodesk® Material Library 2015 - Base Image Library Succeeded 2014/4/24:11:47:57 username username-PC Rollback Autodesk® Material Library 2015 Succeeded 2014/4/24:11:47:57 username username-PC Rollback DirectX Runtime Failed Failure is ignored, Result=1619 2014/4/24:11:47:57 username username-PC Rollback Microsoft Visual C++ 2012 Update3 Redistributable (x64) Failed Failure is ignored, Result=1619 2014/4/24:11:47:57 username username-PC Rollback Microsoft Visual C++ 2012 Update3 Redistributable (x86) Failed Failure is ignored, Result=1619

so, following some of Travis Nave's suggestions, I took a look at the setup.ini file and that log file... and to my surprise was not finding anything related to the issue. To dig deeper, it seems that during the suite installation, additional log files are created in the %temp% directory so I looked through all of those.. without getting any real clue what the problem was. However, in the setup.ini I noticed that nearly all items of the suite had this item as a prerequisite: " _DOTNET35SP1 "

well... I'm on Windows 8.1, and there is and never will be an installer for it. it is already included in the OS, and if it isn't already enabled you have to manually enable it via the control panel > programs and features > turn windows features on/off > check the tick for ".NET framework 3.5". However, I already had that ticked for some other software... so it was already enabled to begin with, but the ECSU installer was somehow failing here. I removed "_DOTNET35SP1" from the reqs... and magically everything installed just fine. so... I really have to question the Q&A/ testing portion of the process there...

I spent probably a solid 3 or so hours working this out and am extremely aggravated by it all. I really wonder if this went through any rigorous testing for Windows 8/8.1 platform because the system I am using is pretty much standard across the board. One exception being that I am also a developer with full Visual Studio 2013, including most binaries for redistribution, and a host of other editing software.. none of which should have caused any related issues with this installer at all. This feature requirement for .NET 3.5 is a huge problem and I honestly can not figure out how that could have been overlooked unless someone just said "let's throw everything at the wall to see what sticks". Looking at how you are still requiring VC++ 2005 RD 1, and nearly every other subsequent patched redistributable since then... 10 years later! I think it is way over due for someone to pull their head out of their butt and get some middle managers in line and get it together over there. Update the dependencies, use the latest frameworks, and just over all clean that house up!

[TravisNave]

I notice you are installing from F:\  Is this a network drive, a usb drive, or disc media?  Try installing from C:\ with local admin rights, UAC off, and anti-virus disabled. 

[walker.troy]

F:\ drive is a data storage drive (RAID array) in my system, it is physically internal hard disks... basically where all my data gets stored (temporary and project related). 

While I may have enough storage to hold both the installation files, temporary files, and the actual installation of the program on my system drive (C:\), this is not a good practice and can lead to fragmentation of the system partition...  so it should be minimally disturbed.  To add, the C:\ drive (on my workstation) is a SSD drive, so using it for temporary cache and multiple read/write operations is also a bad practice and leads to lower MTBF for the unit.

Even though, turning of UAC, anti-virus, and running installers with admin credentials might have worked and potentially could be a work-around for some.. it really is kinda frowned upon and is also a bad practice.  I believe if a product is to work as it should, we should not be circumventing basic security practices for the sake of a work-around to a problem that originates from the product development team.  This doesn't happen to be your problem (even though it looks like it falls on your shoulders for supporting folks), it becomes my problem (and others) and I think this information I've provided should be escalated and address by them.  Don't feel as though I'm pointing at you on this, far from it... I've been right where you are today, just take a peek at my profile or (https://www.linkedin.com/in/tswalker).  I think I know what I'm talking about.

Besides all that, I did get it working for Windows 8.1 installation noted above...   just needed to configure .NET 3.5 the manual way (per microsoft instructions), and remove the prerequisite for ECSU 2015 installation.  Hopefully that little tip will save others hours of frustration and/or work.

I think Autodesk needs to send me a box of cookies or a Starbucks gift card 🙂

[giorgiof]

As I am having the same problem during the 3ds max installation, could you please give me more specific details of what you've done? I've already lost 24 hours of my life trying to fix it. So, I will definitely send you the box of cookies!

[walker.troy]

haha, not necessary.. but a great gesture 🙂 I'll eat a virtual cookie. for me, the fix was a bit perplexing... but worked. I just made sure that the ".NET framework 3.5" was already enabled on the system (this was windows 8/8.1) -> control panel > programs and features > turn windows features on/off > check the tick for ".NET framework 3.5" When you install ECSU, I believe you get the option to "retain" the installation files (incase you want to be able to try again later)... for me, I saved the installation files to my F:\ Drive. So, I was able to go to the root of the installation folder for it @ F:\Autodesk\Autodesk_ECSU_2015_English_Japanese_Win_64bit_dlm and inside that folder, you can find your setup.ini file, make a backup copy of it because you will need to edit it. I went through each section (they are comment like #======= MAX ====== ) for their PREREQUISTE= declarations, and removed the value "_DOTNET35SP1" from all of them. It looks like MAX, MAYA, and SOFTIMAGE still have some dependencies there... however, on Windows 8/8.1 there will never be any installation noted in the OS for these having been installed, they're integrated and enabled/disabled via the control panel (as I noted earlier)... so, when AD tries to check for them.. it fails. Just remove the PREREQUISTE for them, make sure they're enabled (again, like I showed before), and try to reinstall. It is possible, that if .NET 3.5 support had not already been enabled... that their could be some installation required from Microsoft or a reboot.. who knows, for me... it was already enabled via some other developers tools I have. good luck!