How to debug C# without breakpoints in Visual Studio?

Question

I'm having trouble to find the statement that causes a given side-effect. I put a breakpoint in every class member and I still can't make the execution pause on the culprit line.

• Is there a debugger option that makes the execution to pause at every line regardless of breakpoints?

or

• How to make every line a breakpoint without the effort of marking them manually?

Solution 1

You can pause execution, and then start tracing line by line (e.g. by pressing F10). This would give you the exact same effect of breaking at every line.

Edit: You won't have to put a breakpoint in each method is you use "trace into" (by pressing F11 in default settings). Then the debugger will stop in the first line of the method being called.

If you're having trouble debugging it, maybe before going for breakpoints some more static analysis is required... Can you describe the side effect you are trying to hunt down? Maybe then people can offer suggestions on how to find it or at least narrow the search.

Edit 2: I don't think you will find the side effect you described through a breakpoint. The verification of signed code is done by the CLR when you load a signed assembly. It has to access the network in order to update revocation lists.

To workaround this problem you can disable CRL checking. Here's some info on how to do it: http://technet.microsoft.com/en-us/library/cc738754(WS.10).aspx

Of course, you should be aware of the security implications (what if the certificate for the code you are running really was revoked?)

Solution 2

Put a breakpoint on the first line of your code that gets executed (e.g. the first line of your main function, if you're a console application). Then just use the single-step commands (F10 and F11, by default) to walk through the execution.

Solution 3

This one is pretty easy but only if you know what is going on. Here is what to do.

1. In Visual Studio with your project open hold ctrl-alt-E to load the Exceptions dialog. This gives you options for when to break. You will select "Common Language Runtime Exceptions" Thrown column.
2. Now go ahead and run your application. Now any CLR exceptions that are thrown will take you to the line of code that broke.

Don't forget to ctrl-alt-E and uncheck when your done!

Solution 4

The simplest way is to use the built in Break All feature of the debugger. It doesn't apply to every situation, but if it applies to yours, then it's very simple to use. Debug >> Break All (or CTRL + ALT + Break)

See the section titled "Break into code by using breakpoints or Break All" on this page for more information: Start, Break, Step, Run through Code, and Stop Debugging in Visual Studio

View more solutions

Comments

[Jader Dias]

Yes I know. It work only if I set a breakpoint in the first line of each method. I tried it already and it is cumbersome and not so effective.

[Jader Dias]

I don't know which is the culprit line. That's exactly what I am looking for.

[Cody Gray]

This is an excellent suggestion, so long as the code you're trying to debug is throwing an exception. The way the question is worded, he's trying to find the code that causes certain side effects, which doesn't necessarily mean it's throwing an exception.

[Jader Dias]

see my comments to similar answers

[phillip]

@Jader Diaz Yeah... after read all the comments I see what's up... There is no way to have all of them at once. What happens is that you can have it break at any 1 point while your debugging and any subsequent points that break will come to the front of your debug session.

[phillip]

You can use conditional breakpoints, break on exception, DebugBreak, Debug.Write and some others but debugging multi-threaded scenarios is much more difficult because the process may return at any given time.

[Tom]

+1 for pausing execution in a particular place. You can do this anywhere like in MessageBoxes etc, very useful.

[Jader Dias]

It would work for a single threaded app. And what about an event driven multi threaded app?

[Ran]

@Jader Dias, I understand the certificate wasn't revoked. I thought what bothered you was the check itself, and the access to the network that was done in order to update the CRL.

[Jader Dias]

@Ran the CRL is not my main concern, since I can download and install them manually, solving part of the problem for a few months. But I can't do the same with the STL. Even if I download and install it, a given machine will continue to search for it.

[Ran]

So this is not really a Visual Studio debugging issue, since the effect you are hunting isn't happening in your code and you won't be able to break into it. I suggest you add some more information about your problem with the STL, what you were trying to do and what went wrong.

[Jader Dias]

@Ran If I comment a given class and all references to it, the problem is solved. How it cannot be debuggable?

[Ran]

@Jader Dias, because this class probably has a reference to another class, so that in order to JIT that class the CLR now has to load an assembly that wasn't loaded before. And then it has to verify the signing of this new assembly.

[Jader Dias]

what doesn't make sense is the fact the problem only occurs if my assembly is signed.

[Elad Benda]

"You can pause execution" Great idea, but how can I pause it on the very start?