Determining current Task ID from within an addin or debugger visualizer

Question

Suppose I halt at a breakpoint when debugging an application.  From within an addin or debugger visualizer I can access the debugger object, and from that determine the thread that was executing when the breakpoint was hit.  But I can't see any way of determining the task (or even the ID of the task) that was executing at that point.  I can get this information via the Parallel Tasks panel, by finding the row with the yellow arrow, so the information is clearly available at some level.  But I'd like to access this information programmatically, so is there a method that can be called to return the ID of the task currently running on a given thread that can be called when an application is "suspended" at a breakpoint?

Answer 1

In fact it would be really useful if all the information available in the Parallel Tasks panel could be made available via one or more APIs.  Hopefully there are plans to do that?

Answer 2

In Beta 1, you can do this with Task.Current.Id (noting that Task.Current will be null if there is no current task).  In Beta 2 and beyond, you can do this with Task.CurrentId, which returns a Nullable<Int32>, such that it will be null if there is no current Task, and it'll be the current Task's Id if there is one.

Answer 3

I know I can get the current ID in my user application by executing Task.Current.Id.  But I'm not running the application at the point where I want the ID, as the application has halted at a breakpoint.  So are you saying that the Visual Studio's debugger visualizer's GetData method runs within the SAME task as the task that was running at the point the application halted at the breakpoint (in which case I can execute Task.Current.Id within the GetData method to get the value I want)?  Or was my initial description confusing, and your reply is just for the case where you simply want to know your current task ID when you are running?  It feels like there's something missing in the current APIs.  When an application halts at a breakpoint there will be a set of threads associated with the process.  And a subset of these will be in the middle of running tasks.  So logically it feels like there should be a partial map from threads to tasks that can be queried, at least when the application is at a breakpoint, so users can extract the same kind of information as shown in the Tasks Panel in their debugger visualizers, addins etc.

Answer 4

When halted at a breakpoint, the Visual Studio debugger will execute code (e.g. funcevals, code in the Immediate Window, etc.) on whatever thread is the "current thread".  Typically this is the thread that halted at the breakpoint, but you can change it by, for example, double-clicking on a different thread in the Threads window or on a different Task in the Parallel Tasks window.

re: "So logically it feels like there should be a partial map from threads to tasks that can be queried"

The debugger gathers information about what Tasks are currently executing by walking through memory and call stacks looking for Tasks.  It's the debugger generating that information rather than the Framework providing it to the debugger in some manner.  It sounds like you're hoping for the debugger itself to provide some APIs in the future that would surface this data it's collected?

Answer 5

Thanks Stephen

So does your reply suggest I should, from within a debugger visualizer, be able to do the following. 

1. Set Debugger.CurrentThread to each thread in turn, and then 

2. use the TransferData method in the debugger visualizer to execute code in the context of the application that then accesses Task.Current and returns the result back to the visualizer?  

If so, then that will probably give me what I want.

Whilst it sounds like it might make sense for a debugger to expose in an API the thread to task map, wouldn't it also make sense to expand the Thread class to also provide a CurrentTask property?  I can appreciate it might be relatively slow, but if we now have threads executing tasks then it seems natural to query a thread for this information.

Answer 6

Here's an update on what I discovered in case anyone else wants to do something like this.  Setting Debugger.CurrentThread to each thread in turn, and then using the Debugger Visualizer's TransferObject mechanism didn't work.  The task ID I got back was always the same, the task ID that was active when I hit the breakpoint.  However, the debugger's GetExpression3 method did return the correct task IDs for each thread, albeit slowly.  So this approach at least allows the user to access the thread assignments for tasks that were running at the time the breakpoint was hit.  It still doesn't allow you to determine the thread assignments for tasks that are waiting, but I can live without that.  Hopefully the EnvDTE debugger interface will become more "task aware" over time.

Answer 7

Glad you got most of it working K_M. I have noted your feedback, please keep it coming.

Cheers
Daniel

---

http://www.danielmoth.com/Blog/