5

Why does disassembler/disassemly-window pops up some times when I debug my asp.net website?

It happens some times, not always. I have searched on Internet but no useful result was found. e.g: It happened when I was trying to debug a query; it appeared after/when I reached a particular code segment that I used make one of 4 text-boxes enabled while keeping others disabled using updatepanels (nothing ground-breaking here).

My code works fine, I repeat, this disassembly thing doesn't cause any problem, it's just that this hasn't happened before.

Does this mean that something is wrong with my code or the way I write my code...or what??

Improve this question
1
  • First up (+5) in stackoverflow :) Welcome to stackoverflow!
    – Pyromancer
    Commented Aug 16, 2013 at 8:04

2 Answers 2

Reset to default
11

In Tools, Options, Debugging try disabling "Enable address-level debugging".

I'll add that often you can often enable "Enable just my code" (same page), but I think it is useful to keep it disable to comprehend when there is a problem outside of my code.

The window normally appear if you have: Enable address-level debugging enabled, Enable just my code disabled and you have configured the debugger to break on a thrown exception.

Often there are some "benign" (non-terminal) exceptions thrown inside the .NET code/other libraries code that are catched there, without surfacing in your code. With all these options "enabled (meaning set as I've told you)", the debugger will break on these exceptions (very boring quite often) and will have to show you something... But it doesn't have the source code, so it will show you the disassembly (or an empty window asking if you want to view the disassembly if you have the "Show disassembly if source is not available" disabled)

Improve this answer
8
  • Care to mention to pros and cons, and even the general influence(s)?
    – Grant Thomas
    Commented Aug 16, 2013 at 8:05
  • @GrantThomas From here: If you have enabled Just My Code, Break when an exception is: Thrown does not cause the debugger to break immediately if an exception is thrown in a .NET Framework method or other system code. Instead, execution continues until the debugger hits non-system code, then it breaks. As a result, you do not have to step through the system code when an exception occurs. But often am exception that rebounds to your code is modified by other external code... it's often better to be able to see where the exception is born
    – xanatos
    Commented Aug 16, 2013 at 8:07
  • Thanks, but I wasn't talking for my direct benefit, I meant to make the answer more than just an immediate fix, and instead have some greatly useful information. That's also the tip of the iceberg as far as this feature goes.
    – Grant Thomas
    Commented Aug 16, 2013 at 8:09
  • @GrantThomas I haven't ever used the address-level debugging :-) And I program from the .NET 1.1 ...
    – xanatos
    Commented Aug 16, 2013 at 8:11
  • So, a little bit of knowledge...
    – Grant Thomas
    Commented Aug 16, 2013 at 8:12
3

Disassembly window appears when you are trying to debug code that you do not have Symbols for and you have address-level debugging enabled.

Most common way to see this is to try to step into .Net code.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.