Virtual code execution via IL interpretation

As Soma announced, we just shipped VS2010 Beta1. This includes dump debugging support for managed code and a very cool bonus feature tucked in there that I’ll blog about today. Dump-debugging (aka post-mortem debugging) is very useful and a long-requested feature for managed code.  The downside is that with a dump-file, you don’t have a…


Func-eval abort is evil

Func-eval is evil. Func-eval abort is even worse. For those coming in late, Func-eval is when the debugger hijacks a thread and has it evaluate some function such as a property-getter or to-string.   Func-eval abort is when that evaluation hangs, and then the debugger aborts it (similar to Thread.Abort).  Visual Studio sets up a timer…


Resolving functions and func-eval syntax

I got a question about MDbg’s func-eval syntax, which brings up a nice point about function resolution: Is it possible to evaluate a function by specifying an instance variable instead of the fully qualified name of the class? f ex.get_StackTrace… is so much nicer than …System.Exception.get_StackTrace ex I really could have titled this post “Why…


Debugger won’t properly evaluate C#s base keyword

Public Service Announcement: You may have noticed that trying to evaluate members using C#’s ‘base’ keyword in the debugger still calls the derived members. (The ‘base’ keyword lets you access base class member implementations from within  a derived class, which is very useful when the members are polymorphic and so just calling the member directly…


"Correct" may depend on your point of view

Correctness from the debugger’s perspective is very different than correctness from the end-user’s perspective. For example, the debugger exposes many invasive operations like SetIp. The debugger considers the operation successful if it sets the IP to the target line. However, doing that may violate the program’s natural control flow and thus may be considered incorrect…


What does a debugger author need to do to support func-eval?

I’ve mentioned func-eval (aka property eval) is evil for end-users; but it’s also evil if you want to write a debugger that uses func-eval. For example, let’s say you’re writing your own managed debugger and you have a watch window, and you want to eval property-getters and ToString() calls on items.  Since VS does this,…


What to do with a feature that only works 90% of the time?

Imagine when you’re designing a feature if there was an operation that was very useful 90% of the time; but the other 10% of the time it was provably and innately unsafe (either crashed, deadlocked, or gave back garbage). By “innately unsafe”, I mean there’s some intrinsic quality about the feature’s requirements that make it…


Evil trick to render UI when stopped at a breakpoint.

Here’s an EVIL trick to render your UI in a winforms app when you’re stopped at a breakpoint. When managed-debugging, when you hit a breakpoint, all the managed threads stop. With a winforms app, the UI thread is managed and so it stops too. However, that same UI thread that’s pumping WM_Paint messages is also…


Blog Category for Func-eval

I created a blog category for Func-eval (aka Property Evaluation), and I updated some of my old posts to be in this category. And while I’m at it, some other func-eval blog entries:GreggM on Func-eval and WinformsSteveJS on Nested Break States (stopping mid func-eval)Update: Very *Evil* things you can do with funceval:1. Funceval a message pump2….


Rules of Funceval

Funceval (aka “Function Evaluation” or “Property Evaluation”)  is the ability to inject some arbitrary call while the debuggee is stopped somewhere. A debugger commonly uses funceval to run ToString() and property getters. I want to describe when it is legal to initiate a funceval. Doing a funceval:For the CLR, funceval means hijacking a given thread…