Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


Andrew Richards windev Andrew Richards
  • Part 1: Series Introduction

    Just watched all 34 episodes back-to-back. (Power was out in the office so I thought I'd make the most of the day).

    Wow, what a great series. I'm a Win32 C++ guy, with little UI or C# experience, and I followed along easily with all the concepts Bob presented. I'm enthused to write my own app now - just need an idea... Maybe something to do with my series "Defrag Tools"? Tip of the day/week perhaps?

    Thanks Bob!

  • Part 14: Modifying DataTemplates

    At 6:53, the margin change should have been done to the image, not the textblock. Absolutely a great series... Been watching all day. Cool

  • Defrag Tools: #13 - WinDbg

    @felix9: The Defrag Tools series arose as a spinoff of Defrag Show so that troubleshooting tools in general could be covered at depth. We did a lot of research in the forums and this was one of the posts we paid a lot of attention to. Golnaz (our great studio operator) organized Brad to tackle the managed code aspect of windbg in his series (http://channel9.msdn.com/Series/-NET-Debugging-Stater-Kit-for-the-Production-Environment) - while we were planning Defrag Tools.

    On Defrag Tools, we're being more generic than Brad's series and are talking about the basic commands and the underlying OS constructs you need to know about. We'll defer to Brad's series for specific (deep) managed code debugging tips. We will and do cover the basics (next week is all about getting SOS loaded - for example) of managed debugging.

    This is a show for you - steer us in the direction you want us to go... If you want more than 10 episodes on WinDbg, tell us that and we'll hold off transitioning to xperf and will keep on producing windbg content for you. Chad and I both train the user and kernel mode courses within Microsoft and can easily continue to dive deeper and wider - from the physical hardware, up through kernel mode, through user mode and up in to high constructs like managed and WinRT application code.

  • Defrag Tools: #13 - WinDbg

    @James: we have 5 in the bag and still at least 3 more to tape to just cover the basics. I expect another 5-10 after that on advanced stuff.

    The main issue with reducing the courses down to a show format is the inability to interact with the students. When we get in to some particular concepts (breakpoints come to mind), we'll provide examples that you can (and should) repeat at home - as showing it once won't suffice.

    The other struggle for Chad and I is doing all of the debugging with public symbols and extensions - we have internal tools that rely on private symbols that get us to root cause within seconds (this is how OCA and WER scale). Its a training exercise for us too to do it the public way!

    Next week is loading SOS, then there are 2 on kernel, then 3 on useful commands. Well then go on to scenario based episodes using advanced techniques.

    Multi-process - will be sure to cover that .. It's not too hard if you use the right tool.

    The content is hard - yep wrong word - it is just information overload as you say - and we plan to keep it that way abd never miss a deep dive in to a concept.

    Once all this is done, we'll cover xperf - which is debatable more powerful than the debugger.


    Thanks for watching.

  • Defrag Tools: #11 - ProcDump - Windows 8 & Process Monitor

    [Update: 2012-10-26: This is fixed in ProcDump v5.1]

    Due to a bug in ProcDump v5.0, when using -x <folder> <appusermodeid>, some applications get "RPC server not available" exceptions and then fail. The workaround is to debug the package (not the app) and manually activate the application.

    procdump.exe -ma -e 1 -f "" -x c:\dumps <packagename>

  • Defrag Tools: #13 - WinDbg

    @Magic: ProcDump v5.1 -- nearly there. It's going through the final phases to get published externally. Hopefully this week.

    @Charles!analyze -v is covered in Episode #15 (Kernel Analysis), and will get mentioned again in Episode #17 (User Analysis).

  • Defrag Tools: #12 - TaskMgr and ResMon

    @dentaku: Windows Performance Toolkit is the answer. It records the function and duration of every DPC. You can get the win8 version in the ADK - it now has a UI application for the capture. Capture the box and then view the ETL file in wpa.exe.

    If you need help, email defragtools@microsoft.com. We are not covering xperf in the next 5wks at least.

  • Defrag Tools: #10 - ProcDump - Triggers

    Yep, you sure can. You will need to use the PID as there will be more than one w3wp:

    Procdump -ma -e 1 -f outofmemory <pid> c:\dumps

  • Defrag Tools: #8 - Mark Russinovich

    @SteffenZeidler: Use the ETW and Tooltip32 APIs to get this data.

  • Defrag Tools: #8 - Mark Russinovich

    @SteffenZeidler: each core has a thread for idle processing. These are represented by PID 0 (which doesn't really exist). The threads consume working set as the threads need to be paged in to work.

    Process Explorer has history support. New history columns were added about a year ago. Instead of being numbers they are graphs. There is no explicit api that gives you the history. The closest thing is being an ETW consumer and polling the system with the tooltip32 API.

    ProcDump is designed to not change the state of the target. If you wrote your own MiniDumpCallback DLL (-d <dll>) you might be able to force the flush of the ETW buffers  - it'd only work if the target didn't needed to execute any of it's threads (as they will be all suspended).