New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remote debugging woes #538

Closed
douglasware opened this Issue Oct 7, 2017 · 10 comments

Comments

Projects
None yet
4 participants
@douglasware
Copy link

douglasware commented Oct 7, 2017

Apologies ahead of time for not having steps to reproduce this, but over the last couple of months the quality of the remote debugging experience has degraded substantially and is now frequently extremely frustrating. We've noticed this with both VS2015 and with VS2017.

The most common issue we now see frequently is that the debugger will appear to be attached and breakpoints will light up, but code execution will not halt.

@CANUSA

This comment has been minimized.

Copy link

CANUSA commented Oct 7, 2017

Going into Process Explorer and killing the msvsmon process(es) seems to be the only way to "revive" it (sometimes).

image

@tohling

This comment has been minimized.

Copy link
Member

tohling commented Oct 8, 2017

@douglasware, @CANUSA, thank you for letting us know. We are reaching out to VS team for help. We will update this thread with more info soon.

@tohling

This comment has been minimized.

Copy link
Member

tohling commented Oct 9, 2017

@douglasware, @CANUSA - Unfortunately, we have not been able to repro this with our own Functions. Could you provide additional details? We'd like to know the following:

  1. The versions of VS you are using when this is happening?

  2. How are you attaching the debugger? Are you using Cloud Explorer?

  3. How are you deploying your code? Could you verify that they symbols are loaded and that they match?

  4. You mentioned that you are frequently seeing issues with the breakpoints lighting up but not halting. Are there any other issues that we should be aware of as well?

@douglasware

This comment has been minimized.

Copy link

douglasware commented Oct 9, 2017

@tohling

  1. Observed on multiple machines with both 2015 and 2017. Ongoing issue since the beginning of August (I know because I complained on twitter August 6) :)
  2. Yes, using Cloud Explorer right-click attach
  3. Custom scripts in VS 2015, Publish wizard in 2017 with Azure Functions tools. Symbols and assemblies are definitely correct
  4. Occasionally the debugger will throw a null object exception on attach and sometimes the debugger will freeze the function app until the host notices it is unresponsive and kills it.

It should be noted that simply firing up the debugger the first time seems to work OK. The issues arise during longer working sessions on subsequent debugging sessions. I know @CANUSA was debugging two different function apps with two different instances of Visual Studio open. I believe that is the scenario where I have also had the most trouble, but I've also seen it with a single instance of VS after repeated debug/change/deploy/debug cycles.

@tohling

This comment has been minimized.

Copy link
Member

tohling commented Oct 9, 2017

@douglasware, could you share your Function App name and Function name directly or indirectly? If indirectly, kindly provide the following:

  1. From your Function logs, copy and paste any entry with the format 2017-10-09T21:40:03.147 Function started (Id={some Guid}). We need that Guid to locate your Function.

  2. The region that your Function App was deployed in.

@douglasware

This comment has been minimized.

Copy link

douglasware commented Oct 9, 2017

@CANUSA

This comment has been minimized.

Copy link

CANUSA commented Oct 10, 2017

Happy to help, how can we connect? Today, the debugging experience is horrible, it is happening continuously at this point.

2017-10-10T18:20:36.960 Function started (Id=db60a0cc-9aa1-45e6-a6a2-bd49d73e9a92)
East US

@tommcdon

This comment has been minimized.

Copy link

tommcdon commented Oct 11, 2017

H, @CANUSA and @douglasware

This is Tom McDonald on the VS Debugger Team. There appears to be 3 high-level issues that need investigation:

  1. NullReferenceException on attach – is this happening in VS itself or in the debuggee? If in VS, can you send us a dump of VS when the null ref occurs? Note that it is probably easiest to attach a second instance of VS with JMC disabled and NullReferenceExceptions configured to “thrown” in exception settings, then Debug->Save Dump As) If the latter, the customer can provide a callstack. My email address is "t o m m c d o n AT m i c r o s o f t DOT c o m". If a sharepoint upload link would work better, please email me and I will send it to you.

  2. Sometimes the debugger will freeze the function app until the host notices it is unresponsive and kills it – is VS itself frozen or is the azure function hung? If it is VS, similar to above, please send us a dump of devenv.exe (and if we can get the remote msvsmon.exe that would also be helpful).

  3. Bound Breakpoints not hitting – Same as the above two, I think we will want to start with a dump of devenv.exe (and the remote msvsmon if possible) while the issue is occurring. We can verify that the local IDE and debug engine agree on the breakpoints that are set. If after we verify this and determine the breakpoints are set correctly, further investigation on the azure backend will be needed.

Also can you confirm that all 3 of these issues are occurring on VS 2015 as well as VS 2017? Also when did the debug experience get worse? Did that involve upgrading VS?

If I have missed something, please let me know.

Thanks,
Tom

@douglasware

This comment has been minimized.

Copy link

douglasware commented Oct 11, 2017

Hi Tom,
With regards to when I first noticed the issue, it was the first week of August. I know because I tweeted my annoyance on August 6. I was working on some bug fixes for a few days before I made the tweet, so my guess would be around August 3.

@douglasware

This comment has been minimized.

Copy link

douglasware commented Jan 10, 2018

Sorry for taking so long to come back and close this out. This is not a bug, but rather a result of auto-scaling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment