Develop Reference

"No symbol has been loaded for this document" when debug asp.net mvc framework source code

I am trying to debug asp.net mvc source code. Here are the steps I took:
I set up a bare-bone asp.net mvc application (version 5.2.4) by using the template offered by Visual Studio 2017.
I downloaded asp.net mvc source code from offcial github, and according to this, MvcHandler will be hit in the code path so I put a breakpoint in its processRequest() method.
I follow the instruction from the microsoft reference web (there is a link on the main page) about how to set up VS and I use "https://referencesource.microsoft.com" as symbol server.
During debugging, I also make sure "System.Web.Mvc.dll" is loaded (dll for MvcHandler).
I think I get both source code and pdb, but I still get error: "no symbol has been loaded for this document". I want to know what other steps I can take to solve this.
Some other posts I read:
(1) can't debug asp.net MVC
(2) same error message

There should be no need for you to download the MVC 5 source code, the whole point of symbols and source servers is to fetch those source files for you as needed while debugging.
I use "https://referencesource.microsoft.com" as symbol server
That's likely your problem - Reference Source is only for the .NET Framework. In order to get MVC 5 symbols and source files, you need to add a different symbol server, such as SymbolSource - see http://www.symbolsource.org/Public/Wiki/Using.
You should also be aware that a lot of the information around debugging with symbols is outdated. In particular, in VS 2017 and later, there is a new option under Tools > Options > Debugging > General called "Use managed compatibility mode", which should be unchecked.
If all else fails, since you already have the MVC source on your machine, simply point your solution at - either by removing the MVC DLL references and including and referencing the relevant projects in your solution, or by replacing the MVC DLL references with references to your own locally-compiled DLLs. This is a lot more pain and effort than using symbol servers, but it's also 100% reliable.
For troubleshooting purposes, the Modules window (Debug > Windows > Modules when debugging) is invaluable; it will show you what DLLs were loaded by your project, what PDBs were loaded for them and where from, and if a PDB wasn't loaded it will tell you why. You can also manually force a PDB to be loaded via right-clicking a particular DLL and browsing to its location.
See also: Debugging Asp.net MVC 5.2.3 source code

I solved my problem.
Instead of using Asp.net Mvc 5.2.4, I downloaded the latest Mvc package here: https://dotnet.myget.org/feed/aspnetwebstack-dev/package/nuget/Microsoft.AspNet.Mvc
and that does the trick for me (Everything else I did stay the same).
So if one version doesn't work for you, try a different version!

a matching symbol was not found in this folder

first of all, this is a repetitive question. but things are not same in my case. I have tried most of the solutions. but nothing changed. so, here is the problem,
I have standalone sdk for a fingerprint device and working with visual studio 2015 windows form application. When I tried to debug, I got this message, "The breakpoint will not currently be hit, No symbols have been loaded for this document".
I tried: Build --> Windows --> Modules to load symbol. but they referred a symbol of one of the dll file (Interop.zkemkeeper.pdb). which I didn't find there instead I found a .pdb file as my project name (AttLogs.pdb). (I know its not logical though) I tried to choose the AttLogs.pdb. and then I got a message saying, "A matching symbol was not found in this folder". So,
1. How do I make my code debug-able? or
2. How do I create a Interop.zkemkeeper.pdb file?
please suggest me anything related or helpfull. I got stuck here for about a week.

Error "mscoreei.dll not found" in VS2015 debugging

When I'm trying to debug my dump file I get an error:
mscoreei.dll not found
mscoreei.dll was not found in the minidump. You need to load the binary in order to find the source for the current stack frame.
I have a project in C# that can hang sometimes on other computer. Each time as it hangs, 'procdump' app creates minidump file for me. Previously, I could normally open this dump file in VS2015, which shows me a stuck place in the source code.
Everything works fine till I made a 'clean up' in the repository. I didn't add any line in the code, I just clean up repository and all my .pdb files were exterminated. I build project again to restore .pdb files. But now as I try to debug dump files, VS2015 shows me page "No Binary Found" with error message written above.
I didn't make any changes in the source code. I didn't modify my environment. Debugging stops working as I made repository clean up.
When I'm checking 'Stack Frame' list, then evrything that is coming after "mscoreei.dll!7311ffcc" have format "[Frames below may be incorrect and/or missing, no binaries loaded for filename]".

I found the problem. It turns out, that my environment changed. From the last build when debugging worked correctly, Windows Update service updated my .NET library. As result my new build is using updated .NET files, but dumps are created for old .NET. Restoring correct version of .NET helped me.

The Breakpoint will not currently be hit. No symbols where loaded for this document

