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

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.


Here is a dump provided by dwwin.exe, if this is of any use for you:
(xml header removed so it doesn't corrupt the mail)
<MATCHING_FILE NAME="Setup.exe" SIZE="2685088" CHECKSUM="0x6309F52E" BIN_FILE_VERSION="" BIN_PRODUCT_VERSION="" 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="" UPTO_BIN_PRODUCT_VERSION="" LINK_DATE="03/16/2007 23:30:15" UPTO_LINK_DATE="03/16/2007 23:30:15" VER_LANGUAGE="Anglais (États-Unis) [0x409]" />
<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]" />
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


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?
Answered 07/13/2008 by: VBScab
Red Belt

Please log in to comment
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.
Answered 07/13/2008 by: Francoisracine
Third Degree Blue Belt

Please log in to comment