You know how you can click the yellow arrow on a breakpoint and drag it down to skip execution of lines of code? Well, is it possible to create a "When Hit" macro (or something similar) that skips execution of the line containing the breakpoint?
So instead of writing code like
if(!Debugging)
Response.Redirect("LoginFail.aspx");
I could sit a breakpoint on the Response.Redirect() line and "When Hit" will skip it.
I don't know of baked in way of doing this. You can however set the "When hit" options of a breakpoint to run a macro. It shouldn't be hard to write a macro that gets the current line, and then sets the next debugger line. You'll probably want to look at the Debugger.SetNextStatement method.
A macro like this should do it:
Public Sub SkipNextLine()
ActiveDocument().Selection.LineDown()
DTE.ExecuteCommand("Debug.SetNextStatement")
End Sub
Yes, you can do this directly using a tracepoint.
Find the address of the return statement or final closing curly brace at the bottom of the function by breaking on it once, and then looking at the EIP register either in the Registers window or add a Watch for "#eip".
Add a tracepoint to the line you want to jump from. Remember that the jump will occur before anything on the line is executed. The content of the tracepoint should be {#eip = address} using the address from step 1.
See also https://stackoverflow.com/a/14695736/301729
There's no way I know of to do this with a breakpoint but you can use compiler directives to skip code
#if (DEBUG)
//this code is skipped in debug mode
#endif
Try:
#if DEBUG
Response.Redirect("LoginFail.aspx");
#endif
Make sure you have the DEBUG constant checked in your build properties.
Agree with the use of compiler directives or any other requiring to add logic in code. However, also understand editing the debugged code is not always an option (e.g. not owning the code might imply not having all resources needed to build it).
If that's your case, I'm afraid that writing your own macro or waiting for VS to have one built-in equivalent are your only options.
Related
Given the code
[Test]
public void Test1()
{
var a = new A();
a
.Method1()
.Method2();
}
is it possible to set a breakpoint so that execution pauses after Method1() has executed, but before Method2 without going to the definition of Method2 and putting a breakpoint there? When I do it, the breakpoint appears at the 'a'.
you can't set a breakpoint there, but you can set your breakpoint on the whole statement, and then use the "Step into Specific >" command on the right-click menu (Debug.StepIntoSpecific) to step into Method2().
you can also do repeated step in/step out to step through the indivdual method calls of the compound statement.
Use Rider instead of Visual Studio. IntelliJ Idea is capable of logical step in when fluent syntax is used. It is 2017 and fluent syntax is everywhere (LINQ). Shame on Visual Studio (even 2017).
No, the debugger's unit of executable code is a statement. There are only two in the method body in your snippet. Post feature requests to connect.microsoft.com. It's going to be a hard sell, it is not technically impossible but a potentially heavy re-engineering effort.
I am wondering what difference it makes to the debugger (Intellij IDEA + Scala plug-in) when I debug Scala code and not Java code. To my understanding, a debugger is tightly coupled with the language i.e. a Java debugger can not handle Scala code but apparently the JVM is the center of attention here meaning as long as it is byte-code, any debugger would do. right ?
IMPORTANT UPDATE: The problem was to give an example of how a byte-code debugger may be limiting for Scala. Assume a break point is reached and I don't want to go to the next line but I want the debugger to evaluate an Scala expression in the context of the application (e.g. I like to call an operator method from a singleton object). The debugger is stuck because it can not understand Scala. I have to do the transformation myself and input the resulting Java to the debugger.
The problem is that only "breakpoint stuff" could be handled in byte-code level. What if you want to put an expression under watch? Debugger has to understand Scala to evaluate the watched expression,right? This time I'm sure I'm right. Vengeance is mine, Saith the Lord ;-)
Short answer your assumptions are wrong.
The reason is the debugger does not care what language your debugging. It stops at breakpoints which in turn include the line of a particular source file. Note that the source file is merely text for you to read - the debugger never scans the source files. If you change the spot where source files are to another directory with a text file in the right directory w/ the right filename as a breakpoint that has been set, the debugger will happily show it when the breakpoint happens. Everytime you set a breakpoint your ide is telling the debugger hey scan this class for any byte code on this line and stop when you hit it. This of course does not work if your ide is attempting to compile the same text file into a class file - however it will work if you create fake text files as source for a jar file and do the source file mapping thing.
If one thinks about it, writing a simple template and compiling it while support debugging is not that difficult. Simply use asm to create all the print statements and tell asm this print statement is from the template file on this line. After that you can add more clever stuff while keeping things debuggable.
I'm trying to simplify my debugging tasks and I had an idea which could increase my debugging speed.
Suppose I have a value, say 2.8651 that appear in the code at a moment I do not know.
I'm wondering if it was possible to create a super breakpoint which would stop at the first time one of the variable takes this value.
I recall that I do not know which variable takes the value.
I could know it by spending some time on the debugger but I'm lazy.
I'm not really familiar with VBA for VS. I guess, a solution would be to create a macro which would loop along local variable at each line of the code execution. It'd stop when the condition localVariable == 2.8651 is verified.
Thank you for your answers!
There's no such thing as a super breakpoint for a block of code. There are two options to achieve what you want:
Place a conditional breakpoint on each line with a variable assignment. Right-click the breakpoint and click Condition... to specify when it should break.
Place a single conditional breakpoint in the code block and check all the required variables in the condition.
As you suggested, you can place a single breakpoint with a macro, by right-clicking the breakpoint and select When Hit.... However, I highly doubt that it's possible to control the breakpoint from the macro, so this wouldn't work.
I am using MSVC 6.0 to call a macro in the Win32API and I'm getting an access violation. I know that the pointers I'm passing to the macro contain valid addresses, though they're evidently not pointing to the correct data.
The macro accepts multiple pointers, and I'm not sure which pointer is erroneous, so I'd like to use MSVC's debugger to 'step into' the macro to see exactly where the problem is. When I've tried thus far, the debugger just throws the access violation error.
Is it possible to 'step into' a macro using MSVC 6.0's debugger? If not, is there anyway for me to check what the macro expands to, so I can get a better idea of what I'm not doing correctly?
If you really need to trace the macro code, the only way would be to find the definition of the macro, manually "instantiate" the macro code (substituting the parameters) in place where it is "called", and then trace it in the debugger as ordinary code.
Alternative variant would be to step through the disassembly, if your skill level is sufficient to back-associate the disassembled code with the original macro code.
You cannot step into the macro because at the point compiler does its job, the macro is already expanded. However, you can step through a macro - if you just do "step", you will actually step through all code inside the macro as if it was expanded, line by line. If you to "step into", you will step into every function call made from that macro. If the macro is small enough, and/or you know it very well, you can do a "blind step through" that way.
You can step into functions that are called from the macro but as far as I know can not really step through the macro lines themselves. And yes if you code compiles - you can find the macro definition (use MSVC function/class browser to find where it is defined, some header file probably)
I'd just step into the disassembly - usually, even if you're not an assembly expert, short runs of code (a few lines) the assembly map back to the C/C++ code pretty readily (especially in non-Release builds). Hopefully the macro isn't so hairy that that isn't the case here.
Remember that plenty of debugging occurs even without source code, so having the source and the disassembly together usually isn't too bad. And if it's something you haven't much experience with, it's great experience to get.
I am looking for a method to monitor a running program that I have the source code. Basically, when the user runs it, I need to know what functions and parameter is called sequentially.
I can write a trace output code to all functions to achieve this. However, I am not allowed to modify the source code.
I found out that Tracepoint in Visual Studio 2005 allows me to do this - output log info without modifying the source. But I need to add them to all functions.
As I have thousands of files and functions, I need to find a way to programatically do this. I found out about DTE.Debugger.Breakpoints.Add that able to add a breakpoint. However, I couldnt find any way for tracepoint. Or where is the breakpoint info for a project stored? I couldnt find it in sln or vcproj. Or is there a way to convert breakpoint to tracepoint programatically? I see that I can change it manually by changing the "When Hit" property dialog.
Thanks!
You should cast your breakpoints to EnvDTE80.Breakpoint2. Then you'll be able to use
breakpoint.BreakWhenHit = false;
breakpoint.Macro = "YourMacro";
A .NET profiler will allow you to see which methods are executed and how long each takes without modifying the source code. It basically injects special code into the compiled assembly.
I think this is the solution... this macro adds a breakpoint the Main method of your program, and then turns all breakpoints into tracepoints.
Sub AddBreakpointToMain()
Dim bp As EnvDTE80.Breakpoint2
Dim bps As EnvDTE.Breakpoints
bps = DTE.Debugger.Breakpoints.Add("Main")
For Each bp In bps
bp.Tag = "SetByMacro"
bp.BreakWhenHit = False
bp.Message = "Hi, this is your tracepoint calling."
Next
End Sub
You could also look at Aspect Oriented coding. By my understanding this will change the compiled assembly controlled by attributes and is typically used to add tracing to all methods/properties.
How can I add a Trace() to every method call in C#?
First part of the solution:
DTE.ExecuteCommand("EditorContextMenus.CodeWindow.Breakpoint.InsertTracepoint")
It opens the TP window for the line where the cursor was. You will still have to hit Return to select OK, though. Enough for my needs--at least you don't have to right-click, etc.