Rider makes it easy to debug the 3rd party code. But sometimes it is just too much noise when debugging my own code.
VS has the option "Just My Code" which lets us debug only our code. Does Rider has the same?
Here is how it should work. All exceptions are disabled but Any Exception options has Only in my code option checked. It works as allowed filter with no exclusion.
Help about this page: https://www.jetbrains.com/help/rider/Breakpoints_dialog_Rider.html
There is also another option: Process exceptions outside of my code.
I was not able to see any differences with this option enabled/disabled.
Help is unfortunately empty for this option: https://www.jetbrains.com/help/rider/Settings_Debugger.html
Yes, there is an option as documented here
To disable external-code debugging
Clear Enable external source debug on the Build, Execution, Deployment | Debugger page > of JetBrains Rider settings Ctrl+Alt+S.
If this option is disabled, you can still
navigate to the external code and set breakpoints there. However,
breakpoints in external code will be ignored by the debugger and you
will not be able to step into the external code. So your debugging
experience will be limited by the source code in your solution.
I have a solution (VS 2015) with a Fortran console application-project (Intel Fortran compiler) and a C++/CLI library. I'm calling into the C++ library via Fortran C-bindings.
Example function on the C++-side:
extern "C" __declspec(dllexport) void PrintInteger(const int * const a)
{
std::cout << *a << std::endl;
}
Corresponding function on the Fortran side:
module CplusplusWrapper
interface
subroutine PrintInteger(a) bind (C, name = "PrintInteger" )
use iso_c_binding
implicit none
integer (c_int), intent(in) :: a
end subroutine
end interface
end module
Now, fortunately, I got this to work. And I can even start debugging the Fortran application and then step into the called C++ code. However, as soon as I add any managed functionality to my C++/CLI project, this doesn't work any more. It doesn't even have to be in the same function, it can be a totally different file...
I already tried going to the C++-project's properties -> Configuration -> Debugging and set the debugger type to "mixed", to no effect.
Any hints on how to enable debugging into managed code?
I found a solution to my problem, which is described on the intel website.
Create a dummy C# class library, which does not need to contain any files. Set this dummy project as start project of your solution (right click -> set as start project).
On the new project's options page under "Debug", set "Start Action" from "Start project" to "Start external program", and select your fortran-executable there. Further down, check the option "Enable native code debugging".
To get the correct build order within Visual Studio, right-click you project, choose "Build dependencies" -> "Project dependencies" and there checkmark your fortran application. This ensures that the fortran application will be build first if outdated when you hit "Start debugging".
It may well be possible to use any other kind of managed project (VB.NET, C++/CLI, ...) as dummy project, however, I haven't tested that since my solution contains C# projects anyway.
I'm trying to get managed Edit & Continue working (in Visual Studio 2015 v14.0.25425.01 update 3) and it's giving me the dreaded dialog, "Changes are not allowed in the following cases:"
Attached to a process that does not support Edit and Continue on attach.
I'm using IISExpress v10.0.14358.1000, on Windows 10.0.10586, x64.
I have 'Use the 64 bit version of IIS express for web sites and project' checked in Tools->Options. (although, i also get the same error with 32-bit iisexpress)
all my code is compiled 'Any CPU'
The code being debugged was optimized
Nope, the all the code is built with the DEBUG constant set, and no optimizations.
The assembly being debugged is loaded as domain-neutral
Nope, i checked with Process Explorer, the assembly isn't loaded DomainNeutral.
The assembly being debugged was loaded through reflection.
Not sure about this, but it's a regular ASP.NET MVC 5 app.
Intellitrace events and call information is enabled.
Nope, intellitrace is disabled in Tools->Options->Intellitrace.
The .NET Runtime this program is running on does not support edit and continue.
Not sure. It's built against ".NET Framework 4.6.1", and the first symbol load is "'iisexpress.exe' (CLR v4.0.30319: DefaultDomain): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll'"
some other things:
in the 'Web' project settings, both the 'ASP.NET' and 'Enable Edit & Continue' checkboxes are set (and none of the others).
i have 'Edit and Continue' enabled in the Debugger settings.
i have compatibility modes disabled in the Debugger settings.
i have tried deleting my .suo files and the .vs directory, cleaning out my temporary directories, doing a full rebuild
what else can i try?
PS. if anyone on the VS debugger team is reading this, can i ask a favor? please kill this dialog and replace it with something that indicates the actual cause of the problem. You have the debuggee right there, and the solution, you can determine which of these is causing the problem and you can have a button which fixes the problem with a single click.
ok, for posterity. it turns out that the problem was caused by an environment variable (which presumably was configured by the profiler at some point):
COR_ENABLE_PROFILING=1
removing this fixes edit & continue.
it would be great if the error popup could mention this, or even detect it and give you an option to fix it for you...
Has anyone been able to get this going with VS 2010 SP1?
I've tried the instructions at:
http://msdn.microsoft.com/en-us/library/x54fht41.aspx
http://referencesource.microsoft.com/serversetup.aspx
http://blogs.microsoft.co.il/blogs/arik/archive/2010/07/12/step-into-net-framework-4-0-source-code.aspx
http://referencesource.microsoft.com/troubleshooting.aspx
This is very frustrating.
UPDATE (More information):
My debug test code looks like this:
private void TestSymbolDebugging()
{
string myValue = this.txtData.Text;
}
and the breakpoint is set on the only line of code in the method.
If I just F11 (step into) it skips over the line with no error but it doesn't break into anything either.
If I right click and select 'Step into specific' I have the choice of System.Windows.Forms.get_Text. This gets me the No Source Available window.
I have 'Enable .NET Framework source stepping' checked.
I have 'Step over properties and operators (Managed only)' unchecked.
I have 'Enable source server support
I have 'Require source files to exactly match the original version' checked.
In the modules window I show the System.Windows.Forms assembly is loaded.
I'm working on a ColdFusion project for a while now, and Visual Studio started to behave strange for me at least.
I observed that when I started debugging, it built the project, it started the deploy, and the deploy finished and it was starting to load symbols for my project.
But it was very slow, and I don't know why it started to do this step. What may I have done?
Is this symbol loading step necessary? How can I disable it?
In the Tools -> Options -> Debugging -> Symbols dialog there is no Symbol file (.pdb) location added. And I pointed in my project's debug directory at the field below, and I checked the "Search the above directory only when symbols are ...." checkbox. How should I set up this dialog to turn off symbol loading?
I looked in the Modules window which symbols are loaded, but it says nothing to me. What is the problem?
Debug -> Delete All Breakpoints ( http://darrinbishop.com/blog/2010/06/sharepoint-2010-hangs-after-visual-studio-2010-f5-debugging )
After that you can use them again, but do it once. It will remove some kind of "invalid" breakpoints too and then loading symbols will be fast again. I was chasing this issue for days :(.
Another reason for slow loading is if you have disabled "Enable Just My Code" in Debugging options. To enable this go to:
Tools -> Options -> Debugging -> General -> Enable Just My Code (Managed Only)
Make sure this is checked.
Just had this problem.
I fixed it by navigating to:
Tools -> Options -> Debugging -> Symbols
Then unchecking all non-local sources for Symbol file (.pdb) locations
e.g. Microsoft Symbol Servers and msdl.microsoft.com/download/symbols
Configure in Tools, Options, Debugging, Symbols.
You can watch the output window (view, output) to see what it's doing usually. If it's really slow that probably means it's hitting a symbol server, probably Microsoft's, to download missing symbols. This takes three HTTP hits for each file it can't find on every startup - you can sometimes see this in the status bar at the bottom or in e.g. Fiddler. You can see which modules have loaded symbols in Debug, Windows, Modules whilst you're debugging.
Symbols mean you get useful stack trace information into third party and system assemblies. You definitely need them for your own code, but I think those get loaded regardless. Your best bet is to turn off any non-local symbol sources in that menu and, if you're loading lots of symbols for system assemblies that you don't need to debug into you can temporarily disable loading those to speed up debug start - but they're often useful to have loaded.
I faced a similar problem. In my case I had set _NT_SYMBOL_PATH to download from Microsoft Servers for use in WinDbg and it looks like when set, Visual Studio will use that with no way to ignore it. Removing that environment variable resolved my issue.
You can try the following answer to Visual Studio debugging/loading very slow:
Go to Tools -> Options -> Debugging -> General
CHECK the checkmark next to "Enable Just My Code".
Go to Tools -> Options -> Debugging -> Symbols
Click on the "..." button and create/select a new folder somewhere on your local computer to store cached symbols. I named mine "Symbol caching" and put it in Documents -> Visual Studio 2012.
Click on "Load all symbols" and wait for the symbols to be downloaded from Microsoft's servers, which may take a while. Note that Load all symbols button is only available while debugging.
UNCHECK the checkmark next to "Microsoft Symbol Servers" to prevent Visual Studio from remotely querying the Microsoft servers.
Click "OK".
Also try to delete all the breakpoints(Debug>Delete all the breakpoints),
See Also: Visual Studio 2015 RC1 Hangs in Debug mode while loading symbols
For me, it seems related to breakpoints, as indicated in the accepted answer. However, I found two workarounds that did not involve deleting all the breakpoints:
Restarting Visual Studio seemed to fix it temporarily.
Clicking the "X" button to close Visual Studio while debugging causes the "Do you want to stop debugging?" message box to pop up; while this message box is up, the symbols load at ordinary speeds. Once all the symbols are loaded, you can click "No" to cancel the close.
Just encountered this issue.
Deleting breakpoints didn't work, or at least not just on its own.
After this failed I Went Tools > Options > Debugging > Symbols and "Empty Symbol Cache"
and then cleaned the solution and rebuilt.
Now seems to be working correctly. So if you try all the other things listed, and it still makes no differnce, these additional bits of info may help...
Visual Studio 2017 Debug symbol "speed-up" options, assuming you haven't gone crazy on option-customization already:
At Tools -> Options -> Debugging -> Symbols
a. Enable the "Microsoft Symbol Server" option
b. Click "Empty Symbol Cache"
c. Set your symbol cache to an easy to find spot, like C:\dbg_symbols or %USERPROFILE%\dbg_symbols
After re-running Debug, let it load all the symbols once, from start-to-end, or as much as reasonably possible.
1A and 2 are the most important steps. 1B and 1C are just helpful changes to help you keep track of your symbols.
After your app has loaded all the symbols at least once and debugging didn't prematurely terminate, those symbols should be quickly loaded the next time debug runs.
I've noticed that if I cancel a debug-run, I have to reload those symbols, as I'm guessing they're "cleaned" up if newly introduced and suddenly cancelled. I understand the core rationale for that kind of flow, but in this case it seems poorly thought out.
In my case Visual Studio was looking for 3rd-party PDBs in paths that, on my machine, referenced an optical drive. Without a disc in the tray it took about Windows about ~30 to fail, which in turn slowed down Visual Studio as it tried to load the PDBs from that location. More detail is available in my complete answer here: https://stackoverflow.com/a/17457581/85196
I had the same problem and even after turning the symbol loading off, the module loading in Visual Studio was terribly slow.
The solution was to turn off the antivirus software (in my case NOD32) or better yet, to add exceptions to it so that it ignores the paths from which your process is loading assemblies (in my case it is the GAC folder and the Temporary ASP.NET Files folder).
My 2 cents,
I was having a similar problem while trying to get a (Visual Studio 2013) Diagnostics Report in x64 Release Mode (CPU Sampling) and while the symbols for the needed dll files were loaded, the symbols for my executable would fail to load.
I didn't change anything in the Symbols menu, I instead made some changes within the Property Pages of my executable's thread in the Solution Explorer, namely
Configuration Properties / General / Enable Managed Incremental Build to YES
Configuration Properties / Debugging / Merge Environment to NO
Configuration Properties / C/C++ / Enable Browse Information to YES (/FR)
Configuration Properties / Linker / Enable Incremental Linking to YES (/INCREMENTAL)
EDIT : This last one does the trick
....
Configuration Properties / Linker / Debugging / Generate Debug Info to Yes (/DEBUG)
....
After that it worked and it loaded the symbols fine.
I'm sure one or more of the above did the trick for me (although I'm not sure exactly which) and just want to let others know and try this..
peace
Try right clicking at one of the breakpoints, and then choose 'Location'. Then check the check box 'Allow the source code to different from the original version'
Unchecking "Enable JavaScript debugging for ASP.NET (Chrome and IE)" in Tools->Options->Debugging->General resolved my case with unavailability to launch VS2017 debugger with pre-set breakpoints.
The only thing that worked for me was changing the code type.
In the Attach to Process window, I changed the Attach to: selection to Automatically determine the type of code to debug, then my breakpoints were hit.
I previously had only Native code selected.
goto project properties -> debug -> uncheck enable native code debugging
I had a similar issue where visual studio keeps loading symbol and got stuck.
It turns out I added some "Command line arguments" in the Debug options, and one of the parameters is invalid(I am supposed to pass in some values).
After I remove the extra parameter, it starts working again.