Problem

The Visual Studio debugger does not stop on a valid breakpoint when attaching to an application running on your local PC, despite having all necessary elements present, including Symbol files (.pdb) and a current version of the assembly. There are no apparent errors – the code simply executes all the way through without ever stopping on the breakpoint.

Solution

Both Visual Studio and the application you’re debugging need to be running with the same level of elevation.

If the application is running as a local Administrator (such as IIS or a Windows Service) then Visual Studio needs to also be running as an Administrator. If the application is running under your own user context then Visual Studio should also be launched under your own user context (i.e. NOT as an Administrator).

Close Visual Studio and re-open it with the matching level of elevation and suddenly your breakpoints will be hit!

Details

When I was developing traditional ASP.NET applications on a Windows 7 system, I found that it worked best to always open Visual Studio as Administrator. This allowed me to easily attach to my local IIS as well as other custom Windows services for debugging. I even went so far as to set the default behavior for my system to always open Visual Studio as Administrator.

Fast forward to present (2019). I’m now developing custom web functionality and plugins for Dynamics 365 Customer Experience (CRM). There’s really no need for Visual Studio to run as Administrator. And yet, that was one of the first customizations I applied as I configured my development environment for this project.

I discovered that I was unable to debug plugins using the Plugin Registration Tool, despite carefully following Microsoft’s instructions. The debugger on my system would never stop on a breakpoint, no matter what I tried!

Just to clarify, the breakpoints all appeared valid, showing that the symbols were successfully loaded. A common cause for not being able to debug is not having the symbol filed loaded; that was NOT the case in my situation.

I compared my process with other team members and they were able to debug the same code with no problems. While watching another team member one day, I noticed that he was not opening Visual Studio as Administrator.

Then it hit me! The reason I needed Administrator in the past is that the local processes I was debugging were also running as Administrator (IIS and Windows Services). But this process (Plugin Registration Tool) was running under my own account – I launched it as I would launch any other application.

The Visual Studio debugger seems to only be able to work within the user context of Visual Studio. So if you want to debug an application running as a standard user, then Visual Studio must also be running as a user. If you want to debug a process running as Administrator then Visual Studio must be running as Administrator.

Keep this in mind and your debugging will always be on target!