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 开发者_StackOverflow社区them manually?
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?)
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.
This one is pretty easy but only if you know what is going on. Here is what to do.
- 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.
- 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!
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
You could try just stepping over the code with F10 until you hit the problem, it would have the same outcome.
I'm not sure if I understand your problem. You can use one breakpoint and then hit F10 (Step over) or F11 (Step into) to go the next instruction. That would be the same as having a breakpoint on every line and hitting F5 (continue) after each break. Or you can set a breakpoint at the culprit line and investigate the callstack window to see the control flow up to that point.
精彩评论