locked
CVTRES : fatal error CVT1100: duplicate resource. type:ICON, name:1, language:0x0409 LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt RRS feed

  • Question

  • I posted on this problem last year and never received a satifactory answer.  To recap.

    I migrated a special purpose application from Windows NT 3.51, written in VC++ 4.2 to Windows XP and VC++ 2005.  After dealing with a large number of standard functions that had been deprecated, the code compiled but I got the indicated error above.  I was never able to get around this link error.

    Eventually, I obtained VC++ 4.2 from Microsoft, installed it on the XP development machine, and made my modifications to it.  I got this application to run with the new hardware.  This solution, however, is unsatisfactory because we don't won't to rely on an old compiler no longer supported by Microsoft.  I decided to return to the VC++  2005 compiler and try again after incorporating all of the changes I made in the VC++ 4.2 version.  Once again, I got the same link error.

    My attempts to fix this problem have included the following: (1) renumbering all of the identifiers in the resource.h file to eliminate any duplicates; (2) going into properties and changing the TypeLib resource ID from 1.  Other approaches I've played with have been to rename ICON (the compiler didn't like that) and renumbering the two identifiers associated with ICON (no effect), among others.

    I'm wondering if the "language 0x0409" is some kind of a clue.  In the StdAfx.h file, I've indicated that the version is 0x0501 - Windows XP - explicitly.  That didn't help - I got the same message - but it suggests that there may be something I need to define somewhere - possibly in StdAfx.h.  Other than the change I indicated, I've left that header untouched.  Prior to my adding a definition of WINVER, the only stuff in the StdAfx.h file were related to MFC database related functions.

    I may be off on the wrong track here but I've literally attempted everything I can think of in the realm of the resource.h file and resources in general.  The error message is singularly unhelpful but I suspect that if someone else has encountered a similar problem there is probably a simple but non-obvious solution.

    Thanks in advance.

    Friday, January 23, 2009 3:25 PM

Answers

  • Did you happen to see this here

    Visual C++ Concepts: Building a C/C++ Program
    CVTRES Fatal Error CVT1100

    Error Message

    duplicate resource — type:type, name:name, language:language, flags:flags, size:size

    The given resource was specified more than once.

    You can get this error if the linker is creating a type library and you did not specify /TLBID and a resource in your project already uses 1. In this case, specify /TLBID and specify another number up to 65535.

     

    • Marked as answer by Wesley Yao Thursday, January 29, 2009 2:01 AM
    Monday, January 26, 2009 3:18 PM
  • Paul Hager said:

     
    Yes - one of the first things I checked last year.  I obtained a tool to renumber everything and eliminate duplicates.  No effect.  I also tried to change the value of /TLBID.  It wouldn't accept a change.


    Sorry for the insistence, but I was able to change the TypeLib Resource ID, in Linker > Embedded IDL properties without a problem.

    Also, take a look at this thread. It might give you some clues.

    • Marked as answer by Wesley Yao Thursday, January 29, 2009 2:00 AM
    Monday, January 26, 2009 6:02 PM
  • I noticed that you are including in your project's rc file, the file res\\MAKEMTC.rc2. Would you mind verifying if the definition

    XXX        ICON    "res\\MAKEMTC.ico"

    where XXX is defined as 128, ou 129, by any chance, still exists in that file.

     

     

    • Marked as answer by Wesley Yao Thursday, January 29, 2009 2:01 AM
    Monday, January 26, 2009 9:32 PM

