none
Deployment Issue (application failed to initialize 0xc0150002)

    السؤال

  • Hello All,

     

    I have a deployment issue/question that I can not understand why it was fixed.

     

    I built an MFC app in VS 2008, which also includes some third party libraries.  Due to the third party libraries the app was dependent on both MFC/CRT 8.0 and 9.0.  Using a deployment utility I built an installation executable that checks for both and installs the missing pieces.

     

    When I tried to execute the app I would receive the "application failed to initialize 0xc0150002" message.  Based on info in the forum I checked the app using the dependency walker.  As expected it could not find either the MFC/CRT 8.0/9.0 dlls.  But checking the Windows/Winsxs directory they both were properly installed - so all the supposed missing dll's were on the system.  Is there some sort of registration process that was missed during an install?

     

    Now here is the weird part - I performed a Windows update on this particular system and updated to .NET Framework 2.0 SP1 (from .NET 1.1 I believe).  This seemed to solve the problem and the application now runs.  My question is that my app is an MFC app (not .NET) and as far as I know is the same for the third party libraries - so why did this update seem to 'cure' the missing dll issue?

     

    Thanks,

    Mike

    26/محرم/1429 02:54 م

جميع الردود

  • Hi Mike,

     

    Are you able to reproduce the issue on another system that has not installed .NET 2.0 sp1?

     

    For side-by-side issues, please see if following blog helps:

     

    Junfeng Zhang's Windows Programming Notes : Diagnose SideBySide failures in Windows XP/Windows Server 2003 (http://blogs.msdn.com/junfeng/archive/2007/06/12/diagnose-sidebyside-failures-in-windows-xp-windows-server-2003.aspx)

     

     

    28/محرم/1429 03:45 ص
    المشرف
  • Walter,

     

    I have not seen the problem on any other systems locally.  The limited number of systems I have access to have already been updated to .NET 2.0.  I do have a customer that originally found the error and am awaiting info back from him to see what his .NET level is.

     

    Thanks,

    Mike

     

    29/محرم/1429 03:11 م
  • Hi Mike,

     

    Thanks for the update.

     

    Then this is probably an environment specific issue. Anyway, please let us know when you have further updated information.

     

     

     

    01/صفر/1429 09:20 ص
    المشرف
  • Walter,

     

    I went back to the event log (to when the application was failing - pre .NET 2.0) and saw were some of the third party libraries I was using were the culprits in locating the correct MFC/CRT dll's.  Even though the 8.0 versions had been installed in Winsxs directory the error message stated not found.  If these libraries were built w/o an embedded manifest could this be the source of the problem?  Could/should I include the manifest (Microsoft.VC80.MFC.manifest) files in the install directory for these libraries?  Will this create any other issues with my application?

     

    Thanks,

    Mike

     

    05/صفر/1429 03:53 م
  • Hi Mike,

     

    What's the version of CRT and MFC those third party libraries are using?

     

    According to:

     

    Troubleshooting C/C++ Isolated Applications and Side-by-side Assemblies (http://msdn2.microsoft.com/en-us/library/ms235342.aspx)
    <blockquote>
    It is recommended that all DLLs have a manifest embedded inside the binary. External manifests are ignored when a DLL is loaded though a LoadLibrary call.
    </blockquote>

     

    If those libraries are not embedding a correct manifest to let them find the CRT/MFC side-by-side assemblies, it will cause such issues.

     

     

    11/صفر/1429 06:00 ص
    المشرف
  • Hey Walter,

     

    I believe the version they are looking for is 8.0.50727.762.

     

    I did find the info below in their documentation - an oversight on my part.  I fully expected to have the MFC/CRT libraries in place but was not expecting that they required a seperate manifest.  I have seen other applications that have a copy of its own Microsoft.x.x.manifest file.  I can cetainly add the files to my install setup - I am just concerned what else am I affecting?

     

    Note:

    LEADTOOLS Requires the following Microsoft C/C++ Runtime files to be distributed in the application's PATH:

    Win32 Platforms:

    msvcr80.dll

    msvcp80.dll

    Microsoft.VC80.CRT.manifest

    mfc80u.dll

    Microsoft.VC80.MFC.manifest

    MFC80ENU.dll

    Microsoft.VC80.MFCLOC.manifest

     

    Thanks,

    Mike

    12/صفر/1429 03:09 م
  • Hi Mike,

    So it looks like the third party library you mentioned is using the CRT assembly as a private assembly:

    Troubleshooting C/C++ Isolated Applications and Side-by-side Assemblies (http://msdn2.microsoft.com/en-us/library/ms235342.aspx)
    <blockquote>
    However, the CRT assembly can also be installed as a private side-by-side assembly in the application's local folder. If the operating system fails to find the CRT or any other assembly as a shared assembly, it starts looking for the assembly as a private assembly.
    </blockquote>

    As the document stated, this private assembly is only tried when the shared assembly is not found, therefore I don't think it will affect any other applications.


    13/صفر/1429 08:54 ص
    المشرف
  •  

    Thanks Walter.

     

    But it does look like I need to include the dll's in the local folder as well as the manifest file - is that the way you see it?

     

    I was hoping to just include an external manifest file(s) that redirected back to the side-by-side assemblies that are already installed (or get installed).

     

    Thanks again,

    Mike

    13/صفر/1429 01:58 م