none
R6034 - attempt to load C runtime library without using manifest.

    Question

  • I've got a 32bit C++/MFC application that gets the R6034 error on startup.  Seems odd as the application does have a manifest.  And another application that I build the same way starts fine.

    If I compile the applicaton 64bit, it fails with "Unable to start program..."

    Are there any ways to debug manifest/dependency problems?


    Friday, September 23, 2005 12:02 AM

Answers

  • Nikola's blog (http://blogs.msdn.com/nikolad/) contains lots of information on how to debug fusion & manifest issues. Take a look at http://blogs.msdn.com/nikolad/articles/427101.aspx.

    Hope this helps!

    Thanks,
      Ayman Shoukry
      VC++ Team
    Friday, September 23, 2005 12:16 AM
  • If you build your application as 'DEBUG', you should get a DebugBreak() dialog box when you run it.
    Then, if you break into the code, you'll see __CRTDLL_INIT on the stack.
    In that function (in crtlib.c), right before the _NMSG_WRITE, you can set a break point on _check_manifest() and re-run the application.
    Stepping into _check_manifest() will tell you why it thinks that no manifest was used to load the CRT.

    Thanks,
    George Mileka
    VC++ Libraries

    Monday, September 26, 2005 5:25 PM
  • Claus,

    The sample you attached in the bug is building a dll. For dlls, the manifest must be embedded on any operating system (to be taken into account by the loader).

    So, if I add:

       mt.exe -outputresource:Assembly.dll;#2 -manifest Assembly.dll.manifest

    to the makefile after the link command, it does the job.

    Note that in the link command, you have passed a keyfile. So, running mt.exe afterwards will invalidate the signing. To get this working you need to delay sign the dll and then, run mt.exe and sn.exe.

    Here's a possible way of writing the make file:

    FLAGS= /nologo /c /TP /clr:oldSyntax
     
    DEFINES= -DNDEBUG -D_WINDLL -D_M_AMD64 -D_WIN64 -D_AMD64_ -DWIN64
     
    KEY_FILE=Regasmtest.snk

    MT_EXE_CMD=if exist $@.manifest mt.exe -outputresource:$@;1 -manifest $@.manifest
    MT_DLL_CMD=if exist $@.manifest mt.exe -outputresource:$@;2 -manifest $@.manifest
    SN_CMD=sn -R $@ $(KEY_FILE)

    LD_FLAGS= /DLL \
              msvcmrt.lib msvcrt.lib \
              kernel32.lib mscoree.lib /machine:X64 /nologo /incremental:no /nodefaultlib /manifest
     
    LD_SIGN_FLAGS=/keyfile:$(KEY_FILE) /delaysign

    Assembly.dll: AssemblyInfo.obj Application.obj           
           link $(LD_FLAGS) $(LD_SIGN_FLAGS) /out:$@ AssemblyInfo.obj Application.obj
           $(MT_DLL_CMD)
           $(SN_CMD)
           regasm Assembly.dll
     
    AssemblyInfo.obj: AssemblyInfo.C
           cl $(FLAGS) $(DEFINES) AssemblyInfo.C

    Application.obj: Application.C
           cl $(FLAGS) $(DEFINES) Application.C

    clean:
           del *.obj
           del Assembly.dll*

    all: clean Assembly.dll

    Let me know if this does not solve the problem.

    Thanks,
    George Mileka
    Visual C++ Libraries

    Tuesday, September 27, 2005 7:53 PM

