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...

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...

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...

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...

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...

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...

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...

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...

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 Winforms SteveJS on Nested Break States (stopping mid func-eval) Update: Very *Evil* things...

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...

It's possible for a managed debugger to attach to an app and inject arbitrary stub code into the app, without any prior cooperation from the app. The more technical description is that while the debuggee is stopped, the debugger can load an arbitrary module into the debuggee's address space and then...

Function evaluation (aka “Func-eval”, “property evaluation”, “prop eval”) is the ability for a debugger to have the debuggee call a random function when stopped at a breakpoint. For eg, this lets you call functions from VS’s immediate window. Func-eval is extremely useful. VS heavily uses it in...