10

How can one determine which C or C++ compiler was used to build a particular Windows executable or DLL? Some compilers leave behind version strings in the final executable, but this seems to be rarer on Windows than on Linux.

Specifically, I'm interested in distinguishing between Visual C++ and the various MinGW compilers (usually fairly easy from the function signatures), and then between Visual C++ versions (6, 2002/2003, 2005, 2008; more difficult to do). Is there a tool out there that can make the distinction in a semi-reliable way?

kquinn
  • 10,433
  • 4
  • 35
  • 35
  • 1
    What is driving you to need this information? – ojblass Apr 18 '09 at 22:17
  • First, wondering what version of VS was used to build some of the binaries we have here. (I was thinking of rebuilding them with a newer version of VS for a nearly-free performance boost.) I found someone who knows the answer for these particular binaries, but I'm curious as to if it can be done in general. – kquinn Apr 18 '09 at 22:27
  • Isn't the answer in that case just to rebuild using the newest compiler in any case? Either you recompile using the same compiler, making no changes, or you end up using a newer compiler, giving you the advantages you mentioned. – jalf Apr 18 '09 at 22:56
  • Sure, you can do that. But 1. you're probably wasting some of your effort, and (more importantly) 2. that does nothing to assuage my curiosity :) – kquinn Apr 18 '09 at 23:38

3 Answers3

11

One source of a hint to distinguish among VC versions is the specific C runtime library linked. Since the default case is (at least in the modern versions) to link to the DLL, this is fairly easy to do. The utility Dependency Walker is almost indispensible for verifying that you know what DLLs are really being loaded, and it will tell you which C runtime DLL is in use. Although Dependency Walker is included in the Microsoft Platform SDK, it has been extended independently and the site I linked is the home of its current development.

VC6 and MinGW both link to MSVCRT.DLL by default, so this won't distinguish between them. With some effort, MinGW can be made to link to the later C runtime versions as well, so you will need to independently rule out MinGW.

Runtime       VC Version
----------    -------------
MSVCRT.DLL    VC6
MSCVR80.DLL   VC8 (VS 2005)
MSCVR90.DLL   VC9 (VS 2008)

Other runtime DLLs would be good clues too, e.g. references to Delphi's runtime probably indicate the EXE was actually built from Delphi, and not a C toolchain at all.

If symbols haven't been stripped from the .EXE file, then you might find some clues from which internal symbols are present. For instance, a reference to something like _sjlj_init probably indicates that a MinGW GCC 3.x configured for setjmp/longjmp exception handling was involved at some point.

RBerteig
  • 41,948
  • 7
  • 88
  • 128
  • Well, your list of versions *is* more complete... ;-) – RBerteig Apr 18 '09 at 23:09
  • Ah, MSVCRT.DLL with no number on it is VC6... that explains a few things. Thanks for the link to Dependency Walker, it looks very useful. I wish I could split the accepted answer points between the three of you, but I decided to give them to the guy with 1 rep. – kquinn Apr 18 '09 at 23:51
  • Dependencies is a modern replacement for Dependency Walker: https://github.com/lucasg/Dependencies – thomasa88 Jul 01 '21 at 05:15
2

Another option is to check what CRT library the dll links to using depends.exe
MinGW and Cygwin have their own dlls which are quite obvious to recognize.
VC6 uses MSVCRT.dll usually
any newer version of VS has its version next to the dll's file name:
MSVCR90.dll - VS2008
MSVCR80.dll - VS2005
MSVCR71.dll - VS2003
MSVCR70.dll - VS2002

Don't take this list as the definitive guide since these names tend to have strange variations, especially in the area of VS2002-2003. There are also other dlls like the MFC and ATL dlls that have similar versioning scheme.

This will work as long as the PE actually depends on the CRT and it didn't link to it statically.

I think Delphi also has some DLL it links to but I'm not really sure what it is.

shoosh
  • 76,898
  • 55
  • 205
  • 325
1

part of the analysis that IDA-Pro performs contains some compiler recognition. After you open the PE for analysis, look at the output log. it's usually buried somewhere there.

shoosh
  • 76,898
  • 55
  • 205
  • 325
  • Yeah, IDA Pro 5.1 is what I'm using now. Its analysis is very fuzzy, though; for something I know was compiled with VC6, it says "Using FLIRT signature: Microsoft VisualC 2-8/net runtime". – kquinn Apr 18 '09 at 22:28