/build/static/layout/Breadcrumb_cap_w.png

Random error with Adobe CS3 suite



In certain situations, which I can't point, setup.exe returns an error -1073741811 (0xC000000D) and stops before installing anything. The message is provided by DrWatson (dwwin.exe)

-With or without any command line arguments
-In 3 virtual machines (1x VmWare v5, 2x VmWare v6) on Windows XP SP2
-On two baremetal stations, also on Windows XP SP2

I can't find the problem, in rare occasions the installation will finish as it should, and once after the installation finished, I had watson again with error -1073741818 (0xC0000014).

Setup.exe version is 1.0.135.0

The only thing I could find regarding stop 0xc000000d is about a change in VisualStudio 2005, which now have every functions verifying its parameters and returning this exit instead of a Null or nothing.
First time I could read this was there: http://boinc.berkeley.edu/trac/wiki/AppDebugWin#InvalidParameter0xc000000d
then here: http://support.microsoft.com/kb/947803 (Last line of "Cause" section : "As part of the safe CRT library functions, an invalid parameter exception may be thrown to prevent a buffer overrun.")

Furthermore we discovered the same problem with CreativeSuiteDesignPremium CS3, with the same setup.exe. However, I could not reproduce the problem so far with Illustrator CS3 which have the same setup.exe. Maybe we've just been lucky, or not.

Thanks.

Here is a dump provided by dwwin.exe, if this is of any use for you:
======8<----CUT-HERE--------------------------------
(xml header removed so it doesn't corrupt the mail)
<DATABASE>
<EXE NAME="Setup.exe" FILTER="GRABMI_FILTER_THISFILEONLY">
<MATCHING_FILE NAME="Setup.exe" SIZE="2685088" CHECKSUM="0x6309F52E" BIN_FILE_VERSION="1.0.135.0" BIN_PRODUCT_VERSION="1.0.135.0" PRODUCT_VERSION="1,0,135,0" FILE_DESCRIPTION="Adobe Setup" COMPANY_NAME="Adobe Systems, Copyright 2005-2007" PRODUCT_NAME="Adobe Setup" FILE_VERSION="1,0,135,0" ORIGINAL_FILENAME="Setup.exe" INTERNAL_NAME="Setup.exe" LEGAL_COPYRIGHT="Adobe Systems, Copyright 2005-2007. All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x2981FB" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.0.135.0" UPTO_BIN_PRODUCT_VERSION="1.0.135.0" LINK_DATE="03/16/2007 23:30:15" UPTO_LINK_DATE="03/16/2007 23:30:15" VER_LANGUAGE="Anglais (États-Unis) [0x409]" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
<MATCHING_FILE NAME="kernel32.dll" SIZE="1051136" CHECKSUM="0x89F0C5DB" BIN_FILE_VERSION="5.1.2600.3119" BIN_PRODUCT_VERSION="5.1.2600.3119" PRODUCT_VERSION="5.1.2600.3119" FILE_DESCRIPTION="DLL du client API BASE Windows NT" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Système d'exploitation Microsoft® Windows®" FILE_VERSION="5.1.2600.3119 (xpsp_sp2_qfe.070416-1259)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="© Microsoft Corporation. Tous droits réservés." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x1103F4" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.3119" UPTO_BIN_PRODUCT_VERSION="5.1.2600.3119" LINK_DATE="04/16/2007 16:11:08" UPTO_LINK_DATE="04/16/2007 16:11:08" VER_LANGUAGE="Français (France) [0x40c]" />
</EXE>
</DATABASE>
-----CUT-HERE-->8=================================

0 Comments   [ + ] Show comments

Answers (2)

Posted by: anonymous_9363 16 years ago
Red Belt
0
Hi, François.

At the risk of being accused of banging a very worn-out drum, I'm going to suggest that the only realistic way you're going to find out anything of value is to run the setup.EXE with ProcMon or your favoured process monitor. Anything else will be pure guess-work.

Having said that, the Visual C runtimes are a royal pain in the neck. Do you have the latest version of these? Are your machines by any chance running side-by-side versions? Is there a version alongside the setup.EXE?
Posted by: Francoisracine 16 years ago
Third Degree Blue Belt
0
We ran it on multiple computers, different models. We tested it on vanilla computer too.

What we are seeing:
1. This is happening when we are launching the product from a cmd. We never saw it with a direct command line or the setup.
2. The problem might happend and suddenly stop for many weeks and then reoccur.
We opened a case to Adobe and they did not want to support us because we were using batch files instead of direct commandline.... yes its true!

We have fear to send our package to production because we will never know when the problem will occur.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