This topic is incredibly timely for me, as I've been building my own tool to do this recently. On this topic, I have some bad news. But before that... Ravi, I liked your UI, so I integrated a few features I had in my app into yours. I hope you don't mind.
Added:
Tracking of execution highlight and ability toggle it on all selected VIs
Tracking of paused VIs and ability to toggle pause on all selected VIs
Selection of project/target
Filtering of vi.lib
Filtering of global VIs
Filtering of control templates (.ctt)
Sorting by library name
Compressed the column text for some entries so more columns fit on the screen
Here's the modified VI:
LabVIEW Task Manager AQ Revision.zip
Just a bit of tweaking and it can be added directly to the Project directory and launched from the Tools menu. Sorry... it's 2am and I'm not doing that extra bit of tweaking right now.
Now, on to the bad news...
I've spent the last week working on exactly this sort of tool, and I've had a series of problems that I could not solve. I looked at the Task Manager uploaded by Ravi Beniwal, thinking he might have overcome the issues somehow. His tool has the same bugs, though he may not realize it. After consultation with other LV R&D folks today, I can now say that these bugs cannot be fixed in LV 2011 or earlier. And I'm doubtful we can do anything about them in the time remaining for LV 2012 features.
Two insurmountable problems I found...
-----------------------------
First: Affects reentrant VIs. There is no effective way to get a list of the clone VIs... you know, the ones that are named "XYZ.vi:1" or higher numbers.
These are the VIs that you often most need to abort, since one of the more common patterns in LV is to kick off reentrant clones running independently and then, when something goes wrong, you need to kill them. But you cannot get a list of all the reentrant clones that a VI has. You can open a VI ref to the clones by using Open VI Reference and passing a name in like "XYZ.vi:1". I tried checking each value sequentially until I got an error, only to discover that the numbers are not sequential. They can be any number up to MAX_Int32 (roughly 2 billion), so the "guess and check" method is out.
-----------------------------
Second: Affects both remote VI Server calls and local Asynch Call By Ref calls. You can't abort subVIs. The Abort VI method will return error 1000 unless the VI is the top-level VI. So what's the problem? When you launch a VI using the Asynch Call By Reference using "Fire & Forget" mode, it launches as a subVI, even though it will keep running if its caller quits. That means that even if the VI is not reentrant, so you can get a reference to it, you still can't tell it to abort. And there is no way to get the caller VI because the caller VI is a fake proxy (you can see it in the VI Hierarchy window). When you launch a VI remotely using the Run VI method or ACBR, you also have a proxy caller that isn't abortable.
-----------------------------
I've talked to multiple R&D staff with really deep knowledge of this issue, and there is no solution, and when I raised the topic was basically the first time that those involved collectively realized just how problematic this is to solve. I'd like to say something will be better in 2012, but that seems unlikely at this late date (yes, a month after 2011 released is late in our dev cycle; we do have to finish development pretty far in advance to get the testing solid).
The best workaround solution is to build a mechanism into your reentrant and dynamically launched VIs that allows them to be messaged by some tool to stop them -- like if they use a queue, register that queue with a central data store somewhere that you could run to kill all those queues, which would make those VIs exit on their own. Unfortunately, that lead me to discover the third issue. There's no solution in LV to have code that is conditionally compiled in only when debugging is enabled on the VI. Code that registers the VI with the central system is useful while debugging, but probably shouldn't be there when you release -- it's only going to create performance overhead and take up memory. But you'll have to remove it manually before you build your application OR create a custom conditional disable symbol in every project you write. I find this solution distasteful at best.
Anyway, that's my sucky news on the LV Task Manager front. I hope the edits I did add are useful.