Tech Off Thread

35 posts

Side-by-side screwup

Back to Forum: Tech Off
  • User profile image
    Kaelan

    Something seems to be seriously wrong either with Windows XP or VC++2005. One of my friends is unable to run an application of mine, and the problem has been tracked down to a native win32 DLL that I've been building with VC++2005.

    The main problem seems to be the SXS information being embedded in the DLL. Dependency Walker spits this out:
      Error: The Side-by-Side configuration information in "c:\complex\sys\SOFTFX.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
    If I make VC++ spit out an external manifest, then we have:
    Error: The Side-by-Side configuration information in "c:\complex\sys\SOFTFX.DLL.manifest" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
    Error: The Side-by-Side configuration information in "c:\complex\sys\SOFTFX.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).

    Unfortunately, this makes NO SENSE, because the manifest looks like this:
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1"><assemblyIdentity version="0.0.0.0" name="SoftFX.dll" type="win32"></assemblyIdentity></assembly>

    I'm stumped. Any ideas? For now I'm hoping I can build a VC++2003 project file and compile with 2003.

  • User profile image
    Kaelan

    Yargh! I built a version with VC++2003 and it's giving the same SXS error!

  • User profile image
    TomasDeml

    If you mean manifest of visual styles (comctl32.dll v6.0.0.0), it looks like this:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity
        version="1.0.0.0"
        processorArchitecture="x86"
        name="MyApp.EXE"
        type="win32"
    />
    <description>MyApp.EXE</description>
    <dependency>
        <dependentAssembly>
             <assemblyIdentity
                 type="win32"
                 name="Microsoft.Windows.Common-Controls"
                 version="6.0.0.0"
                 processorArchitecture="x86"
                 publicKeyToken="6595b64144ccf1df"
                 language="*"
            />
        </dependentAssembly>
    </dependency>
    </assembly>

  • User profile image
    Kaelan

    TomasDeml wrote:
    If you mean manifest of visual styles (comctl32.dll v6.0.0.0), it looks like this:

    No, I mean that somehow both VC++2003 and VC++2005 are generating bad Side-By-Side information that makes my DLL fail on some systems (not mine, for whatever reason)

  • User profile image
    Kaelan

    Okay, I researched this with a friend's copy of Virtual PC, using two virtual machines - a stock XP Pro install, and a stock XP Pro install with SP2 installed on top.

    My DLL loads and runs in SP2, but fails in the stock install.

    Why?

    Apparently VC++2003 and VC+2005 are both embedding an entirely useless (and wrong) manifest inside my DLL. SP2 is apparently either ignoring it or able to handle it, while standard XP cannot handle it and refuses to load the DLL.

    If I manually rip out the manifest, the DLL then works on standard XP.

    Anyone have a clue how to fix this without manually ripping the manifest out of every DLL I compile? I kind of need to solve this problem; this application is for the IGF Student Showcase and I have a deadline sneaking up on me. Sad

  • User profile image
    nightwolf__

    Hi Kaelan,

    I have been looking into the same problem recently. Stock XP installations refuse to run my  VS 2005 Beta 2 compiled applications. They only work with SP2.

    Well, I'm not sure about VS 2003, but if you take a look inside your project configuration under VS 2005 Beta 2, you will find an option called "Manifest Tool", with a suboption that reads "Embed manifest", which defaults to "Yes". Turn it off and you should get rid of the embedded SXS. You can also deactivate the manifest file generation from the Linker options.

    I have not tested this yet, but I think it's what you need Wink

    Cheers,
    Andrea.

  • User profile image
    YoY

    I've the same problem..
    do you have find a way to fix it ??

    thanks,

  • User profile image
    rajenk

    Hi all,

    Here is the solution. If you are facing the "Error: The Side-by-Side configuration information " on native 32bit or x64 (non .NET applications) then set "NO" to "Embed Manifest" setting in "Input and Output" section of "Manifest Tool" I had this problem and resolved it by changing this setting to NO.

    The above setting is in its respective Project properties.

    Thanks
    Raj

  • User profile image
    samdutton

    Did anyone manage to resolve this problem?

    I'm running Visual C++ 2005 Express with an application using the Qt framework, for PCs running XP SP2.

    On PCs other than my own I get the error referred to by the original poster: "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001)."

    If I turn off manifest embedding, I get an error to the effect that this type of app cannot be run without the manifest embedded.

    No problems building with Visual Studio 2002.

    I've had a good look in newsgroups, on MSDN and elsewhere on the web, but haven't found a solution. Any pointers or suggestions much appreciated.

    Thanks

    Sam Dutton
    ITN New Media

  • User profile image
    Mike Dimmick

    If you're building with Visual C++ 2005, you're linking with the new version 8.0 C/C++ runtime library (CRT). Microsoft's plan for msvcr80.dll is that it should be shipped side-by-side. Presumably this is why Visual C++ Express complains that you can't disable the manifest generation.

    I suspect that the error you're getting from other machines is simply that the compatible CRT DLLs are not installed. You should use the Microsoft_VC80_CRT_x86.msm merge module if you're using Windows Installer for your installation package. The actual layout of the directories under Windows\WinSxS is, as far as I'm aware, undocumented, and you shouldn't try to install shared side-by-side assemblies by copying files directly into this directory.

  • User profile image
    LC

    Our machine is running with Microsoft Windows XP Professional Version 2002 Service Pack 2. We compile our C++ code with Microsoft Visual Studio 2005. The resulting AssetAllocator.dll causes many problems. Checking this dll with the Dependencywalker gives the message:

    Error: The Side-by-Side configuration information in "c:\windows\system32\ASSETALLOCATOR.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
    Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

    In the past we worked with Microsoft Visual Studio 7 and everything was fine. Since we have installed the new version we are faced to that problem.

    We thank you for your help!Smiley

  • User profile image
    brendanx

    Okay, Google gave this thread the top billing in my search for a solution to the same issue, and other forums even pointed people to this thread as being helpful in solving this problem.  But, I don't think it is all that helpful, and even lead me down a dead-end with the idea of turning off the embedded manifest.

    If I redistributed my EXE without an embedded manifest, I got an error that I was attempting access the C-runtime incorrectly.

    So, for anyone looking for help with this problem, you should read the page on MSDN titled "VC++ How To: Deploy using XCopy":

    http://msdn2.microsoft.com/en-us/library/ms235291.aspx

    To summarize, if you want to redistribute an app with a dependency on the C-runtime, ATL, or MFC without getting into more advanced installers, you can either run the program vcredist_x86.exe, which installs all VC++ 8 redistributable DLLs in the machine's system directory, or you can copy individual directories from "Microsoft Visual Studio 8\VC\redist\x86" (e.g. Microsoft.VC80.CRT) and place these directories beside your application.

    In the old world you could just dropped individual DLLs beside the application.  Now you need the entire "assembly" including its manifest.

    Finally, the page that lead me to this page, titled "Redistributing Visual C++ Files" may also be of use:

    http://msdn2.microsoft.com/en-us/library/ms235299.aspx

  • User profile image
    HoleDigger

    So, I had the same problem as above.  I had developed a dll using Qt that worked fine on my machine but would not register on another.  The familiar "This application has failed to start because the application configuration is incorrect..." appears when I ran the depencency walker on the dll.

    So this was the solution that worked for me, which may help some others see what's going wrong here:

    Within my dll the manifest emedded read:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
    </assembly>

    It seemed that the assembly definition was not found upon my client computer.  So then, from within my original computer's 'Windows\WinSxS' directory, I copied the 'x86_Microsoft.VC80.DebugCRT_1f...' directory and it's associated files within the 'Policies' and 'Manifests' directories onto the client computer.  Once copied, the dll registrered fine. 

    Hope this helps...


  • User profile image
    jsuddsjr

    So, if I read this correctly, I can avoid this problem entirely by A) installing the vcredist package, and B) providing a RETAIL version of the DLL or EXE in question. I don't even need to worry about WinSxS unless a DebugCRT dependency is required.

  • User profile image
    mattlee

    I've ran into this issue a couple times, the first time I overcame it I didn't fully understand why - but now I have a solution I feel I should share.

    I have VS 2005 on my desktop here at work, and I installed VS 2005 SP1 Beta on my work laptop to try it out. Software compiled on my laptop will give the 14001 SxS error that we have all been struggling with on my desktop (and all the other computers I tried to deploy on).

    A valid solution is creating an msi installer with merge modules for MFC and the CRT included, but that is not practical for testing and deploying small apps. Also, if you are installing at a customer site, you don't want to install new SxS policies and manifests that could break other 3rd party apps that the customer depends on. I don't recommend manually messing with the WinSxS directory, as some have had success with. If you copy dll directories only, and not policies and manifests, you can really screw things up. Also, don't just dump tons of DLLs into your System32 folder, another good way to mess things up. Merge modules are cleaner, but have some dev overhead and leave a global footprint. (A policy file will re-route any app asking for an old version of a dll to the newest version. Not good if some other app is not validated with the latest dlls yet.)

    BEST SOLUTION FOR ME:
    I like to drop dlls that my app depends on into the same folder I drop my app into. The trick is to know which dlls your app was compiled with. VS 2005 and the Beta SP1 have different versions of MFC and CRT. Browse to:
    C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86
    Here you will find folders of what you are looking for, little groups of dlls and manifest files to go along. Just copy all the contents into the local path of the exe you are deploying.
    (Most people only see an x86 folder here, but some have AMD x64 and Intel x64 folders for those compile options.)
    You'll notice that Debug dlls are NOT redistributable.
    This local copy also makes uninstalling much easier. Just delete them!

    I was guided by this article, which today apparently does not exist in English, but hopefully MSDN will fix it before anyone clicks on it:

    http://msdn2.microsoft.com/en-us/library/ms235317(VS.80).aspx">http://msdn2.microsoft.com/en-us/library/ms235317(VS.80).aspx

    You can either copy these files manually in a debugging deployment scenario, or add post-build events to copy from your actual Visual Studio 8 folder (use $(Configuration) macro for Debug/Release switch), or add these files to a Setup project.

    -Matt

  • User profile image
    ubhawk

    It seems the Beta SP1 for VS2005 doesn't update some of the manifest files. The version of the new dll's (ATL, CRT, MFC) doesn't match with that of the manifest. Replace the old version number (8.0.50608.0) in the corresponding manifest with the new version (8.0.50727.363) and
    the application should run.

  • User profile image
    g10010111

    Well, I had the same problem trying to debug an app. I tried depends.exe and it returned the above side-by-side error message. I tried the listed solutions, and nothing seemed to fix the dll in question.

    Then I installed VS 2005 SP1. After that, and a recompilation, the problem was gone.

    So, try SP1...

  • User profile image
    hyling

    I've found installing the VS library folders( ie: Microsoft.VC80.CRT)  inside the same folder as the dependent .exe works for loadtime DLLs.  For runtime DLLs which are in their own folder not in the .exe folder, I've only been able to make them work if I don't embed the manifest.  If you don't embed a manifest you must make sure the manifest is in the same folder as the .exe or .dll.  So if you have a myapp.exe you need to make sure myapp.exe.manifest is in the same folder.

    I've tried upgrading to VS 2005 SP1 but that seems to make the problem worse for me.

    HTH
    Hua-Ying

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.