All replies

  • You'll get this bogus error when you've got more than one .rc file in your project that contains icons.  #include the one in the other.
    Hans Passant.
    Friday, January 23, 2009 7:00 PM
  • Have you tried /INCREMENTAL:NO in Linker Properties ?
    Saturday, January 24, 2009 2:32 PM
  • Belloc said:

    Have you tried /INCREMENTAL:NO in Linker Properties ?



     That produced a new error: LNK4075 (warning).  The other error remained.  Though it didn't work, it suggested that maybe I should look at the other properties.  The problem is that anything I do is pure trial and error.

    First trial and error was to look at some resource properties.  I chose setting ignore the standard include path and got fatal error RC1015 - can't open afxres.h.  Haven't looked that up yet.

    I still wonder about the 0x0409 languange mentioned in the error message.  There is nothing anywhere that explicitly sets this - as I stated above, I set the version to 0x0501.  One thing I came across was the linker target machine, which is defaulted to X86.  What does this mean?  It sounds ancient - the actual machine is a dual core AMD purchased a year ago.  Might this be the source of the incompatibility?  Remember that when nearly identical code (except for the deprecated functions such as "sscanf()" becoming "sscanf_s()") is compiled using VC++ 4.2 on the same machine, it compiles and links.  If the target machine is defaulting incorrectly for some reason, what should it be?

    • Edited by nobugz Thursday, November 17, 2011 11:35 AM html messed up
    Monday, January 26, 2009 3:00 PM
  • nobugz said:

    You'll get this bogus error when you've got more than one .rc file in your project that contains icons.  #include the one in the other.


    Hans Passant.



    Unfortunately, I only have one ".rc" file.
    Monday, January 26, 2009 3:01 PM
  • Did you happen to see this here

    Visual C++ Concepts: Building a C/C++ Program
    CVTRES Fatal Error CVT1100

    Error Message

    duplicate resource — type:type, name:name, language:language, flags:flags, size:size

    The given resource was specified more than once.

    You can get this error if the linker is creating a type library and you did not specify /TLBID and a resource in your project already uses 1. In this case, specify /TLBID and specify another number up to 65535.

     

    • Marked as answer by Wesley Yao Thursday, January 29, 2009 2:01 AM
    Monday, January 26, 2009 3:18 PM
  • Belloc said:

    Did you happen to see this here

    Visual C++ Concepts: Building a C/C++ Program
    CVTRES Fatal Error CVT1100

    Error Message

    duplicate resource — type:type, name:name, language:language, flags:flags, size:size

    The given resource was specified more than once.

    You can get this error if the linker is creating a type library and you did not specify /TLBID and a resource in your project already uses 1. In this case, specify /TLBID and specify another number up to 65535.

     



    Yes - one of the first things I checked last year.  I obtained a tool to renumber everything and eliminate duplicates.  No effect.  I also tried to change the value of /TLBID.  It wouldn't accept a change.  Remember, there is no problem in VC++ 4.2.  The problem occurs in VC++ 2005.  I may be the only person around who has attempted to update an old 4.2 program to 2005.  I wish the people responsible for maintaining this software had migrated to newer versions of both the operating system and the Visual Studio tool but, regrettably, they didn't ... and I enherited this mess.  Quite frustrating.

    I figure this must be something simple: maybe changing some header file or some resource setting.  I still think that the 0x0409 must be some kind of clue.  Where does this come from?  And there's that "X86" target machine.

    One problem was that early on, when I ported the code to the new machine, operating system, and visual studio, I had the VS 2005 do a conversion.  I figure that it chose some default somewhere that is wrong.  But, which one??  There's the rub.

    Anyway, I'm trusting in you MS gurus and your vast MS experience on this.

    Monday, January 26, 2009 3:36 PM
  • Let me add the first part of the ".rc" file for perusal.  Maybe this will suggest something to knowledgeable folks.

    // Microsoft Visual C++ generated resource script.  
    //  
    #include "resource.h"  
     
    // Generated Help ID header file  
    #define APSTUDIO_HIDDEN_SYMBOLS  
    #include "resource.hm"  
    #undef APSTUDIO_HIDDEN_SYMBOLS  
     
    #define APSTUDIO_READONLY_SYMBOLS  
    /////////////////////////////////////////////////////////////////////////////  
    //  
    // Generated from the TEXTINCLUDE 2 resource.  
    //  
    #include "afxres.h"  
    #include "dlgs.h"  
     
    /////////////////////////////////////////////////////////////////////////////  
    #undef APSTUDIO_READONLY_SYMBOLS  
     
    /////////////////////////////////////////////////////////////////////////////  
    // English (U.S.) resources  
     
    #if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)  
    #ifdef _WIN32  
    LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US  
    #pragma code_page(1252)  
    #endif //_WIN32  
     
    #ifdef APSTUDIO_INVOKED  
    /////////////////////////////////////////////////////////////////////////////  
    //  
    // TEXTINCLUDE  
    //  
     
    1 TEXTINCLUDE   
    BEGIN  
        "resource.h\0"  
    END  
     
    2 TEXTINCLUDE   
    BEGIN  
        "#include ""afxres.h""\r\n"  
        "#include ""dlgs.h""\r\n"  
        "\0"  
    END  
     
    3 TEXTINCLUDE   
    BEGIN  
        "#define _AFX_NO_SPLITTER_RESOURCES\r\n"  
        "#define _AFX_NO_OLE_RESOURCES\r\n"  
        "#define _AFX_NO_TRACKER_RESOURCES\r\n"  
        "#define _AFX_NO_PROPERTY_RESOURCES\r\n"  
        "\r\n"  
        "#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)\r\n"  
        "#ifdef _WIN32\r\n"  
        "LANGUAGE 9, 1\r\n"  
        "#pragma code_page(1252)\r\n"  
        "#endif\r\n"  
        "#include ""res\\MAKEMTC.rc2""  // non-Microsoft Visual C++ edited resources\r\n"  
        "#include ""afxres.rc""         // Standard components\r\n"  
        "#include ""afxprint.rc""       // printing/print preview resources\r\n"  
        "#include ""afxdb.rc""          // Database resources\r\n"  
        "#endif\0"  
    END  
     
    #endif    // APSTUDIO_INVOKED  
     
     

    There is a lot more but I figure this is the significant part.  I made no changes in this file at all.

    Monday, January 26, 2009 3:43 PM
  •  Normally you would have in your resource.h and .rc files the following :

    #define ICON    1            (resource.h)

    and

    ICON    ICON    "icon.ico"        (.rc file)

    You mentioned on your first post that you renumbered the 2 identifiers associated with ICON. But there's just one identifier to be changed, the first one above, like :

    #define ICON  2

     

     

     

     

     

    Monday, January 26, 2009 4:40 PM
  • Belloc said:

     Normally you would have in your resource.h and .rc files the following :

    #define ICON    1            (resource.h)

    and

    ICON    ICON    "icon.ico"        (.rc file)

    You mentioned on your first post that you renumbered the 2 identifiers associated with ICON. But there's just one identifier to be changed, the first one above, like :

    #define ICON  2

     

     

     

     

     


     

    I'm fairly confident that is not the problem.  The code immediately following the posted source is:

     
    /////////////////////////////////////////////////////////////////////////////  
    //  
    // Icon  
    //  
     
    // Icon with lowest ID value placed first to ensure application icon  
    // remains consistent on all systems.  
    IDR_MAINFRAME           ICON                    "res\\MAKEMTC.ico"  
    IDR_MAKEMTTYPE          ICON                    "res\\MAKEMTCDoc.ico"  
     
     

     

    The values of these ID's are 128 and 129 respectively (in the resource.h file).  I have commented out all references to IDR_MAKEMTTYPE and the I get the same error.  And remember, this compiles and links in VC++ 4.2.  There is something about going from 4.2 to 2005 that is the problem.  I tried changing the name from ICON and that just generated a different error.  Maybe some way of invoking something in MFC changed over the intervening 10 years and that's the source of the problem.

    Any thoughts on the X86 default machine type?  How about the 0x0409 error on language?  Why is the linker making that assumption, since I explicitly set the system to 0x0501?  The linker error is obviously not properly explaining what is actually going on, which is why tracking down this problem has been so difficult.

    If I were writing this application from scratch, what would the default settings for the resources and linker be?  If the conversion process changed a key setting that might account for the problem.

    Monday, January 26, 2009 5:40 PM
  • Paul Hager said:

     
    Yes - one of the first things I checked last year.  I obtained a tool to renumber everything and eliminate duplicates.  No effect.  I also tried to change the value of /TLBID.  It wouldn't accept a change.


    Sorry for the insistence, but I was able to change the TypeLib Resource ID, in Linker > Embedded IDL properties without a problem.

    Also, take a look at this thread. It might give you some clues.

    • Marked as answer by Wesley Yao Thursday, January 29, 2009 2:00 AM
    Monday, January 26, 2009 6:02 PM
  • Belloc said:

    Paul Hager said:

     
    Yes - one of the first things I checked last year.  I obtained a tool to renumber everything and eliminate duplicates.  No effect.  I also tried to change the value of /TLBID.  It wouldn't accept a change.


    Sorry for the insistence, but I was able to change the TypeLib Resource ID, in Linker > Embedded IDL properties without a problem.



    Well, in my case, it doesn't matter what value I assign because I get the identical message.  I slightly misspoke - the /TLBID may show as "2", for example, but the error message still is "type:ICON, name:1" as though I never changed it.  (I just went back and checked this to make sure I was right about the behavior.  No matter what value is assigned, the error message says "1".)  So, assuming that the interface is correct, TLBID is changing even though the error message indicates that it is not.  Maybe there is an error with VS 2005 but I don't want to contemplate that.

    My sense is that the better bet is that the conversion wizard - or whatever it was - set something wrong.  Incidentlly, I just checked the generated "makemtc.rc" files for the 4.2 version and the 2005 version and they are slightly different.  All of the includes are the same.  However, there are some minor differences.  For example, VC++ 2005 above has:

    IDR_MAINFRAME     ICON     "res\\makemtc.ico"

    whereas, VC++ 4.2 has:

    IDR_MAINFRAME     ICON     DISCARDABLE     "res\\makemtc.ico"

    As I understand it, the ".rc" file is generated by visual C++ so I assume that "DISCARDABLE" was... discarded.  There are some other keyword differences between the two files but they don't pertain to ICON and there is no obvious connection with the value of the identifier.

    Monday, January 26, 2009 6:52 PM
  • I noticed that you are including in your project's rc file, the file res\\MAKEMTC.rc2. Would you mind verifying if the definition

    XXX        ICON    "res\\MAKEMTC.ico"

    where XXX is defined as 128, ou 129, by any chance, still exists in that file.

     

     

    • Marked as answer by Wesley Yao Thursday, January 29, 2009 2:01 AM
    Monday, January 26, 2009 9:32 PM
  • Belloc said:

    I noticed that you are including in your project's rc file, the file res\\MAKEMTC.rc2. Would you mind verifying if the definition

    XXX        ICON    "res\\MAKEMTC.ico"

    where XXX is defined as 128, ou 129, by any chance, still exists in that file.

     

     



    Nope.  I also tried commenting "res\\MAKEMTC.rc2" out - it seemed superfluous to me since it only contains an error statement - and it had no effect.  I got the same error.

    BTW, base was closed on account of a blizzard yesterday so I only got to this today.

    I return to my question about default settings.  Is it possible that the conversion wizard that takes the VC++ 4.2 workspace and converts it to a VC++ 2005 solution resets some parameters in such a way as to cause this error?  There are a number of differences organizationally between 4.2 and 2005.  For example, code and header files are all lumped together in a 4.2 workspace, although there is a "dependency" folder that includes some header files.  In 2005 the header files go into a separate header folder, though my recollection is that I had to move some of the header files by hand because the conversion wizard failed to do this completely.

    From my previous questions about this last year, my impression was that no one had ever tried to migrate from 4.2 to 2005 - I have boldly gone where no one has gone before.

    Thursday, January 29, 2009 3:52 PM
  • Paul Hager said:

    Belloc I return to my question about default settings.  Is it possible that the conversion wizard that takes the VC++ 4.2 workspace and converts it to a VC++ 2005 solution resets some parameters in such a way as to cause this error?  There are a number of differences organizationally between 4.2 and 2005.  For example, code and header files are all lumped together in a 4.2 workspace, although there is a "dependency" folder that includes some header files.  In 2005 the header files go into a separate header folder, though my recollection is that I had to move some of the header files by hand because the conversion wizard failed to do this completely.

    From my previous questions about this last year, my impression was that no one had ever tried to migrate from 4.2 to 2005 - I have boldly gone where no one has gone before.


    I can't tell you about this. Hope somebody give us some input about this conversion.
    Thursday, January 29, 2009 4:36 PM
  • Belloc said:

    Paul Hager said:

    Belloc I return to my question about default settings.  Is it possible that the conversion wizard that takes the VC++ 4.2 workspace and converts it to a VC++ 2005 solution resets some parameters in such a way as to cause this error?  There are a number of differences organizationally between 4.2 and 2005.  For example, code and header files are all lumped together in a 4.2 workspace, although there is a "dependency" folder that includes some header files.  In 2005 the header files go into a separate header folder, though my recollection is that I had to move some of the header files by hand because the conversion wizard failed to do this completely.

    From my previous questions about this last year, my impression was that no one had ever tried to migrate from 4.2 to 2005 - I have boldly gone where no one has gone before.


    I can't tell you about this. Hope somebody give us some input about this conversion.



    Any thoughts about a different forum or a different heading to describe the problem?  I think all of the obvious solutions have been tried - the error message just isn't helpful because it doesn't appear to be a duplicate resource problem at all.  Microsoft doesn't support 4.2 even though this is arguably a problem with 2005 - that's why I ended up on the forums in the first place.

    Suppose I titled this something along the lines of "conversion wizard produces linking problem going from 4.2 to 2005" or some such?  I don't know that really is the problem but it does seem like the way to bet.  Maybe if a different set of gurus look at the problem, I'll have better luck.

    Thursday, January 29, 2009 5:05 PM
  • Paul, I frequently recommend that you migrate an old project by building a basic VC++ 2005 project, and then copy/pasting the guts of the code from the old project to the new. This way you bypass the conversion wizard completely. And you don't need to be as nearly concerned about the compiler settings.

    In my experience I've found the conversion wizard very reliable with VC2005->VC2008 and VC2003->VC2008.

    VC6->VC2008 is more hit and miss. Obviously the wider the bridge, the greater the number of problems encountered.

    You started this thread almost a week ago. I'll bet if you took my approach you would have migrated this in just a few hours.

    Thursday, January 29, 2009 5:24 PM
  • Brian Muth said:

    Paul, I frequently recommend that you migrate an old project by building a basic VC++ 2005 project, and then copy/pasting the guts of the code from the old project to the new. This way you bypass the conversion wizard completely. And you don't need to be as nearly concerned about the compiler settings.

    In my experience I've found the conversion wizard very reliable with VC2005->VC2008 and VC2003->VC2008.

    VC6->VC2008 is more hit and miss. Obviously the wider the bridge, the greater the number of problems encountered.

    You started this thread almost a week ago. I'll bet if you took my approach you would have migrated this in just a few hours.



    I've written some Forms programs and some standard C++ programs.  However, I've never tried to write anything with the mix of MFC and other features found in this 4.2 program.  I like your suggestion but I'm not sure where to start.
    Thursday, January 29, 2009 5:34 PM
  • Nobugz,

    I know this is an old post but I'm now experiencing this problem. You mention a solution of #including the one in the other. Since I'm pretty new to using .rc files and icons, how do I exactly do that? I have a library containing a number of CDialogs which each need to contain an Icon. As soon as I added the second icon to the second dialog in the library, I started getting this error. So, are you saying there's a way to combine both icons to be referenced in one .rc file even though they get used by different Dialogs?

    Thanks,

    hestes37
    Saturday, August 22, 2009 1:14 AM
  • Don't put the dialogs in separate .rc files.

    Hans Passant.
    Saturday, August 22, 2009 1:35 AM
  • Nobugz,

    The project I'm inheriting has 5 different dialogs each with their own .rc file. I didn't design it, but that's what I have to work with. I have to put an icon on each of the dialogs, but if I put the icons in only one of those .rc files, how does one tell the other 4 dialogs where the icon listing are since they won't be in each of their .rc files?

    Thanks,

    hestes37
    Saturday, August 22, 2009 1:47 AM
  • Hi,,

    Thank you for this ans...it helps me a lot

    Friday, October 4, 2013 7:19 AM
  • Here we are, 2014, and I had this problem today with some old code I've been given to maintain. The original poster said he had only one .RC file, but in my case, the project used several .RC files but resulted in the same error.  Many answers described what the problem was, but didn't indicate what caused it or how to fix it. For those who are stumbling upon this thread via web search, and have this same problem except with multiple .RC files, here's how I fixed it.

    My application's main .RC file included the other .RC files.  I had created a new build configuration for a Chinese build.  By default, all .RC files in the new build configuration were assigned the property "Excluded From Build = No".  So when I built the application, it tried to compile all of the .RC files, each of which was already included in the app's .RC. 

    To fix, I made sure all my resource IDs were unique (which they were).  Then I selected each of the included .RC files in the Solution Explorer tree and went to Properties-General-Exclude From Build and set the property to "Yes".  Make sure the app's .RC "Exclude From Build" is still "No"... you still need to compile that file.  Rebuild the app and it's fixed.

    In my case, /INCREMENTAL:NO and including ICON resources in more than one resource file did not cause the problem or fix it.

    [VS2003]

    Friday, March 14, 2014 10:23 PM
  • I fixed this annoying and essentially nonsense problem by deleting the project's manifest file. Problem solved, went away, was non-existent. I love Microsoft's insistent need to make coding as complex as possible.
    Wednesday, April 30, 2014 5:34 PM
  • Oh, Microsoft: manifest files are a java JAR paradigm to instill some semblance of security in an inherently insecure VM. Might be ok in managed code, but in native code let us experts manage our risk.
    Wednesday, April 30, 2014 5:37 PM
  • >>>To fix, I made sure all my resource IDs were unique (which they were).  Then I selected each of the included .RC files in the Solution Explorer tree and went to Properties-General-Exclude From Build and set the property to "Yes".  Make sure the app's .RC "Exclude From Build" is still "No"... you still need to compile that file.  Rebuild the app and it's fixed.

    ----------------------------

    I got this error on VS2013 and took much time for it, now I've fixed it by your solution, thank you very much. 


    • Edited by Xu Laiming Thursday, August 27, 2015 7:50 AM
    Thursday, August 27, 2015 7:48 AM
  • Maybe in resource.h have the same ID, change to different number.

    ex:

    #define IDI_UNITERM 101

    ...

    #define IDI_MAIN        101


    Friday, July 14, 2017 10:29 AM
  • I met this issue as well, I simple close the manifest generate @Linker->Manifest file->Generate Manifest->No, after rebuild the project, I get the execution file.

    regards

    S.J.

    Wednesday, November 8, 2017 4:01 AM