2011
08.18

I’ve been working on a 3D VideoGame prototype these last months, using Visual C++ (Visual Studio 2010). With such work, some vacancies and some job affairs I havn’t had enough time for publishing something interesting in the blog… ;-)

Visual Studio 2010 worked fine at the beginning, but one day, suddenly, breakpoints stopped working. A yellow exclamation mark symbol was shown over them and placing the mouse cursor over such symbols showed the message “Breakpoint won’t be hit”.

Searching on the internet for this problem I found out it was a common one in almost every version of Visual Studio, specially in 2008 and 2010. Most common causes for this error are:

  • The project was compiled in Release mode, not in Debug one
  • Debug symbols are not found (or wrong path)
  • Incremental Debug linking option is not enabled
  • Not having installed the latest service packs and patches (some of them address this problem)
  • Corrupted installation: Reinstalling the application, restoring default configuration or even deleting Registry Keys and Local App configuration stored in the Windows User profile folders might fix this case

The fact was none of the above worked for me, but found out that if I started Visual Studio with a different user account everything worked like a charm. :?: After opening two projects (each generated with a different user) and compared differences on the .vproj XML files I found these extra lines added to the “faulty” one:

Removing these lines from the .vproj file and recompiling made the breakpoints to work again! The case was these lines referenced User configurations that didn’t appear in my VS configuration panels or couldn’t change (some of them were grayed). These XML lines contain a conditional inclusion and the path is $(UserRootDir)\MicrosoftCpp.$(Platform). It happened that path was C:\Users\Boriel\AppData\Local\Microsoft\MSBuild\v4.0, which was not the Visual Studio configuration Folder. Deleting it fixed the issue (it’s regenerated the next time Visual Studio IDE is started).

To avoid even more troubles I not only removed that folder, but also the local configuration stored in my profile (C:\Users\Boriel\AppData\Local\Microsoft\VisualStudio\10.0) and related registry keys (HKEY_CURRENT_USER\Software\Microsoft\VSCommon\10.0). Afterwards I restarted the IDE and a splashscreen warning told me the application was being prepared to be used for the first time. And the problem was gone. ;-)

Share

Comments are closed.