@James G: I use a vhd for the show and it only runs during taping (so I don't add features to the install without you seeing it). The next time I prepare for a show, I'll make sure to give it some time to do the updates. Can't set a bad example can I!
The show will be weekly for at least another ~10 weeks based on the current episode recording schedule. We tape a few at a time if it is the same topic.
Next is vmmap, then we have a special edition, then inbox tools. After that in a yet to be decided order is 3+ on Windows Performance Toolkit, 2+ on Procdump, 4+ on Debugging Tools for Windows, Network Monitor, Fiddler and PsTools. In the maybe bucket is audio, video, printing and device troubleshooting (1 each). We will also probably do a live show on Channel 9 Live at Build.
Lots and lots of shows to watch! If your favorite tool isn't in that list, drop us an email at email@example.com or write a comment and we'll add it to the list or move it forward.
@siodmy: The repurposed of 0-4 is expected. It is the 5-7 that matter. You are getting enough memory pressure on 5 (1.6Gb -- x8 reused) to raise interest at least. Adding a few gigs will definitely help in those times - its not critical though.
@Tom Hall: Procmon may indeed be looked for by crysis. Some games don't like you looking at the I/O operations as they think you are trying to hack the game. All you can do iscrebiit (to unload the driver) and then play the game.
@MagicAndre1981: xperf is scheduled for a future episode. And yes, I agree that it allows you to go deeper. ProcMon does do a very good job though of presenting information required to get an idea of what is happening.
@Debojyoti: Great question. The answer unfortunately is No. ProcMon doesn't run in the right area of the kernel to know what handle is allocated for the successful operation.
The way Process Monitor gets the file operations is to insert itself as a filter driver. It is called first, just after FltrMgr.sys. It logs the result of IRP_MJ_CREATE operations that is receives as ProcMon 'CreateFile' operations. If you turn Advanced Output on, you'lll see that the Operation will be renamed from CreateFile to IRP_MJ_CREATE (the real name). At the time that the ProcMon driver sees the result of the IRP_MJ_CREATE operation (and last time it is involved in the call), all that exists is the pointer to the object. The object hasn't been added the handle table of the target process.
It isn't feasible to leverage the Process Explorer data either. ProcExp is only able to view the handle data on a process by process basis - this design doesn't gel with how Process Monitor works.
Note that some, if not most, CreateFile operations in ProcMon aren't actually a CreateFile call, they are the result of a memory mapping (nt!MmCreateSection) call that maps a file in to an address space, be it directly (CreateFileMapping) or indirectly (LoadLibrary).
ProcMon simplifies the world - maybe a little too much.