All replies

  • Nikola's blog (http://blogs.msdn.com/nikolad/) contains lots of information on how to debug fusion & manifest issues. Take a look at http://blogs.msdn.com/nikolad/articles/427101.aspx.

    Hope this helps!

    Thanks,
      Ayman Shoukry
      VC++ Team
    Friday, September 23, 2005 12:16 AM
  • We recently downloaded the RC build of Whidbey, and ran into a similar issue on Windows XP x64 - during the build process, we run regasm, which displays this error message.

    We could not really find documentation on this problem so far, so we looked up the CRT source code and found a function called _check_manifest() which raises this error message. Apparently, it checks that the instance of the CRT which it is part of was loaded through Fusion under the guidance of manifest files (on the most recent OS versions, that is), and if that is not the case, it bails out.

    In our case, regasm actually loads two instances of the CRT into its process - one of them comes from a side-by-side (SxS) directory, so it was probably loaded through the manifest mechanism; the other instance, however, comes from a local build directory where we store a copy of the DLL. That copy, however, also has a manifest, so we're actually puzzled why we get the error message. I just discovered Nikola's blog, and it does seem to contain some interesting information on this area, but any additional hints or pointers are most welcome.

    Claus

    http://www.clausbrod.de

    Saturday, September 24, 2005 10:35 AM
  • I've found one interesting difference between the application that works and the one that doesn't - both have external manifest files that seem to be fine (just CRT and MFC, correct versions, etc.)  The application that doesn't work has a manifest resource (correct ID) that only lists Microsoft.Windows.Common-Controls 6.0.0.0.  This is missing from from the external manifest file.  Also, my machine only has the following common controls manifests on it:

    amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.1433_x-ww_4B80EF29.manifest
    amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.1830_x-ww_4D792D2A.manifest
    amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.1433_x-ww_AAF534AE.manifest
    amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.1830_x-ww_ACED72AF.manifest

    wow64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.1433_x-ww_001B8FC7.manifest
    wow64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.1830_x-ww_0213CDC8.manifest

    x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.1433_x-ww_19770949.manifest
    x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.1433_x-ww_19770949.manifest

    Why would there be both internal and external manifests and why would they be different?
    Monday, September 26, 2005 4:42 PM
  • If you build your application as 'DEBUG', you should get a DebugBreak() dialog box when you run it.
    Then, if you break into the code, you'll see __CRTDLL_INIT on the stack.
    In that function (in crtlib.c), right before the _NMSG_WRITE, you can set a break point on _check_manifest() and re-run the application.
    Stepping into _check_manifest() will tell you why it thinks that no manifest was used to load the CRT.

    Thanks,
    George Mileka
    VC++ Libraries

    Monday, September 26, 2005 5:25 PM
  • Ernie: Thanks for the details on your observations; we'll check the manifest situation again on our system to see whether there are any similarities to your situation.

    George: We already debugged into _check_manifest(). It calls FindActCtxSectionString() to verify whether the runtime library (MSVCR80.DLL) was in fact loaded through a manifest file. FindActCtxSectionString() claims that MSVCR80.DLL wasn't loaded through the manifest, and so _check_manifest() fails, causing the calling code to display the R6034 error message.

    Earlier today, we submitted a bug report at http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=5169ccf9-5756-4c1e-84d8-38c711219f9e. When we submitted the report, we did not have repro data which we can share in public, which is why we didn't attach the test data there. We are, however, working on a simple test case which we will hopefully be able to share tomorrow.

    Claus Brod

    Monday, September 26, 2005 5:53 PM
  • My problem is now solved.

    Someone on our team had added a hand coded manifest to the resource file for this application, it had the 6.0.0.0 Microsoft.Windows.Common-Controls reference in it.  I suspect that windowx XP x64 was using the internal manifest and ignoring the manifest file, thus reporting that the runtime was being loaded w/ out a manifest.  Removing this resource has solved the problem.

    From http://blogs.msdn.com/nikolad/articles/427101.aspx, it indicates XP should respect manifest file first, then resource and 2003 server the opposite.  Since the x64 version of XP came out with 2003 SP1, I suspect they both respect the resource first.

    This thread did wonders helping me track this down.

    Thanx guys.
    Monday, September 26, 2005 10:26 PM
  • Claus,

    About internal and external manifests I'd like to bring up something that might be helpful.

    If an exe has both internal and external manifests, then:
    - On Windows XP, the internal one is ignored and the external one is used. So, if the external one is bad or missing dependencies, then, you get the problem you are seeing.
    - On Windows 2003, the internal one is what gets used even if an external manifest file exists.

    Thanks,
    George Mileka
    VC++ Libraries
    Monday, September 26, 2005 11:57 PM
  • George,

    thanks for the background on internal/external manifests. Which camp does XP Professional x64 belong to? Which of the two kinds of manifests (internal/external) will have priority?

    Thanks!

      Claus Brod

    Tuesday, September 27, 2005 6:57 AM
  • Claus,

    The sample you attached in the bug is building a dll. For dlls, the manifest must be embedded on any operating system (to be taken into account by the loader).

    So, if I add:

       mt.exe -outputresource:Assembly.dll;#2 -manifest Assembly.dll.manifest

    to the makefile after the link command, it does the job.

    Note that in the link command, you have passed a keyfile. So, running mt.exe afterwards will invalidate the signing. To get this working you need to delay sign the dll and then, run mt.exe and sn.exe.

    Here's a possible way of writing the make file:

    FLAGS= /nologo /c /TP /clr:oldSyntax
     
    DEFINES= -DNDEBUG -D_WINDLL -D_M_AMD64 -D_WIN64 -D_AMD64_ -DWIN64
     
    KEY_FILE=Regasmtest.snk

    MT_EXE_CMD=if exist $@.manifest mt.exe -outputresource:$@;1 -manifest $@.manifest
    MT_DLL_CMD=if exist $@.manifest mt.exe -outputresource:$@;2 -manifest $@.manifest
    SN_CMD=sn -R $@ $(KEY_FILE)

    LD_FLAGS= /DLL \
              msvcmrt.lib msvcrt.lib \
              kernel32.lib mscoree.lib /machine:X64 /nologo /incremental:no /nodefaultlib /manifest
     
    LD_SIGN_FLAGS=/keyfile:$(KEY_FILE) /delaysign

    Assembly.dll: AssemblyInfo.obj Application.obj           
           link $(LD_FLAGS) $(LD_SIGN_FLAGS) /out:$@ AssemblyInfo.obj Application.obj
           $(MT_DLL_CMD)
           $(SN_CMD)
           regasm Assembly.dll
     
    AssemblyInfo.obj: AssemblyInfo.C
           cl $(FLAGS) $(DEFINES) AssemblyInfo.C

    Application.obj: Application.C
           cl $(FLAGS) $(DEFINES) Application.C

    clean:
           del *.obj
           del Assembly.dll*

    all: clean Assembly.dll

    Let me know if this does not solve the problem.

    Thanks,
    George Mileka
    Visual C++ Libraries

    Tuesday, September 27, 2005 7:53 PM
  • George,

    thanks a lot! Once we had broken down the issue to the small test example which we posted, we also quickly tracked it down to the difference between external and internal manifests - but when I went back to the bug report site to add a note about it, I found you had already beaten us to the punch .-)

    Thanks also for the neat recipe of how to embed the manifest without having to re-link! We're now using this technique in our build scripts, and it works great.

    Thanks again!

      Claus


    Wednesday, September 28, 2005 12:43 PM
  • Hello,

    I've the same problem that Claus had:
    where my application loads: " two instances of the CRT into its process - one of them comes from a side-by-side (SxS) directory, so it was probably loaded through the manifest mechanism; the other instance, however, comes from a local build directory".

    When i tried to emped manifest to this application, I got the following error:
    "Unable to start program 'application.exe'.
     This application has failed to start because of the application configuration is incorrect. Review the manifest file for possible errors........"

    here is the content of the manifest file:
    "<?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.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
        </dependentAssembly>
      </dependency>
    </assembly>
    "
    also the applicaiton is mixed mode.

    Thanks,
    Mostafa
    Sunday, October 30, 2005 7:05 PM
  • Hello,
    The problem was caused be the applicaiton.config file, when deleted everything is working fine.

    Thanks,
    Mostafa
    Sunday, October 30, 2005 8:56 PM
  • I am trying to write an add-in DLL to extend the Mozilla Firefox browser, and am getting the R6034 "An application has made an attempt to load the C runtime library incorrectly" error when Firefox starts up with my DLL installed. My DLL has a manifest which correctly references the dependency on the Microsoft.VC80.CRT assembly. However the Firefox executable does not have a dependency on Microsoft.VC80.CRT, though it does have an embedded manifest, which appears to be correct. It appears that when my DLL is installed, Firefox tries the load the VC8 runtime when it starts up, which of course produces the R6034 error. Does anyone have any suggestions as to what to do here?

     

    If I put an external firefox.exe.manifest file into the folder where the firefox.exe executable resides, the error goes away, but I can't do that when redistributing my DLL. I also have no control over the Firefox executable. So what can I do in this scenario, where I have a DLL that depends on the Microsoft.VC80.CRT assembly (and which has a correct manifest that reflects that), but which is being used by an executable (Firefox, over which I have no control) that doesn't have the VC80 runtime dependency, and whose embedded manifest does not refer to Microsoft.VC80.CRT?

    Tuesday, August 21, 2007 12:46 PM
  • Hi,

    any one have solution to the above mentioned problem?

    Wednesday, October 17, 2007 8:42 PM
  • Hi,

    I have a problem that is more than a bit frustarting. I have a collection of dlls (namely ORBacus dlls) which I managed to compile with VS2005. There exist a collection of programs in VC6. I should run these programs (ones in VC6) with the new dlls(Orbacus dlls compiled with VS2005).

    To test whether the problem is with dlls or the application, I've wrote a test program with VS2005 which do the same, and it works correctly.

    I've got the same sort of error messages  pointed out in this  thread.
    I've tested either manifast embeded in dlls, or separated from them. Although I knew that it would not work, I also tested dllls without any manifast at all.

    When I put these MSVC80 ... dlls beside my exe. An assertion with number R6034 will be presented to me saying that an application is trying to loasd a dll without its manifast. After that all things will go wrong.

    I've also tested all sorted possible solution suggested in this thread.

    Thanks in advance,
    Mohamad Ali Honarpisheh
    Thursday, October 25, 2007 10:45 AM
  • Mohamad,

     

    You could attach the debugger when the popup is displayed and check who's trying to load the CRT incorrectly...

     

    The problem you're seeing usually happens if somebody tries to LoadLibrary() the dlls directly.

     

    Thanks,
    George Mileka
    Visual C++ Libraries


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, November 14, 2007 6:11 AM
  •  

    DexterDurai,

     

    Are you referring to Wengyik Yeong entry?

    If so, could you try deploying the VC runtime to the winsxs folder using the redist msms or the vcredist?

     

    The real question is why Fire Fox is trying to load the CRT dlls directly... Most likely this happens only when the dlls are the same folder as the exe...

     

    You could also try deploying the VC runtime to a subfolder that has the same name as the assembly and see if exe still tries loading the CRT...

     

    Thanks,
    George Mileka
    Visual C++ Libraries

    Wednesday, November 14, 2007 6:24 AM
  • Reply to Wengyik Yeong
    I experienced the same problems with my extension.
    It turned out that I needed to compile and link debug to load it with a debug firefox
    and release to load it with a release firefox.
    While this works it seems annoying so I have posted about it here:
    http://forums.mozillazine.org/viewtopic.php?t=603743

    Thursday, November 15, 2007 11:47 PM
  • mh, I'm having the same error for a simple .exe application, and something seems quite strange.

    the (embed) manifest seems correct, I tryed stepping into _check_manifest(), and again, it's FindActCtxSectionString() that fails.

    now, for the strange part: when looking at the manifest file, it starts with bytes '0xEF 0xBB 0xBF'
    which translate to: ""

    this is my app.exe.embed.manifest file: (added quotes)

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

    if I remove manually the first three bytes, and build once more the project, the error disappears and everything seems to work fine...
    however, as soon as a rebuild is made, and the .embed.manifest file is regenerated, these 3 bytes come back, and so does the error...

    manually editing the manifest after each rebuild turns out to be quite stressing...
    anyone knows any way around this? (are these bytes actually meant to be here? what are they for?)

    Tuesday, January 01, 2008 8:56 PM
  •  

    I am sorry – after reading all of that I kind of did not

    get the solution. Could anybody please take a look at the following:

     

    Problem: old program with native windows (no MFC or .Net), does not start on 64-bit XP. 32-bit version from the same solution (VC2005) works fine. I am forced to use Common controls 6.0.0.0  since we use advanced list view styles

     

     

     

    32-bit generated (with help from pragma statement for Microsoft.Windows.Common-Controls). It takes forever to start the application, but it eventually works.

     

    <?xml version='1.0' encoding='UTF-8' standalone='yes'?>

    <assembly xmlns='urnTongue Tiedchemas-microsoft-com:asm.v1' manifestVersion='1.0'>

      <dependency>

        <dependentAssembly>

          <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />

        </dependentAssembly>

      </dependency>

      <dependency>

        <dependentAssembly>

          <assemblyIdentity type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*' />

        </dependentAssembly>

      </dependency>

    </assembly>

     

     

     

    The following generated imbedded 64-bit manifest does not work

     

    <?xml version='1.0' encoding='UTF-8' standalone='yes'?>

    <assembly xmlns='urnTongue Tiedchemas-microsoft-com:asm.v1' manifestVersion='1.0'>

      <dependency>

        <dependentAssembly>

          <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='amd64' publicKeyToken='1fc8b3b9a1e18e3b' />

        </dependentAssembly>

      </dependency>

      <dependency>

        <dependentAssembly>

          <assemblyIdentity type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*' />

        </dependentAssembly>

      </dependency>

    </assembly>

     

     

     

    Does anybody know what is wrong with 64-bit version?

     

     

    For any Microsoft developers who is reading this - could you please explain how is this manifest idea of yours is better than "DLL hell" you "liberated" us from ?

    Tuesday, January 15, 2008 2:54 AM
  • So I understand this whole manifest thing can arise with a .Net 2.0 assembly. However our program is compiled in VS2003 with .net 1 and only loads 2 other dlls which are also compiled in VS2003.  Randomly through the program on only some computers do I get a the R6034 error.  This is especially difficult to debug as my computer seems perfectly happy with it the way it is.  So a few questions.

     

    1. Why would this error only show up on some machines not all?

    2. Why does the Runtime even check for a manifest on a .net 1 assembly which should not have one embedded?

    3. And why can i just click through it and the program continue to execute?

     

     

    We have a very simple .config file  to expllicitly require the 1.1.4322 runtime for each assembly, but nothing else.

     

    <?xml version="1.0"?>

    <configuration>

    <startup>

    <supportedRuntime version="v1.1.4322"/>

    </startup>

    </configuration>

     

    I appreciate the help,

     

    Joe G

     

    Friday, February 08, 2008 10:28 PM
  • Please MSFT! what is wrong with you! You are making a rocket science out of nothing!

    Can you guys think a little bit!

    Can any MSFT developer explain in plain text clarify this s**t?
    Monday, February 23, 2009 2:32 PM
  • SergeyK's comment - I share my experience with solving that magic-R6034 problem...

    Microsoft's recommendation is very confusing. That is, it recommends to include a manifest file and to re-compile the project.

    I recently had a problem with 'R6034' error message even with a manifest file already included!

    In my case, Visual Studio 2005 compiles and builds a DEBUG-configuration of some DLL. But, as soon as I try to start an application that uses that DLL the loader can't load the DLL and displays an error message with error code 'R6034'.

    It happened because two Run-Time DLLs were referenced in my DLL by some reason! As soon as I looked inside of my DLL I found two strings: 'msvcr80d.dll' and 'msvcr80.dll', and the 2nd one is the reason of that run-time problem.

    In order to resolve the problem I added 'msvcrt.lib' to the list of ignored libraries for DEBUG-configuration:

    [Configuration Properties] -> [Linker] -> [Input] -> 'Ignore Specific Library' - msvcrt.lib

    Who cares?..
    Thursday, July 09, 2009 5:43 PM
  • In my application the control returns from case 4 i.e

    /* check condition (4) */
        {
            ACTCTX_SECTION_KEYED_DATA askd = { sizeof(askd) };
            if (!(*pfnFindActCtxSectionStringW)(0, NULL, ACTIVATION_CONTEXT_SECTION_DLL_REDIRECTION, _CRT_DLL_FILENAME, &askd))
            {
                            /* no activation context used to load CRT DLL, means no manifest present in the process */
                            return FALSE;
                    }
        }

    pfnFindActCtxSectionStringW function returns false. what may be the reason? how to solve it?
    Monday, November 02, 2009 1:46 AM
  • Hello everyone,
    I'm working actually on an interface Java/Prolog, to call some Prologs methods from Java.
    I use a library containing some dll files. When I execute my Java code I have the following error:
    R6034: An application has made an attempt to load the C runtime library incorrectly.
    I don't know what I must do to get rid of this problem.
    It's very urgent for my final student project.
    Do you have any suggestions?
    Cheers,
    Diana

    • Proposed as answer by DianaALLAM Monday, April 26, 2010 1:50 PM
    Monday, April 26, 2010 1:43 PM