Unable to load symbols for remote debugging

[grayjeremy]

Running the newest version of VS 2017 15.7.4 and the newest "Azure Functions and Web Jobs Tools" version 15.0.40617.0

Created a functions v2.0 (preview) azure function project and added a new function with an event grid trigger.

Successfully debugged locally, then Web Deployed to an App Service (confirmed pdb's are on app service), and registered the event grid event. I am able to see event output from the "View Streaming Logs" function within the portal AND in visual studio by right-clicking on the app service in the Server Explorer -> Azure window.

When I click on "Attach debugger" (Server Explorer -> Azure -> App Service -> Function App Service)

Everything connects successfully and all my non-project symbols for dependencies are loaded. I have "Just my Code" disabled and have tried toggling "Enable Source Server Support" as well as "require source files to exactly match their original version" unchecked with no luck.

All my non-project symbols load, however the local ones don't and I can't match my local source code to what is running on the remote.

Did something break in 15.7.4 here?

[safihamid]

@grayjeremy nothing has changed for 15.7.4 and I just tested mine and everything works just fine. can u try again or create a new function app and let us know what exactly is not working for u?

Thanks
Hamid

[TobiasMalm]

I have the exact same problem. I created a new project and function app i azure. The problem remains.

[safihamid]

We have identified an issue that causes the function app to scale out to two instances when debugging is enabled in consumption plan. and when hitting the url of an http trigger function in that function app you could be sent to the other instance than the one VS is attached to and hence your breakpoints might not be hit.

The fix is checked in and we will deploy it in the next few weeks. but as a general rule when debugging functions in consumption mode, you will need to use tools like Fiddler or Curl to make sure only one concurrent request is sent to the function app to avoid scaling out as VS can only attach to one instance at a given time.

[grayjeremy]

This makes sense if the bug you found caused the .pdb's not to be deployed to the new instance(s). If the .pdb's replicated it seems like the symbols would load but the breakpoint wouldn't be hit on every request.

[safihamid]

@grayjeremy again the issue is not with symbols. pdbs as well as all site contents are always shared across all instances. The issue is VS connects to one instance and request ends up in another instance.

[grayjeremy]

I agree that the issue you found was not with the symbols, however, my issue was symbols not loading...not that everything loaded correctly and the server I was attached to didn't get a request. Either way, I'll retest when the patch goes out. Thanks for all your effort on this.

[safihamid]

One workaround for the time being is to set this app setting for your function app in consumption plan:
WEBSITE_HTTPSCALEV2_ENABLED = 0

This will cause the function app to not scale so aggressively and stay on one instance during debugging for dev/test scenarios.

[CoenraadS]

My functions run on Service Plan. I had 2 instances, setting it to 1 instance also fixed my problem.

[konradsikorski]

I have exactly the same issue. I have just created new azure function v2.0 from VS template. Pulished to new Azure Web Site. The App Service use B1 service plan, this plan support only manual scale. In Scale out options I have set 1 (ONE) instance. The function is deployed in debug mode and the pdb file exists on the server. After attaching from VS I am receiving exactly the same error 'no symbols loaded' any solution?

And my VS is 2017 15.8.6, azure function tools 15.9

[rohittidke]

Any solution yet? I am having the same issue.

[safihamid]

This is fixed by now. if you still hit this issue, make sure in Debug code types, 'Managed (CoreCLR)' is selected.

[simondel]

Unfortunately I'm not yet able to debug the code. I've set the application setting and also the 'debug these code types' setting.

[CasperWSchmidt]

This is fixed by now. if you still hit this issue, make sure in Debug code types, 'Managed (CoreCLR)' is selected.

This work-around worked for me. But why does it not recognize this automatically?

[MartyIce]

I was still seeing this issue with a .Net Core Azure Function project, and nothing in this thread was working for me. Finally stumbled across this:

http://dontcodetired.com/blog/post/Remote-Debugging-Azure-Functions-V2-The-breakpoint-will-not-currently-be-hit-No-symbols-have-been-loaded-for-this-document

It boils down to manually attaching to the process in Azure, rather than relying on the Cloud Explorer right-click functionality.

[iamalexmang]

We came across the same scenario.
Portable application written for .NET Core, Azure Functions runtime 2.0, consumption plan.
No solution to remote debug as of right now.

[Andrei0809]

I have the same problem.
.NET Core app, Debug, netcoreapp2.1, consumption plan.
Cannot remote debug.

[safihamid]

This should be working fine with workarounds mentioned above, if it's still not working, we will need more info. Is this failing when running locally or when running from Azure? Do you have the latest updates of VS and .Net Core installed? Did you try adding the above app setting to make sure your app runs on a single VM and does not scale when debugging? Did you select 'Managed (CoreCLR)' as the debug type?

[iamalexmang]

Yes, to all of the above. In fact, I even created a brand new application from scratch with a Timer Trigger, pushed it to a brand new resource with the magic App Setting set and Remote Debugger enabled (published Debug) and still, the debugger finds the process but never gets attached (symbols aren't loaded).

[safihamid]

@AmanG2205 I assume you are using functions V2, Does this work with http trigger? Maybe timer trigger doesn't fire? would you please email me your code and all your settings along with your function app name and I will invetsigate... hamids (at) microsoft (dot) com. thanks

[safihamid]

If the debugger is attached but breakpoints aren't hit, it means for some reason symbols weren't loaded for the function app. make sure the .pdb file is available in the .\bin folder then you will need to go to the 'Modules' tab in VS and right click on the function app's dll and manually load the symbols.

[iamalexmang]

The debugger is attached and the breakpoints aren't hit despite the pdbs being correct (for same binaries) and available at the right location.
As mentioned over the private e-mail as well, it seems that the list of modules isn't retrieved correctly for the published Function. This means that even though the .pdbs are accessible, they will never be loaded because the module isn't returned as a dependent module for the running process the debugger is attached to.

[iamalexmang]

After working on the matter with @safihamid, it turns out that the issue I had was that I heavily relied on Cloud Explorer which is bugged to a point where Remote Debugger won't work with runtime v2 because it incorrectly loads the symbols for .NET FX rather than .NET Core - hence, it's mandatory at this point to use the Attach to Process procedure to attach your debugger remotely and whilst you do that, make sure that you select Managed (Core CLR) instead of Automatic.
BTW, you may as well confirm that VS2017 fails at determining the right version code because Automatic will likely show that it tries to attach to Managed (v4.5, v4.5, v4.0) code rather than Core.
Also, this issue will supposedly be fixed in VS2019!
Hope this helps!

[fabiocav]

Closing this issue as resolved/answered.