This is a very particular scenario. It happened to me and cost me over 3 hours to fix it.
I am currently working on a fully managed WPF application, that references a certified C# DLL that was purposely compiled targeting x86 platform (part of the certification process I think). Since I recently got an upgrade on my development machine, and I wanted to take full advantage of my 8GB of RAM I ended up installing Windows 7 x64.
Because of the particular x86 certified DLL, I had to force my application to run in a 32bit process, thus, I changed my application build target to x86. This was about one week ago.
Since I am in the middle of a code cleanup and refactoring work item, I did not had the need to debug my source up until three days after I changed that setting, thus moving if to a back drawer on my brain.
Now I get to a point where I actually need a breakpoint, set it on my code, and run my application. The breakpoint does not get it! I then move the breakpoint to the first line of code on my App.xaml.cs constructor. It does not get hit either. Then I rebuild my project, cleanup my bin and obj folders (something could be inconsistent with those files).
Got it working
After spending a couple of hours on this, even getting older change sets to see if the issue was a problem with the source code, I re-opened that back drawer and remembered to try to set the target CPU back to any (it would only crash when the actual certified DLL was loaded).
The breakpoint finally got hit!
Obviously this did not make any sense. Since I had elaborated on the issue I was now able to successfully search for what I needed: “vs2008 breakpoint x64 target x86” and this came out as a result:
What happens is that when you install Visual Studio 2008 on Windows 7, the OS will set the compatibility mode to “Windows XP SP3”. All you have to do is to change this setting to “Windows Vista SP2” and your problem will be fixed. :S