0

The "Just My Code" feature permits to limit debugging operations to user code (unoptimized code with available pdb).

Is it possible to break whenever program flow invokes "my code" in Visual Studio?

Potential application: when debugging issues in libraries used by a complex third-party application, anything that is called when the issue occurs is a good starting point. Breaking when entering own code would permit to do that without excessive logging.

dst
  • 3,307
  • 1
  • 20
  • 27
  • Do you mean that you want to edit your code during debugging? We often use E&C in VS, is it what you want to use? – Jack Zhai Sep 12 '17 at 11:07
  • @JackZhai-MSFT no, I don't need to edit code. The issue is that I don't know which parts of a library ("my code") are called by a third-party program. I'd like to attach a debugger to the third party application, and break whenever any code in the library is invoked. – dst Sep 12 '17 at 17:04
  • So you have no source code for the third party app, am I right? One idea is that you could use the attach to process and set the third party project as the " Start external program" like this case: https://stackoverflow.com/questions/13672751/how-to-debug-class-library-that-called-from-external-app, so you could add breakpoint in your class library,if it was hit, it means that your library was called by third party app. – Jack Zhai Sep 13 '17 at 08:56
  • @JackZhai-MSFT I know how to get the debugger running. The problem is that I do not know which of >1k potential entry points are used, so setting breakpoints manually is not really an option. Also, these entry points should ideally not break when they are called from within the library. My current workaround is using windbg (which at least supports wildcards when defining breakpoints). If you have a suggestion on how to improve the question, feel free to share it. – dst Sep 13 '17 at 14:41
  • Glad to know that you got a nice workaround, if you have to use the VS, maybe the Class Breakpoint is what you want to get: https://blogs.msdn.microsoft.com/habibh/2009/09/10/class-breakpoint-how-to-set-a-breakpoint-on-a-c-class-in-the-visual-studio-debugger/ – Jack Zhai Sep 14 '17 at 10:11
  • @JackZhai-MSFT That technique doesn't seem to work for namespaces, although it indeed looks promising. I also don't see a way to differentiate between "own" calls and external ones, although that might be possible using conditions. I'll just post my workaround as answer for now, maybe it will attract better ones :) – dst Sep 14 '17 at 19:05
  • Does putting a project on pause ("break mode") and then hitting F11 not break as soon as any of your methods is called? – alexkovelsky Jan 31 '20 at 23:24

1 Answers1

1

It doesn't seem so.

However, if all own code is within a few namespaces, windbg can be used as a workaround (the following is for unmanaged code; I assume there's also a way for managed code):

> bm ModuleName!NamespaceName::*

will set breakpoints for any entry point within the given namespace. If all access is single-threaded, windbg can even print a list of all actual entries performed in the execution:

> bm ModuleName!NamespaceName::* "bd *; ln; l+t; p \"dv; pt \\\"be *; r $retreg; g\\\"\""

will add breakpoints to all potential entry points that automatically perform actions to log and get out again:

  1. bd * disable all breakpoints as we're entering "own code"
  2. ln print information to the call location
  3. l+t; p "[...]" skip calling convention handling
  4. dv print locals (including arguments, which are now handled)
  5. pt "[...]" skip to method end
  6. be * re-enable breakpoints as we're leaving "own code"
  7. r $retreg log method result (if calling convention and result type cause a result register to be used)
  8. g continue to the next breakpoint

From the log it is usually possible to at least identify reasonable breakpoints and breakpoint conditions for a second debug run (in any debugger, including Visual Studio).

dst
  • 3,307
  • 1
  • 20
  • 27
  • Thanks for sharing your solution here, you could mark it as the answer. Of course, if we found other better workaround, we will share it here. Have a nice day:) – Jack Zhai Sep 19 '17 at 02:41