Defrag Tools (HD) - Channel 9

In the spirit of Star Trek crossovers, Andrew Richards and Chad Beeder pay a visit to Gov (Rhymes With Orange) Maharaj, the co-host of The Defrag Show. We talk about how each series got started, the focus of each, and how the two sometimes overlap. Gov has a wealth of knowledge, a lot of it being garnered from his role as a developer on the Windows Application and Device Compatibility Team for over 16+ years, but also by doing research for you, to answer your questions. In this episode we cover a lot of things, but of note, we talk about the version of Windows. How it is reported to applications and drivers, and the common misconception that the version number represents functionality. We've previously taped in Studio F when visiting Raymond Chen. And we've previously talked about API Contacts with Larry Osterman. As mentioned while in the kitchen, Bill Gates made a Coke (Coca-Cola) commercial years ago. Email us your Questions/Comments: Defrag Show: [email protected] Tools: [email protected]

In this episode of Defrag Tools, Chad Beeder and Andrew Richards walk through using various tools to determine what is causing Andrew's computer to be slow and unresponsive. Resources: Process ExplorerProcess MonitorAutoruns Mark Russinovich Videos on Windows Internals: 2nd video is the video referenced by Andrew. Mark Russinovich: Inside Windows 7 ReduxMark Russinovich: Inside Windows 7Mark Russinovich: On Working at Microsoft, Windows Server 2008 Kernel, MinWin vs ServerCore, HyperV Questions/comments? Email us at [email protected]

In this episode of Defrag Tools, Chad Beeder and Andrew Richards discuss the PsPing command-line tool from Sysinternals - a more powerful replacement for the default "ping" command, which also adds additional capabilities such as bandwidth measurement. Additional Resources: PsPing ProcDump Debugging Tools for Windows (includes WinDbg) Timeline: [00:00] Introductions and overview.[02:12] Plain vanilla "ping" command and its limitations[05:15] PsPing allows you to ping a different port than the standard ICMP "ping" port[08:35] Andrew's story about using PsPing to troubleshoot a network problem at home[11:14] Demo: using PsPing to measure network bandwidth[17:58] Using the -h switch to get a histogram of the bandwidth over various attempts[18:15] Oh no! The program crashed![18:36] Installing ProcDump as the just-in-time debugger, to get a crash dump so we can debug it[20:20] Using WinDbg to analyze the crash[23:41] Questions? Email us at [email protected]

In this episode of Defrag Tools, Chad Beeder and Andrew Richards discuss the Powercfg command-line tool in Windows, which allows you to configure power management settings, and analyze power and battery usage. Additional Resources: Powercfg Command-Line Options Timeline: [00:00] Introductions and overview. Welcome back, Andrew![03:35] One facet of Powercfg is that it offers the command line equivalent of the Power Options GUI[07:02] The /availablesleepstates shows the sleep state capabilities of your system[08:08] You can enable/disable Hibernation (S4) with the /hibernate switch.[09:27] The /devicequery switch is useful to tell you which devices on your system are capable of waking it from sleep. You can also use /deviceenablewake and /devicedisablewake to configure this.[10:51] The /lastwake switch will tell you why your system woke up.[12:50] /waketimers will tell you if any application has requested the system to wake up at a certain time.[13:05] The /requests switch tells you if any application is preventing the system from going to sleep, keeping the screen on, etc. The /requestsoverride allows you to override this if necessary.[16:11] The /batteryreport is a cool way to see the condition of your battery as well as recent usage history.[19:45] The /energy switch will run a tracing session for a specified period of time and give you an idea of suspected energy configuration problems and top CPU users[25:42] Questions? Email us at [email protected]

