Andrew Richards

Andrew Richards windev Andrew Richards

Comments

  • Defrag Tools: #8 - Mark Russinovich

    @RyanRies: 6th edition Part 2 RTMed today, so it will be printed and available soon.

  • Defrag Tools: #8 - Mark Russinovich

    @siodmy: We are going to do a big series on xPerf which will cover logging for all applications.  I'll add Logparser to the list of applications to be covered in a future episode.

  • Defrag Tools: #7 - VMMap

    @Roger: They all come from the Microsoft Company Store (the shop on Redmond campus, as opposed to the retail shops we now have). You'll have to come visit campus!

  • Defrag Tools: #6 - RAMMap

    @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 defragtools@microsoft.com or write a comment and we'll add it to the list or move it forward.

  • Defrag Tools: #5 - Autoruns and MSConfig

    @Debojyoti: xPerf (WPT) profiling can help you here.  We'll go over this in detail on a future episode but the gist is:

    xperf -on Diag+Latency -stackwalk Profile+CSwitch+ReadyThread+ThreadCreate -BufferSize 1024 -MinBuffers 256 -MaxBuffers 256 -MaxFile 256 -FileMode Circular

    echo Press a key when you want to stop...
    pause
    xperf -stop -d result.etl

    Look at the result.etl with xperfview.exe

  • Defrag Tools: #6 - RAMMap

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

  • Defrag Tools: #6 - RAMMap

    @Phililp Saunders: It's from the Windows Internals books/David Solomon kernel course.  It is copyrighted to them, so I can't make it available for download Sad

  • Defrag Tools: #4 - Process Monitor - Examples

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

  • Defrag Tools: #1 - Building your USB thumbdrive

    @Joe:  If you have a enough space, definitely set the path to the USB Stick. I'd definitely do this if I was using one of those self-powered 2" harddisks. You'd use X:\My\... instead of C:\My\...

    _NT_SOURCE_PATH is used by Process Monitor and VMMap (and more).

    If you are internal to Microsoft, set the _NT_SOURCE_PATH and _NT_SYMBOL_PATH to the same value. The internal symbol server can download source code, as well as symbols and executables (images).

    _NT_SYMCACHE_PATH is used by Windows Performance Toolkit (xPerf)

    I'll dive deep in to these environment variables again when I do the VMMap, WPT and Debugging Tools episodes.

  • Defrag Tools: #4 - Process Monitor - Examples

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

  • Defrag Tools: #3 - Process Monitor

    @Debojyoti: NetMon (and Fiddler) is on the list of future episides - probably around episode #15.

  • Defrag Tools: #3 - Process Monitor

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

    Once again - great question!  Thanks for watching.