I have a c# solution A in my Visual Studio 2010. I have added a dll of solution B as a Reference. I have built solution B with "Debug".
If I run solution A in debug mode I can debug into solution B (Step Into F11) and see the code. That's nice. If I am NOT in debug mode and I "Go to definition (F12)" of external code Visual Studio opens a file without the body/logic of the methods :-( It looks something like an Interface.
Is it possible to "Go to definition (F12)" of external code in edit mode? Do I need a plugin?
I do not want to edit the external code. I just want to read the logic and set breakpoints.
This situation only happens in non-Debug modes. It's better to run both in Debug when you are going to debug and set breakpoints.
Run both in the Debug mode.
Related
I want to debug a C++ MFC/CLI program developped on Visual Studio 2019.
Until now, I can debug C++ native (MFC) code.
DebugType in Debug panel is set to Auto.
All breakpoints in C++/CLI modules are flagged as inactive (a red circle with an interrogation character in a yellow triangle).
After having changed DebugType from Auto to 'Mixed (.Net Framework), Visual Studio, when starting a debug session, is displaying following warning box.
But my build is in DEBUG mode !
What is happening ?
What must I do to debug pure C++ AND CLI C++ code ?
PS: I have also tried to debug in only C++/CLI code, but Visual Studio 2019 is displaying same message !
On Visual Studio 2019, how to debug pure C++ and CLI C++ in a C++
Debug program?
Since I do not have your project and cannot troubleshoot the issue quickly unless you provide a sample.
You can try the following suggestions:
Suggestions
1) try to reset all settings by Tools-->Import and Export Settings-->Reset All Settings
2) disable any third party extensions under Extensions-->Manage Extensions in case one of them causes the behavior.
3) check Use Managed Compatibility Mode option, Enable .NET Framework source stepping option and Suppress JIT optimization on module load (Managed only) option under Tools-->Options-->Debugging-->General.
4) close VS, delete .vs hidden folder, Debug folder from the solution folder and also Debug folder in the project folder. Then restart your project to test again.
I'm putting this here because it might help someone in the future, and because it's completely nuts.
I've followed all instructions I could find, including the ones on this question, reinstalled VS twice, with different versions, and nothing.
What solved for me was to simply delete the lines of code and write them again.
Yes.
I know.
I use IronPython for a lot of debugging, and I usually attach my Visual Studio debugger to ipy.exe, then import and use a .NET assembly to step through my code. However, I find that the IronPython Interactive extension for VS2010 is more fully-featured than the ipy.exe shell, and I would like to know whether it is possible to attach the debugger to the extension. Thank you!
Right click on the project file (not the solution) Proprieties/ Debug.
Then you should select "Standrad Python Louncher" for launch mode. It will use the ipy.exe, for interpeter, just you can debug easier.
You sould make visible the "Python Debug Interactiv" from Debug menu
I have a program I made using Visual Studio that won't start unless VS is debugging. Where should I look for problems?
The program works when debugging through VS but won't start from the debug folder. The program works fine when debugging. No output is given.
For this sort of startup problem I'd suggest running your app in Windbg (part of the Debugging Tools for Windows). Do File -> Attach to executable and then hit F5. You should get more informative output there. I suspect it's a dll dependency or manifest problem. Another useful tool is the Dependency Walker which may highlight some dlls that are on Visual Studio's path but not your default path, which may also explain the error. Another thing to try is check that all types of debug output are being shown in Visual Studio: right-click to get the context menu in the debug output window and ensure it's showing exception messages and module load messages.
Try turning on Stop on Exceptions
Debug - Exceptions - Common Language Runtime Exceptions (thrown and user unhandled)
I see that with the 'Attach to Process', one can debug the process by setting up break point in Visual Studio IDE.
I think it's pretty cool, and I'm curious what's the mechanism that enables it. I also found that gdb and Mac's Xcode supports the technology.
Q1 : Can anyone explain how does this work? How can the process mapped to a breakpoint in an IDE or gdb environment?
Q2 : Are there other compiler/debugger options than /Zi or -g (adding debug info)?
Q3 : Is this the way to debug dll (dynamic library)?
ADDED
I found this one with MSDN - http://msdn.microsoft.com/en-us/library/c6wf8e4z.aspx
The most common scenario I know of is using a browser to debug web code. In these cases, you start Visual Studio in debug mode and then attach to the browser and call the page in question. When the page is called it starts running the code in the debugger. Essentially, the debugger watches the process and when it hits code in VS, it starts debugging.
The same is true with other applications that are calling code you are running in Visual Studio. When you cross the boundary to the code, the debugger catches the call and starts running code in VS.
I use it fairly frequently when developing plugins for existing applications (Maya, Reaper, etc). As a general rule, plugins can't be run independently, so in order to debug them I have to run the host program and use "Attach to Process" to run the debugger on my plugin, at which point I can set breakpoints and all that other debugging goodness. You need to have debugging symbols and al that for the plugin, but you don't need to have them for the host application.
My C# code is calling an unmanaged third-party library function via P/Invoke, and the unmanaged function is having some strange side effects. I want to debug into it and see what it's doing.
If I debug my C# code, and try to "Step Into" the P/Invoke call, it steps over instead. No surprise there -- I expected that; it doesn't have the source for this DLL, and I didn't tell it I was okay with seeing the disassembly view.
So I switch the debugger to disassembly view (Debug > Windows > Disassembly). Now I see the individual x86 instructions in my JITted code. Again I try to step into the P/Invoke call. Again, it steps over instead -- even though I clearly told it to Step Into an x86 CALL instruction. How hard is it to step into an x86 CALL?
My Googling thus far has shown me a couple of options that can affect this, and I've already set them:
In Tools > Options > Debugging > General, "Enable Just My Code" is unchecked.
In Project > Properties > Debug tab, "Enable unmanaged code debugging" is checked.
No good. Visual Studio still refuses to step in.
I don't have a PDB for the third-party DLL, but that shouldn't matter. I don't care about source code or symbol information. (Well, actually they'd be really nice, but I already know I'm not going to get them.) Visual Studio can do x86 debugging (that's what the Disassembly view is for), and all I want to do is step into the x86 code.
What else do I need to do to get VS to allow me to step into the x86 instructions inside a P/Invoke call?
This may help you solve the problem:
(by Graviton)
CallingConvention = CallingConvention.Cdecl
Also this mentions that you need to detach managed debugger and re-attach unmanaged when crossing the boundaries. You might need to check the capabilities of mixed debugger and it's preferences from MSDN.
And finally, using Ed Dore' answer:
Under Tools.Options dialog, select the
Debugging category, and make sure the
"Enable Just My Code" setting is
unchecked. From the Project
properties, select the Debug tab, and
then ensure that "Enable unmanaged
code debugging" is checked.
Once you've got these squared away,
you should get the mixed mode
debugging support working.
Also, if you use "Debug.Attach To
Process" , be sure to hit the
"Select..." button in the "Attach To
Process" dialog, and select both
Managed and Native debugging support.
One thing I would try is going from C# to C++/CLI code, and then from C++ to the third-party code. Once you're in C++ (and free of the P/Invoke infrastructure), you might have better luck with the disassembly view.
In your C# project properties, in the Debug tab, check Enable native code debugging. Worked for me in VS 2012.
Credit goes to billb.
Also, since it's a third party library, ensure Enable Just My Code is unchecked in Options > Debugging.
I had a similar issue where I was debugging a C# exe that called my own C++ dll via PInvoke, all part of the same solution. Enabling native code debugging in my c# project allowed me to debug my C++ code.
Had same issue today.
What helped in my case was to run Visual Studio as administrator.
My setup:
Visual Studio 2019
Windows 10