Freigeben über

Getting your feedback!

  • Artikel

I'm interested in our consumer's feedback and knowing what sort of things people would like me to blog about. If you have feedback or things you'd like to see me post on, please just post a comment on this blog instead of trying to send me email. (I bet half the blog authors prefer it the other way...)

Why email is bad: The spam filters on my email rock and are cranked up very high and frequently reject external emails as spam, and so I may never even get your email.

Why blog posting is good: Posts on the blog are public and so everybody else can see your questions and benefit from the answers. It will also help folks find other random individuals who may have similar technical interests.

Comments

  • Anonymous
    October 01, 2004
    Hi Jim!

    I'd be intrested to know what limitations are put on for example code generation when a debugger is attached.

    Or in other words, what in my app is working differently when run under a debugger?

    Regards,

    /Staffan
  • Anonymous
    October 01, 2004
    Hi Jim,

    I've tried a few memory profilers for the CLR (such as your CLRProfiler), and found that while the amount of information that one could collect was awesome, the collection process slowed my application down by so much that it made it painful to actually try anything interesting.

    What I'm wondering is whether it is technically possible to attach to an already-running CLR app and collect information on all the existing instances. This would be already quite useful, while not hampering the app between snapshots. It does not look like CLRProfiler can do this, is it a limitation of ICorDebug or did I simply miss something ?

    Cheers,
    --Jonathan
  • Anonymous
    October 01, 2004
    Those are both great questions.
    Staffan - I hope my most recent post answers your questions. check out: http://blogs.msdn.com/jmstall/archive/2004/10/02/236942.aspx

    Jonathan - Only debuggers can attach. Profilers <i>can't</i> attach. I'll try to post about profilers in more detail and dig up links to some blogs that may be helpful here.
  • Anonymous
    October 02, 2004
    I've been pondering this whimsy: What would it take to harness ILDASM in a managed debugger (of sorts) so that you can visually step through the IL code behing a running application? Every now and then I'm tempted to step into a Class Library routine and see what's happening inside (because, say, my client code doesn't get the expected results), but it is so hard and tedious to correlate the IL code (from ILDASM) with the actual native code being executed (and definitely the semantics of IL are way easier to discern than of x86 assembly). I've only heard of the tracing information optionally produced by the JIT compiler for debuggers. I suppose that would be the key to automatically and reliably correlating IL "source" and native machine code. I'll appreciate any insight into this or a pointer to relevant information. I might get inspired to start a hobby project.
  • Anonymous
    October 02, 2004
    Chango - Great question. In response, I just posted about the "IL-debugging": http://blogs.msdn.com/jmstall/archive/2004/10/03/237137.aspx