I'm getting this strange behavior when I launch a program without selecting "Step Into new instance". It launches the program as if I had, requiring me to manually hit F5.
If I explicitly select to step into the new instance, I have to hit F5 twice before it proceeds. I've tried restarting, and messing around with the exception options. It's not an exception. And no, there isn't a breakpoint defined on the first line.
Has anyone seen this before?
I'm going to take some guesses here:
Try closing the solution then moving or renaming the *.suo file for this solution (the *.suo file keeps some information like breakpoint settings and certain UI states - it probably shouldn't be in version control if it is). Reopen the solution and see if it behaves any better.
If not, try the same process, but rename/move any *.vcxproj.user files (which have per-user project settings, and also probably shouldn't be in version control). If you're using some other project type than C++, there will be slightly different names - but I think they all end in *.user. There might also be *.vcxproj.<user name>.user files that you'd want to handle similarly.
If one of these turn out to solve the problem, you might want to look at the file to see if there's something that would tell you what the problem was (.vcxproj is quite readable XML, the *.suo file is some undocumented binary format, so you probably wouldn't be able to identify anything in there).
Related
In a team project I'm working on, setting a breakpoint in a file (say IdeasController.cs) will lead to erratic debugger behaviour if there's another file with the same name in the solution. I've reproduced the problem on several developers' workstations.
Example
I set a breakpoint in IdeasController.cs in our Web API:
Another file called IdeasController.cs exists in our separate MVC 4 web project. In the screenshot below, the debugger shows the Api->IdeasController source code, but the line highlight matches the code structure of Web->IdeasController. The breakpoint is duplicated, with one of them in the middle of a comment block.
The Breakpoint window shows the breakpoint in both files simultaneously:
On some workstations the debugger steps through the correct lines (regardless of the line highlight); on others it cheerfully steps through irrelevant lines (including comments and whitespace). I'm guessing this depends on which source file it chooses to display.
What I've tried
I've trawled the Internet. This kind of problem seems to occur when there's a mismatch between the debug file (*.pdb), the source file, and the compiled code. There are a lot of possible causes: duplicate file names (which can confuse the debugger[5]), outdated project build files, invalid solution cache, or incorrect build configuration.
These are the solutions I've found and tried:
Checked my build configuration.
Made sure the project isn't built in release mode.
Made sure we don't have code optimization enabled.
Made sure the project's debug module was loaded correctly. (Started debugging the project and checked Debug > Windows > Modules. Both assemblies are listed, not optimized, and have a symbol status of "Symbols loaded".)
Reset the debugging metadata & Visual Studio cache.
Closed Visual Studio and deleted the solution cache file (*.suo).[1]
Deleted each project's build output (the bin and obj folders). (For future reference: open the solution folder in Windows Explorer and type this in the search box: "type:folder AND (name:=bin OR name:=obj)".
Deleted the assembly cache folder (C:\Documents and Settings\<user>\Local Settings\Application Data\dl3).[2][3]
None of these had any effect. I can rename one of the files (without renaming the class) to temporarily work around the problem, but that's far from ideal.
Where I am now
Page 14 of my latest Google search. Suggestions would be much appreciated. :)
If no better alternatives exist, you could put the breakpoint in code:
System.Diagnostics.Debugger.Break();
Just don't forget to remove it afterwards...
I'm so glad I found this post, thought I was the only one and was going insane! I'm having the same problem in VS2012 with VB.Net and have tried everything the OP mentioned.
Unique naming of the files seems to be the only 100% fix that I've found. Disabling all breakpoints until the application has loaded and then re-enabling the breakpoints you need works most of the time. Breakpoints in Lambda functions can still give you issues.
I just had the exact same problem. What solved it for me was deleting the .suo files belonging to the solution that contained the affected project/source file.
I also deleted my local symbolcache but I don't think that had anything to do with it.
(My solution contains multiple projects, one file (DataAdapter.cs) in one project was affected by this (VisualStudio put my breakpoints in the pdb belonging to System.Data.DataAdapter). I opened the .csproj file directly and was able to correctly set the breakpoint.)
I had the same problem today. I was able to trace it back to the fact that I had forgotten to set the platform target to x86 while debugging. Unfortunately the others (x64 / Any CPU) can be problematic while debugging. At least VS 2008 doesn't like them. I guess this is yet another reason to stay away.
Some speculation... I think the debugger (while running a 64 bit app) somehow "steals" breakpoints away from a file in certain cases. For me it was because another assembly was loaded first which had the same file name. I was able to avoid the issue, even in 64 bit mode, if I first manually loaded the assembly with my breakpoints: Assembly.Load("MyAssemblyWithBreakpoints");
Hope this (my first stackoverflow contribution) helps.
Although renaming one of the files will work, I found that the simplest solution is to temporarily disable automatic loading of symbols for the "other" assembly.
Start the debugger and continue until you hit the erroneous breakpoint.
Find where the debugger actually set the breakpoint using the Call Stack window:
Right-click on the row with the yellow arrow and enable Show Module Names. (The row should also have the red breakpoint symbol on it.)
The assembly name is now visible on that row.
Find that assembly in the Modules window (Debug > Windows > Modules).
Right-click on the assembly and disable Always Load Automatically.
Stop the debugger.
Start debugging again.
By doing this, you're preventing the Visual Studio debugger from mapping the breakpoint to the wrong assembly. It will then load the symbols from the other [presumably] correct assembly first, therefore mapping the breakpoint to the correct assembly.
Why does this happen?
This seems to occur when two different symbol files (PDB files) — for two different assemblies — both reference a source file with the same name. Although the source files are completely different, the Visual Studio debuggger seems to get confused.
For example, imagine there are two different files both with the name IdeasController.cs. The first one compiles into assembly Api.dll, and the second one compiles into assembly Web.dll.
When the debugger loads symbols, it will either load Api.pdb or Web.pdb first. Let's say it loads Api.pdb first. Then even if you set a breakpoint in Web\IdeasController.cs, it will find a match for IdeasController.cs in Api.pdb. It then maps code from Web\IdeasController.cs to Api.dll. This won't map correctly, of course, and so you see all sorts of odd issues while debugging.
I just had this issue on Visual Studio 2017 (Version 15.9.7), were break points were skipped and the debugger just "jumped" over return statements etc.
After a while I noticed, that I've recently added a .runsettings file to the project - and it turned out, that in my case configuring the CodeCoverage data collector is causing this problem.
As soon as I removed this section:
<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"> ... </DataCollector>
from the .runsettings file, it worked like a charm again.
I just backed up and deleted the file and then added back to the project, that solved the problem. I just whish i did it before going through the beforementioned list :)
You may also try to Clean and Rebuild (not Build) all projects.
I was hitting this issue in Visual Studio 2015.
I had a sub-folder with a DLL I wanted to save as Version1. It seems even after removing the reference to that DLL, and then adding a reference to another project studio pulled in the existing reference and went to the wrong source file. I removed that DLL in the sub-folder then Studio got the correct source.
I found a helpful link on [MSDN that shows how to clear prior associated source files in studio at this link][1].
Summary:
In the Solution Explorer, right click on the solution name (ex: Solution ‘TestApplication’) and select Properties This will bring up the Solution Property Pages dialog
Under Common Properties, select Debug Source Files
In the Search these paths for source code files (Visual Studio .NET 2003) / Directories containing source code (Visual Studio 2005) box, add, remove and/or reorder the directories as desired
Click the OK button
I was having the same issue. In my case both the projects had same port numbers. I was able to resolve it by changing the port number of the project whose file's breakpoints were not hitting.
My guess is that IIS Express was caching the pdb file from the second project since both files had the same name, and the projects had the same port number.
What worked for me (VS2017) was disabling this option in Tools --> Options... --> Debugging --> General: "Require sources files to exactly match the original version", which is enabled by default but I had it turned on.
That was not enough though, I also had to manually remove obj and bin folders for all projects in solution.
Delete all the .pdb files of the project where the break point is hitting wrongly. This will solve the issue.
It happened to me (in VS 2008) to have two child breakpoint with the same memory address and the same associated file.
Those breakpoints were spawned at a certain time during the running of the process.
I noticed that I had duplicated .dll files in my project folders, and resolved removing the duplicated .dll, while keeping only one .dll per name in the debugging folder structure. (As example in my case I had /bin/Example.dll and /bin/Plug-in/Example.dll both present under my debug folder structure).
I had a very similar problem. In my case the problem was a different target .net framework in one of the projects causing VS2017 to wrongly load a source file (with the same name) of another project, not the one being activated with
ObjectHandle handle = Activator.CreateInstance
Changing the project's target framework to be the same in all projects fixed it.
I had a similar issue with the breakpoint being set in another file with the same filename in a different project.
It was caused by the fact that the debugging was started for that other project, while it was not started for the project where I tried to set the breakpoint. The breakpoint creation worked correctly after doing the Debug > Start New Instance for the intended project.
During step-by-step debugging, I often use "step into" to halt at every line in the section that I am debugging, to see all my code that's executed.
But library calls can disrupt this work flow: The debugger will jump into some STL file and continue there. I then have to press "jump out" to go back to my own code.
Is there a way to prevent the debugger from opening STL source files? A blacklist or a setting somewhere? I work with native C++ code. The "only my code" debugger setting unfortunately only works for managed code.
good question, the debugger constantly jumping into everything is indeed a huge slowdown and distraction during debugging. Luckily there's a solution:
open your registry editor, navigate to
HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\NativeDE\StepOver
(add \Wow6432Node after SOFTWARE if you're on a 64bit machine, this casued me headaches in the past).
Add a new String Value (REG_SZ). The name is not so important, I used NoSTL for clarity and set it's value to
std\:\:.*=NoStepInto
This tells the debugger to not step into anything matching that regex so it will skip every function (global and class level) in the std namespace.
By using StepInto you can add overrides for specific methods, and you can still use breakpoints off course. It's also handy to add some of your own methods that get stepped into often but of which you know the result by head.
Here is a more detailed explanation, google on NoStepInto for more scattered information.
The answer is as above mentioned, but in case you use VisualStudio 2017 or it didn't work for you, then try the following:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Packages\Debugger\Visualizers
Open the following file with notepad or whatever you have:
default.natjmc
and add this line:
<Function><Name>std\:\:.*</Name><Action>NoStepInto</Action></Function>
The 'name' means the value of the registry key in that file and 'action' is self-explanatory.
If you want to add the registry key too, (not sure if it is necessary), then you will find it here:
\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VSTA\8.0\NativeDE\StepOver
At least, that was the path in my case. It took a good hour to find these, so I hope that it will help somebody.
Remove the 'Wow6432Node' if you have 32bit machine, as above mentioned.
You don't use F10/F11/Shift+F11??? Those are "step over", "step into", "step out", and there are many more that are useful. Much more usable than hunting for buttons, and you never have to take your eyes off the source code.
In general you're well served by using keyboard shortcuts in Visual Studio instead of the mouse. Not just for debugging, but everything. Learn 'em, you'll love 'em! You probably can't learn them all at once, just pick a few functions you use often, get used to them, then start on a different set. It becomes second nature over time.
Sorry that this is off-topic, but your original question was beautifully answered by the previous poster already, and I thought I'd help with something else :)
I'm working on a large, inherited C++ (really, mostly C) project developed and maintained under Visual Studio 2008. Technically, in Visual Studio terms, it is a "solution" consisting of eight "projects", and therein appears to be the rub.
As I'm sure most of you know, Visual Studio grays out the code that it believes to be #ifdef'd out. What I'm finding, though, is that it doesn't seem to do this correctly for the different projects. To keep matters simple, let's just call them Proj1, Proj2, ... Proj8. When I'm working on the Win32 Debug configuration of Proj5, I'd expect that the macros defined in the C/C++ Preprocessor properties configuration of Proj5 would determine what is grayed (or at least that there would be some straightforward way to make it so). Instead, I seem to be seeing views based on properties of Proj1. That is, if Proj1 defines some preprocessor macros that eliminate part of the code, I'm seeing that part grayed even when I'm working on Proj5. And the macros for Proj5 have no effect at all on what I see.
Yes, I did a complete clean and build (several, actually, and even saved everything off to SVN and started in a new top-level folder), and so I'm pretty sure this is not because of some vestigial files produced by an old build. And I'm pretty sure that in other respects Visual Sourcesafe "understands" the context correctly, because (1) the Build menu contains options related to Proj5, not Proj1; (b) at the bottom of the Project menu is "Proj5 properties..." not "Proj1 properties..."; and (c) there is no question that the #ifdef's are working in the program that is built: there are major feature differences, and they are as I'd expect them to be.
ADDED 27 Sept 2010 I still don't have an answer, so let me try this a different way: Assuming I've already run successful builds (which I have) is there anything other than the preprocessor properties and configuration of the currently selected project (and, as noted below, those of individual files, but that is moot in this case) that should influence what code is grayed?
Please see if these preprocessor directives might be set for the individual files. You can do this by right-clicking on a source file and selecting "Properties" from the context menu. It's somewhat counterintuitive to think that the directives can be set for individual files, not just for projects.
If that doesn't help, your best bet might be to use a text editor to look for the problem preprocessor definitions in each of the project files to try to get a better idea of what might be happening.
VS2010 is supposed to help with this. In VS2008, the no-compile browse cache is done after preprocessing, so it can accommodate only one set of macro definitions.
I don't believe that "Build Clean" or "Rebuild" will delete the .ncb files, since they are not part of the build process at all. I do know that deleting these files by hand fixes all kinds of weird behavior, but I'm afraid that in your case it's not going to be a lasting solution (the .ncb files will still get filled in based on a single configuration.)
Make the project the Startup Project and Remove and Re-add the offending Preprocessor Definition
Details:
I found a process that that fixes my MFC projects when this happens (at least temporarily). First I set the project I am working on as the startup project. Do that by right-clicking the project in the solution explorer and selecting Set as Startup Project. Then I go into the preprocessor definitions for the project and deleting the one that is not triggering and clicking OK. You will see a little progress bar a few seconds later appear in the lower right. Once it finishes, go back into preprocessor definitions for the project and add it back in again and click OK. After the little progress bar finishes again, you should see the correct code active again.
When I right-click my solution in the Solution Explorer and choose Properties I get a dialog where I can select the Startup Project.
I sometimes select Current selection (If it is an experimental solution with lots of projects I jump between), but most often it is a Single startup project selected, which would usually be the main WinForms applications or or Console application.
My problem is that whenever I do a treeclean with the tfpt command (Team Foundation Power Tools 2008) this setting is forgotten. So when I try to run my solution the next time, it has defaulted to some random project and I get an error stating that I cannot run a class library or something like that. Which is obvious of course. But where is this setting stored? Why is it forgotten when I do the treeclean? The solution file is still there, right? Isn't solution properties stored there?
Reference 1
Arian Kulp says:
I was struggling with trying to figure
out why a certain solution of mine
wasn’t starting right. It was in VB
with four projects. Upon initial open
it would set a certain project with a
DLL output as startup. If I set the
EXE as startup project, it was fine,
but when I distribute code I always
clean it by removing *.suo and *.user
files, and bin/obj folders. Upon
opening the “cleaned” version, it
would always revert to the DLL project
and fail to F5 nicely. The fix turned
out to be simple, though I’m curious
as to why I needed to do this at all.
In the solution file, there are a list
of pseudo-XML “Project” entries. It
turns out that whatever is the first
one ends up as the Startup Project,
unless it’s overridden in the suo
file. Argh. I just rearranged the
order in the file and it’s good.
I’m guessing that C# is the same way
but I didn’t test it. I hope that
this helps someone!
Reference 2
Setting the StartUp Project
Which project is the "startup" project only has any relevance for debugging, which means it's user metadata from the point of the solution and the projects. Regardless of which project is the "startup" project, the compiled code is the same.
Because of this, the information is stored as a user setting in the Solution User Options file (solution.suo) which accompanies the Solution file (solution.sln). The .suo file "Records all of the options that you might associate with your solution so that each time you open it, it includes customizations that you have made" according to MSDN.
The .suo file is a binary file. If you want to read or change it programatically, you have to use IVsPersistSolutionOpts.LoadUserOptions from the Microsoft.VisualStudio.Shell.Interop namespace.
I suspect that this setting is saved as part of the .suo file created whenever you edit a solution file. This file contains various user settings, such as breakpoints, watch data etc.
I cannot confirm this but that would be my guess.
Unfortunately its not XML its a binary file and not easily edited.
I just wrote a little command line utility for windows called slnStartupProject to solve this. It sets the Startup Project automatically like this:
slnStartupProject slnFilename projectName
I personally use it to set the project after generating the solution with cmake that always sets a dummy ALL_BUILD project as the first project in the solution.
The source is on github:
https://github.com/michaKFromParis/slnStartupProject
Forks and feedbacks are welcome.
Hope this helps!
This may sound like a newbie question - and it is. I'm relatively new to vs, we started using it a few months ago, and I still haven't "mentally" made the change from the command line. So, if you could help me with 2 things:
I create a new project (not a solution). He puts the files in some directory. After putting my code inside it, I click on the little green triangle (Debug, it says), and he compiles it, builds it and runs it. It works ok. Now, sometimes, I have to change only a tiny bit of code and I don't feel like getting the whole VS up just for that. How can I do that Debug thing from the command line, with the assumption I didn't change anything else.
Where do I tell him not to create a "Debug" subdirectory, not to create a HTML Build log, an object file ... and so on, generally, where can I find the settings which will help me to get as little files ... apart from my original source, and the .exe resultant one ?
I have to change only a tiny bit of code and I don't feel like getting the whole VS up just for that. How can I do that Debug thing from the command line, with the assumption I didn't change anything else.
I think what you want here is not debugging but a rebuild of your project.
Where do I tell him not to create a "Debug" subdirectory, not to create a HTML Build log, an object file ... and so on, generally, where can I find the settings which will help me to get as little files ... apart from my original source, and the .exe resultant one ?
The answer to both these questions is to use the command line! You can make VS emit a make file from the loaded project. Use NMAKE to build this make file after you have made your desired modifications. The ".obj" files are created as an intermediate step between compilation and linking phase this is how the C++ compilation model works. Why do insist on not generating them?
You can't really start debugging without starting up Visual Studio, since Visual Studio is the debugger. You can tell VS to rebuild a solution from the command line without firing up the UI if you want to just build it: See MSDN for details.
You can control the creation of the DEBUG and RELEASE directories via the 'intermediate files' option in the project settings. Though you need to create the obj file somewhere in order for the compile to work.