In this episode of Defrag Tools, Chad Beeder and Jorge Novillo discuss a power saving feature in Windows: hardware offloading of Audio Processing Objects (APOs). We demonstrate how to use Media eXperience Analyzer (MXA) to determine whether audio offload is working on a given system.Additional Resources: Implementing Hardware Offloaded APO EffectsWindows 8.1 Audio streaming - Part 2: Power savings via H/W offloadWhat's New in Audio for Windows 10 Timeline: [00:00] Introductions and overview[02:25] To see if it's working: first capture a trace in Windows Performance Recorder (see Defrag Tools #149 for a demo)[04:43] Examining the first trace. First look for the Audio_Render events to confirm that audio was playing during the trace.[07:00] Filter down to the audiodg.exe process and note the audio pump thread running every 10ms. Conclusion: audio processing was not offloaded.[08:07] Looking at the Callstacks dataset to find out which Audio Processing Object was running on the CPU.[10:09] Examining a second trace for comparison. Same steps as before - no AudioDG pump thread running frequently. Conclusion: APO processing was offloaded in this case.[12:24] Questions? Email us at [email protected]

Collecting and visualizing Windows 10 Energy Estimation Engine (E3) data with "powercfg /srumutil" and ExcelIn this episode of Defrag Tools, Chad Beeder and Jorge Novillo take a look at the Energy Estimation Engine (E3) in Windows, and how to use it to get detailed information about battery usage. Note: In addition to viewing data from a single device, as demonstrated in the video, an OEM, during device pre-production, or an enterprise IT administrator could create domain scripts to generate and collect E3 SRUMUTIL logs on a daily or weekly basis and collect the information in a database. This would allow the OEM or enterprise to analyze energy usage data from devices, and identify opportunities to improve battery life on their Windows images.Additional Resources: Energy Estimation Engine (E3) presentation from WinHEC 2015Energy Estimation Engine (E3) lab from WinHEC 2015 Timeline: [00:00] Introductions and overview[01:04] First step: Look at the Battery Use UI, in the Settings app[02:11] How to reset the battery usage data, for testing and analysis purposes[04:45] Use powercfg /srumutil to get a detailed report on power usage - we can use Excel to analyze it[06:20] Note the "MeasuredPower" column - tells you whether there is a power meter chip in the device (for more accurate reporting)[09:07] Using an Excel Pivot Table to analyze the data. This report also includes background processes not shown in the Battery Use UI.[12:08] We can also get a more granular breakdown of usage by various apps, and even generate fancy charts![16:51] Questions? Email us at [email protected]

In this episode of Defrag Tools, Chad Beeder and Sylvain Goyette demonstrate how to do critical path analysis in Windows Performance Analyzer (WPA), to troubleshoot apps which have an unresponsive UI. WPA is available in the Assessment and Deployment Kit (ADK). Timeline: [00:00] Introductions and overview[02:10] Thread scheduling states (for lots of details see the Windows Internals book)[04:28] Sylvain's sample app - click a button and the UI hangs[05:10] To diagnose: Launch Windows Performance Recorder and get a verbose mode trace using First level triage and CPU usage profiles.[07:40] Open the trace in Windows Performance Analyzer. Make sure you have the symbol path configured (including the symbols for your app).[09:19] First, look at the UI Delays graph and find the hung UI thread.[10:40] Then look at CPU Usage. Start with the UI thread we found previously and, using the CPU Usage (Precise) events, find the dependency on another thread.[15:11] Look at the call stacks - New Thread Stack and Ready Thread Stack columns. Ready Thread tells you what it was waiting on. Repeat as necessary to find what we were ultimately waiting on.[23:10] Can also look at the CPU Usage (Sampled) view to get a statistical view of what the CPU was doing during a given time period.[24:42] Another example: Do the same type of analysis on a boot trace, starting with looking at the Windows Logon instrumentation to see why logon is slow.[29:29] Questions? Email us at [email protected]

In this episode of Defrag Tools, Chad Beeder and Sylvain Goyette discuss how to analyze and optimize Windows boot performance, using tools available in the Assessment and Deployment Kit (ADK). Timeline: [00:00] Introductions and overview[01:31] In-box feature: Task Manager Startup tab will show estimated startup impact of various processes and let you disable them[02:10] More scientific measurement: Use the ADK's Windows Assessment Console to run the Boot performance assessments. There are two: Fast Startup and Full Boot.[02:52] Discussion of traditional (Full Boot) vs. Fast Startup/Hybrid Boot (introduced in Windows 8)[05:12] Various options you can configure when running the Boot performance assessment[07:38] Note that it will do six reboots before taking the measurements, to make sure the boot prefetcher (ReadyBoot) is fully trained[09:26] Open the results XML file in Windows Assessment Console. Example: comparing a baseline (clean OS install) vs. an OEM preload image with extra software installed[11:23] Main Path Boot vs. Post On/Off sections. Post On/Off is a heuristic where the assessment tries to estimate the time until system settles down to idle[13:00] Drilling into the various sections of the report[15:50] Keep in mind that you need to enable Auto Logon for the test to be valid.[18:05] Next step for deeper analysis: Open the analysis trace in Windows Performance Analyzer.[21:58] Looking at the CPU Usage (Sampled) graph to see who was using CPU during Post On/Off phase[23:04] Filter out low-priority threads since they don't impact the user experience[25:36] Looking at the Disk Usage graph and filtering out low-priority I/O[29:45] Questions? Email us at [email protected]

In this episode of Defrag Tools, Chad Beeder and Sylvain Goyette discuss how to diagnose issues related to memory usage, using tools available in the Assessment and Deployment Kit (ADK). We cover two scenarios: Looking at the baseline memory footprint of a particular Windows installation, and comparing it to the usage during a certain activityDiagnosing memory usage and leaks in a particular app.Timeline: [00:00] Introductions and overview[01:43] Scenario 1: Get a baseline memory measurement of your system at idle, using the Windows Assessment Console. Run the Memory footprint assessment.[04:08] Open the resulting XML file to see who is using what memory[08:33] Collect a memory usage snapshot at any time by using Windows Performance Recorder and selecting the Resident Set analysis profile. Capture a short trace.[10:37] Open the trace with Windows Performance Analyzer and look at the ResidentSet graph to drill into the memory usage data[16:57] Scenario 2: Memory leak analysis. Capture a longer trace, using VirtualAlloc usage and Heap usage providers.[18:09] You need to set a registry key to specify which process you want heap tracing enabled on. This is noted in the WPR documentation.[19:44] What is the difference between heap usage and VirtualAlloc usage?[20:45] Looking at Sylvain's test app which leaks memory[22:37] Open the trace in WPA. Use the VirtualAlloc Commit LifeTimes and Heap Allocations graphs to see the memory usage over time and track down where the leaks are in your app.[31:33] Questions? Email us at [email protected]

In this episode of Defrag Tools, Chad Beeder and Jorge Novillo wrap up a series on Media eXperience Analyzer (MXA). We examine one more audio glitch scenario, and show how to use MXA to determine what caused the problem. Media eXperience Analyzer (formerly WindowsXRay) is a tool used to visualize ETW traces, with a particular emphasis on media scenarios such as audio/video capture and playback. For an introduction to MXA, and explanation of how to capture a trace, refer to Defrag Tools Episode #149. Timeline:[00:00] Introductions and overview[01:20] Loading the trace into MXA[01:50] Step 1: Start with the Audio Glitches dataset to see where we need to look in the trace[02:52] Step 2: Look at the CPU Scheduler dataset to see what was going on at that time[04:04] Filter on the audiodg.exe process to see the activity of the audio engine - notice a gap in the audio pump activity[05:57] Look at the Call Stack when the thread started again after the delay. What was it waiting on? (Hard page fault)[07:27] Ready Thread viewer tells you what was running when our thread was ready to run, but couldn't.[08:28] Hard Page Faults dataset lets us see what file we were paging in during this time: the DLL for the Audio Processing Object was paged out.[12:47] Email us at [email protected]