Debug problem: The source file is different from when the module was built


  • I debug the code StereoMatch (can be downloaded from When I step into a function that is defined in another .cpp source file, VC++ 2005 Express (abbr. as VC below) always report



    Source file: D:\Projects\StereoMatch\stereomatcher.cpp

    Module: D:\Projects\StereoMatch\Debug\StereoMatch.exe

    Process: [4024] StereoMatch.exe


    The source file is different from when the module was built. Would you like the debugger to use it anyway?



    I also notice that some break points turned into empty red circles intead of filled red circles. Moving the mouse onto the empty circles triggers a balloon tip window that says:



    At StereoMatcher.cpp, line 166 ('ComputeCorrespondence()', line 128)


    The breakpoint will not currently be hit. The source code is different from the original version.


    To allow the breakpoint to be hit when the source code is different, right-click on the breakpoint, choose 'Location ...', and turn on 'Allow the source code to be different from the original version.


    To allow this for all breakpoints, disable the option 'Require source files to exactly match the original version' under Tools, Options, Debugging, General'



    In all, what does it mean "The source file is different from when the module was built."? Could someone please offer an explanation? Thanks.



    Saturday, July 28, 2007 3:23 AM

All replies

  • What's wrong with the description? AFAICT, it says it all.


    When the compiler generates debug information, it will generate a hash (AFAICT, only MD5 is supported at this point) over all contributing source files (i.e. the .cpp file and all #include'd files). This information along with the full path of the files on the build machine eventually end up in the PDB file.


    Now when the debugger tries to obtain a source file, it gets the full path name from the PDB file does some path-based mapping and opens the file. Then it generates the hash and check if it matches the one saved in the PDB.


    In your case, it does not and that suggests your source file is outdated. You can force the debugger to ignore such mismatches, but it is obviously a feature designed to prevent you from looking at outdated source files while debugging.


    Are you quite certain sources and debug information are from the same version (obviously you could just rebuild on your box to make sure)?



    Sunday, July 29, 2007 1:54 PM
  • After I rebuild the solution (Ctrl+Alt+F7), the debugger warning still exists.

    Monday, July 30, 2007 12:35 AM
  • If there are any static libraries that you link to, these might be causing the problems. Do you see the problem for all files? Are these files included from precompiled source files (e.g. in static libs)?


    There's the dia2dump sample, that might help you understand the problem. You need to build it first. Once you have, you can dump the hash for some of the conflicting files and compare against the real MD5 hash of the source files.



    Monday, July 30, 2007 1:06 AM
  • There's no static library that is linked into the exe file as you can see from the weblink in my first post.

    Monday, July 30, 2007 1:22 AM

    Is your StereoMatch is a filter or other dll?

    I think you need to register this dll.

    Tuesday, September 04, 2007 3:07 AM

  • May it works if you...

    Delete all the files in the folders:

    ..\bin\Debug , ..\bin\Release, ..\obj\Debug , ..\obj\Release, ...obj\Debug\Refactor

    For your primary program and the aditional projects in the solution and recompile.


    Tuesday, November 06, 2007 9:41 PM
  • I thought I would add another scenario to this thread. I encountered this issue when I was trying to write code to handle an exception that would be thrown if the system time was wrong. To test my code, I had to change the system date/time. This makes Visual Studio believe that the source file is in fact "different from when the module was built".
    Thursday, February 26, 2009 6:33 PM
  • In win7 with the system locale in Chinese, it can be reproduced in VS 2005 and VS 2008 by adding a non-ASCII(eg: 0xa9) character into comment or license header of a source file.

    It seems that cl.exe and vs debugger haven't processed non-ASCII characters in the same way, so they got different MD5 checksums.



    • Proposed as answer by mljack Wednesday, October 27, 2010 6:09 PM
    Wednesday, September 22, 2010 7:14 PM
  • I want to kiss you right now! Thanks for the answer, it worked for us!
    Thursday, December 02, 2010 4:23 PM
  • vonpato's answer worked for us.  Also, if using Visual Studio and you made a copy of a project and performed "add an existing project", verify that your solution file is pointing to the correct location for the new project.  Opening the solution file in Notepad showed us that the old project location was being referenced - a "Clean Build" cleaned out the old project not the new project.  In our case, deleting the directories indicated above before performing the "Add" seemed to do the trick - then "Clean Build" worked moving forward.

    Thursday, April 07, 2011 8:31 PM
  • Solution: Build->Configuration Manager Check whether all project allows to build when the Configuration is Debug.
    Help me help you
    Tuesday, July 12, 2011 9:51 AM