Windows 8, VS2013 IIS8,5
I'm trying to connect to a local WEB API by connecting to processes w3pv.exe (Managed (v4.0.30319), 19). The website front end and back end is both running fine on my local IIS. Right after publishing my x86 web API to the local IIS i try to connect to the process, where the break point states "The Breakpoints will not currently be hit. No symbols where loaded for this document". My colleague' can without any problems debug from his local computer.
So far I have.
Reinstalled VS2013.
Checked All Debug Properties
-Project -> build: Define DEBUG constant check / Define TRACE constant check.
Generate serialization assembly = Auto. Advanced build settings -> Debug info = full
Enable Just My Code: Check, Use Managed Compatibility Mode: Check
Enable Edit and Continue : Check
Made sure all Debug mode is set and all project Configured to Active solution platform x86, marked Debug and Build.
Deleted all bin and obj folders, as well as pdb folder in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
Reset IIS.
Set Select Code Type to Automatically determine the type of code to debug
Checked in IIS that .Net compilation -> Debug and Enable Prefetch is set to true.
And I still get the same error message. Anyone found anything in addition to this?

I have encountered similar problems many times while training new employees in our very complicated devenv, so here is our internal step by step instruction:
Don't panic
Make sure you attached the debugger to the correct process - you debug the plugin by launching VMS which is external app that has separate config file where the plugin path is stored, so when you change just your configuration Debug/Release it doesn't work.
Make sure you have symbols generated for the assembly Project properties->Build->Advanced->Output section
Make sure the build path hasn't changed. You may have accidentally changed the path and you may only think that the assembly you are trying to debug is the correct one.
Investigating the information you provided this is only help I can think of. My guess is the files you publish are not the files you're debugging locally.

RESOLVED (embarrassed)
A few day's ago, I downloaded the front-end code for the website from the VPN (GIT). I forgot to update the code-behind reference in the App.js file in the front end root. This, of course, referred to the API on the cloud, and not my local API.
This took me way to long to find out. But, at the same time, it's not a solution I've seen so far on the web.
Thanks for all your help.

Slow symbol loading in an ASP.NET Project in VS2012

I'm having an issue with loading symbols on my ASP.NET MVC project. The first time I load visual studio and debug my project, symbols are loaded in roughly 2 seconds. I then end the debug session, make a code modification, and debug again, and the symbol load time is about a minute. Based on the research I have done, here are some applicable settings on my machine/VS:
In Options/Debugging/Symbols/Symbol file locations, "Microsoft Symbol Servers" is unchecked, and there are no additional locations.
Options/Debugging/Symbols/Cache symbols in this directory is "G:\Symbol Cache". I did click "Load all symbols" and I have inspected that directory and I see lots of symbols.
Just my code is enabled.
The _NT_SYMBOL_PATH and _NT_ALT_SYMBOL_PATH environment variables are not defined on my machine.
Options/Debugging/Symbols/Automatically load symbols for is set to "Only specified modules", with no modules specified.
I have tried both debug and release builds, with identical results. Ctrl + F5 loads the site almost immediately.

I too had this problem, the cause was that I had accidently enabled the "Microsoft Symbol Server"
You can disable it by going to Tools > Options > Debugging > Symbols and uncheck the "Microsoft Symbol Server"
Now it loads just as fast as it used to.

I too had this problem and noticed that it was mostly related to 3rd-party assemblies acquired via NuGet. In these cases, Visual Studio was trying to load PDBs from paths that apparently existed on the original author's machine (i.e. D:\OriginalAuthor\MyVisualStudioProjects\AwesomeNuGetPackage) but on my machine the same path referred to an optical drive. I then discovered via Command Prompt that if you tried to change directory to an optical drive that didn't have a disc in the tray, it took a very long time (~30 seconds) to fail. With this in mind, my solution was to simply place a DVD in the tray. At that point Visual Studio was able to very quickly determine that the path didn't exist, skip loading the PDB, and go straight into debug.
So, if Visual Studio is taking a long time to load symbols, watch the Output window for the paths it's trying to access and verify that you can quickly access (or quickly fail to access) those paths yourself via Command Prompt.
This brings up an interesting question about security/privacy--apparently Visual Studio is storing the absolute path of the original PBD within the assembly. I suppose this isn't a super critical issue, but from a privacy perspective I don't really want my absolute filesystem paths being exposed to the public without my knowledge.

Just try this Debug -> Delete All Breakpoints.
Its works on me.

I had 2 .dll's giving me grief that I didn't need to debug that started taking minutes to load. The afore mentioned solutions didn't help. So I went to Options -> Debugging -> Symbols and under the radio button for "All modules, unless excluded" click on "Specify excluded modules" link. Then type the .dll's that are causing issues.