I've a solution which is ported from VS (Visual Studio) 2010 to VS2017 from one machine to another. I could debug while I can't. I need to know what's the problem. When running, I see the breakpoint marks get changed to include a warning, but I can't find what can be wrong. It seems that everything is ok.
1) Try to rebuild the application. Make sure that it's in the "Debug" mode.
2) If it works fine in VS2010 but failed in VS2017, I wonder if Visual Studio gets confused the configuration of the correct code type, if so you may need manually selected the .NET version. If you are using Framework 3.5 in VS2010, but on Visual Studio 2017 you are using such as Framework 4.6, by default automatically determines the code types to debug (v4.6, v4.5, v4.0). In this case you need to click in "Select..." button on "Attach to process" window and select Managed (v3.5, v3.0, v2.0).
3) Try to clear/delete all breakpoints from the Debug menu, choose Delete All Breakpoints. The reason is that it refreshes your Visual Studio setting file of your project.
4) Potential Workaround: Uncheck "Require source files to match original versions ..." in Options, Debugging.
In my case, changing from "Release" Mode to the "Debug" mode works!
When you launch the process, if the breakpoint icon turns hollow with the warning symbol, then the debugger cannot figure out what part of the program corresponds to that line of the source code. This is typically because the build is out-of-date with the executable, DLL, or PDB file.
A common way to get into the this situation is to not notice that the build failed and then let the debugger try to run the old executable which doesn't correspond to the current sources. It can also happen if Visual Studio gets confused about some of the dependencies and doesn't rebuild everything that needs to be rebuilt (which can happen after significant changes to the solution and/or project file(s), e.g., after an upgrade).
In these cases, clean out the build directory and force Visual Studio to rebuild everything. This will usually get you back in sync.
When you set a breakpoint in DLL code, that breakpoint will appear in the hollow warning state until the DLL is loaded. If your program uses delay-loading or if it manually loads the DLL (e.g., via a LoadLibrary call), you will commonly see this. Once the DLL is loaded, any breakpoint icons in the DLL should return to the normal red-ball state. If it doesn't yet you think the DLL should have been loaded. Check the Output window in the debugger to see if it really was loaded and whether there were any warnings or errors about loading the corresponding symbols from that DLL.
Related
I'm attempting to run a program built with a CMake-generated solution file under Visual Studio 2017's debugger in order to debug a problem. However, whenever I try selecting Start Debugging or Start Without Debugging I get the following error popup.
Unable to start program
'E:\build\someprogram\build\x64\Debug\ALL_BUILD
Access is denied.
At first glance the problem sounded like the one described here. However, that bug was allegedly fixed in VS 2017 15.5, and I currently use 15.6.7. And the location of the compiled executable isn't on a RAM disk or network drive, but on a physical drive. And the error happens when running without a debugger also.
Also I wondered about whether or not the executable was not properly configured, since it looks like the error is related to the ALL_BUILD target, but in my CMakeLists.txt I have this declaration:
add_executable(someproject ${SOURCE_FILES})
I would think that would add the executable to run. It also appears as a subproject in the Solution Explorer.
The compiled .exe runs outside of Visual Studio fine, although it crashes, which I'm trying to debug. Strangely, I cannot enter the Visual Studio debugger from the Abort/Retry/Ignore dialogue that appears after the crash by clicking Retry like it instructs; the window for choosing the Visual Studio version never appears.
It does not seem to be a permissions issue since I manually adjusted the permission of all the build directories with all permissions, with no changes. I'm also running Visual Studio with administrator privileges, and it makes no difference. Additionally I replicated the build process on an entirely different machine (Windows 10, as opposed to Windows 7) and the exact same error occurs, so I'm suspecting it's a CMake issue.
You need to set a different project as startup project (right click on your target executable project "someproject" and select "Set as StartUp Project" from the context menu). ALL_BUILD is a symbolic target and is not connected to an executable.
I am using Visual Studio 2013. I use a single start up project. There are more than 8 projects in the solution. Here is what I used to do when I was on Visual Studio 2010;
I would Build the solution. Then run it from its .exe file in /bin/Debug, then on Visual Studio, I would Attach to Process and it would start debugging and it would always hit the breakpoints as long as the source code and the .exe are not different.
This is the same thing that I do on Visual Studio 2013. I put the breakpoints in a file in my startup project. I build the solution (it says it successfully builded on the output window), or I Start Without Debugging, then attach to process, it says "The breakpoint will not currently be hit. The source code is different from the original version" Then I stop debugging, and without building again, I run the .exe again, attach it, then the breakpoints start hitting. Why do I have to close my .exe and then start it again? I use attach to process a lot and this 'must do twice to hit' is really annoying. I haven't change any configuration or anything. What am I doing wrong? I swear I don't change the source code. Not even a single space. It says "Build succeeded" when I attach it.
I have a similar issue. (on a webproject)
my temp solution:
right click the web project
Select Property Pages
Under Build --> Change the Target Framework to something else than the one selected (Apply the new framework)
Then Change back to your desired framework and Debug
I used to work with VS 2008 but I am missing the following feature in VS 2010 when debugging MFC C++ app:
whenever an assertion occurs, VS 2008 automatically opens the source file and focus the line with an assertion expression
in VS 2010 I have to mark the file name and line of assertion and then manually open the source file and scroll to the expression
Is there some option or registry setting how to enable such behaviour in VS2010 like it works in VS 2008 ?
The first setting that really matters in in the Project + Properties, General page, "Use of MFC". You'll have no trouble if you select the "Use MFC in a static library" setting. This causes the linker to generate the debugger .pdb file entries for MFC symbols, giving the debugger an easy time to find the MFC source code files on your machine.
This isn't always practical however, the "Use MFC in a shared library" setting is the normal one. Which will load the MFC dll from c:\windows\system32, put there when you installed VS. Getting a .pdb for this DLL requires enabling the Microsoft symbol server, Tools + Options, Debugging, Symbols. Press F1 to get config help for this setting page.
You can verify this worked out by using Debug + Windows + Modules while debugging and checking the Symbol File column for mfc100xx.dll. Right-clicking the module and Symbol Load Information provides additional info, showing which directories were searched to find the .pdb
A further complication is that the .pdb that the debugger will download was created on a build server in Redmond which had the source code files installed in f:\dd\vctools\vc7libs\ship\atlmfc. Obviously not the directory where you have them installed. The IDE will prompt you for the actual source code directory. This prompt is often highly confuzzling so clicking Cancel on the dialog is a common thing to do. You now however bought the farm, the IDE remembers that you cancelled this dialog and won't prompt you again. You reset that by deleting the hidden .suo file in the solution directory.
I have the following problem with design-time debugging in Visual Studio 2010 Pro.
In my solution I have got two libraries. One with name Alfa that contains some of my basic components. Two with name AlfaDesign that it contains designers for components from library Alfa. And of course I have a project for developing and testing Alfa components.
AlfaDesign is having reference to Alfa library. And the test project is having a reference to Alfa and AlfaDesign.
And my problem:
When I put breakpoint in component's constructor from the Alfa library and then I put this component on the form in my testing project, the debbuger is doesn't break. Visual Studio is still running.
I followed instruction from the tutorial Walkthrough: Debugging Custom Windows Forms Controls at Design Time, but without any success.
I ran into this problem today with one of my projects, and I spent the last several hours figuring it out. What I found is that the symbols and modules will not load when your project target framework is set to anything less than .NET 4 when doing an F5 debug. Switching the projects to .NET 4 does fix this weird behavior, but you may not want this for .NET 2 applications that you don't want to use the newer runtimes/BCL.
However, you can still correct this behavior. You can run manually use Debug -> Attach To Process and select devenv.exe and that will load the modules and symbols. So, you can either have a second instance of Visual Studio 2010 already open and simply attach, or you can run it on debug (Run External Program), Detach, and Re-attach to get the modules to load.
I thought this was something wrong with my environment settings, because my install of Visual Studio is very customized, so I thought there might have been some sort of setting, conflict, or file difference, but it seems to just be a weird behavior in the Visual Studio 2010 debugger. I would be curious to see if anyone from the Visual Studio 2010 team could investigate this a bit further.
If the breakpoints are properly resolved, then it must hit properly.
Please check the following.
Is the breakpoint resolved properly or not. If it's properly resolved, it will be displayed in red during debugging sessions. Otherwise the red will turn into a disabled state (with a yellow exclamation mark with a grayed circle).
Why don't you put a breakpoint where the object is being constructed and debug through it? So that you can ensure that your construction code is working well. You can step through (F11) to get inside the constructor.
I'm creating an IE extension in C# using visual studio 2010. How do I go about debugging the extension whilst running it in Internet Explorer?
A few things are very striking:
This question is being asked a lot
Most answers, if not all, are incomplete or incorrect
So here it goes: In VS2010. perform the following:
Create your BHO project, a good starting point is: Demo IE Toolbar/BHO
Create a similar solution/project, Go to "Solution Explorer", Right Click your project or use Alt+Enter and go to "Properties":
Be sure the debug profile is selected:
We will need some post build events to register our assembly:
These are the different commands:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\gacutil.exe" /u "$(TargetName)"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\gacutil.exe" /f /i "$(TargetPath)"
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" /unregister /codebase "$(TargetPath)"
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" /codebase "$(TargetPath)"
The order is important. First the assembly gets unregistered, then registered. The first time you run this, build will fail since these post-build events will fail. This is normal, the first time you build, there was no assembly registered and as such there is nothing to unregister. The second time you build, everything will work just fine. At this stage, after a successful, error-free build, manually starting IE should result in your BHO being visible:
Now we would also like to be able to just go and press F5, have the whole thing build, open IE and attach the debugger. Contrary to popular belief however, the VS 2010 debugger will not attach on its own, not even when defining "Start external program" in "Debug" (which in fact, is still necessary):
Doing so will start IE, your BHO should also run but breakpoints will not be hit.
To solve this we will use:
public virtual void SetSite(Object pUnkSite)
{
#if DEBUG
Debugger.Launch();
#endif
... Other code ...
}
This ensures that the debugger gets attached early on in the BHO lifecycle. Read about the nitty gritty details here.
Pressing F5 now will result in a few dialogs asking you which debugger to attach:
From thereon out it' s happy debugging:
I hope this helps!
EDIT
I recently was asked to bring some updates to a rather ancient BHO I wrote. Revisiting my own tutorial, I noticed some issues might come up when following it:
1) After quickly deploying a W7 machine with VS2010 (as released) I got a funky error when an attempt was made to attach the debugger:
I could resolve the issue by also installing VS2010 SP1 (as I used it originally) although I have no clue why this was happening.
2) Right now, when an attempt is made to attach the debugger, the instance of VS2010 holding my project is not in the list of available debuggers.
However, when I just cancel all dialogs and restart IE, the running instance is magically there and I can hit my breakpoints once again. The issue seems related to questions by others.
EDIT 2
The 2nd issue was solved after a full reboot, just as in the linked question.
Project + Properties, Debug tab. Select "Start external program", set it to c:\program files\internet explorer\iexplore.exe. You probably want to set the "Command line arguments" to the path of an HTML file that exercises your BHO.
Set a breakpoint on the code you want to debug. Internet Explorer will start running when you press F5. You'll see the breakpoint turning hollow, indicating that the breakpoint is not armed. As soon as IE loads your DLL, visible in the Output window, it will turn into a solid red. And the debugger automatically breaks when IE calls your code.
There is a registration step. Do always avoid using gacutil.exe, it does nothing but pollute the GAC on your machine. Always favor the "Register for COM interop" option in the IDE, the equivalent of running Regasm.exe with the /codebase option. No need for the GAC that way. Either way, VS must be running elevated to make these machine config changes, start it by right-clicking the shortcut and selecting "Run as Administrator".