Xbootmgr Part 2: ReadyBoot Basics

The more I work with the xperf/xbootmgr the better I get with it. I still feel like I have a lot to learn though. I wrote a previous post, https://blogs.technet.com/b/markmoro/archive/2011/08/20/dipping-my-toe-into-the-xbootmgr-water.aspx , about troubleshooting my own machine with slow boot. Lately I've been doing some WDRAPs where we do a deep dive analysis on 1 or 2 machines. One area that seems to be overlooked as we are always looking for the service or script that is slowing the machine down is ReadyBoot.

Readyboot is boot acceleration technology that maintains an in-RAM cache used to service disk reads faster than a slower storage medium such as a disk drive. ReadyBoot reads (prefetches) data into the cache before it is requested. Prefetching optimizes disk access patterns by taking data locality and hard drive's performance characteristics into account. Read requests from system processes, services and user applications are then serviced out of the ReadyBoot RAM cache.

ReadyBoot plays a HUGE role on how fast Windows is able to start. If ReadyBoot is broken, the rest of your data can be skewed entirely. I check ReadyBoot first to see how it's looking before I move on to other areas.

Here is an example

There are 3 different colors I want to focus on. The first is blue are write requests to the disk. The second is black, these are misses which means a read requests was serviced from the disk instead of the ReadyBoot cache. This is ReadyBoot death. The third color is green. These are ReadyBoot hits which means the read request was satisfied from the ReadyBoot cache. Notice there is NO green in this picture. ReadyBoot is essentially broken in this trace. The boot performance reflects this as ReadyBoot is finishing after 130 seconds, there is still much more disk activity taking place after that.

So now we need to fix this. We run the following command.

xbootmgr -trace boot -prepsystem

This will cause the system to reboot 6 times and order the files in the best order for performance. Now let's look at the trace after this was run.

Notice all the green. ReadyBoot is done loading fully 70 seconds into the boot. A full 1 minute earlier then the previous trace which drastically cut down the boot time.. In a future post I'll talk about the other colors, red and orange.

Now I'm sure you are thinking, "How do I massively detect for this in my environment?" and "How do I massively fix this in my environment?" I don't have a good answer to those questions.....yet

Update: There is a better way, I spell it out here, https://blogs.technet.com/b/markmoro/archive/2011/12/07/slow-windows-7-boot-one-readyboot-fix-that-you-ll-want-to-apply-probably-anyways.aspx

Mark "ReadyBoot me some Great Lakes Christmas Ale" Morowczynski

Comments

• Anonymous
  January 01, 2003
  ReadyBoot and ReadyBoost are not the same thing. When you take an xbootmgr trace do you see ReadyBoot? You might have to hit the flyout menu on the left (the transparent arrow), to add it.

• Anonymous
  January 01, 2003
  Great Lakes Christmas Ale? Try Bell's. And nice work.

• Anonymous
  November 28, 2011
  Nicely summarized.  I'm doing this on my own machines now.

• Anonymous
  November 28, 2011
  I didn't even have ReadyBoost enabled on my work PC. One of those things never got around to. Went ahead and added a thumb drive and ran through this. Dramatic difference when comparing before and after. Need to check PC at home where I do have ReadyBoost on

• Anonymous
  October 26, 2014
  Thank you!
  
  Got a browser full of wpr tabs! technet is a goldmine!!! quick Q's:
  
  what's with the prepsystem?
  
  Charity writes (@ http://goo.gl/j5nvdJ)
  
  Note: If you are running a 64 bit version of Windows 7 or Windows Server 2008 R2, you will need to disable the paging executive in order to successfully gather event stacks. To do this, go to a command prompt and run wpr.exe –disablepagingexecutive on. You can also do this manually by setting DisablePagingExecutive (dword) to a value of 1(hex) under HKLMSYSTEMCurrentControlSetControlSession ManagerMemory Management. This does require a reboot.
  
  
  
  a) do I need to do this any time I've doing any tracing (inc. with xbootmgr -trace boot -prepsystem)?
  b) if this is a pre-requisite, can the disablepaging option be added to the list of parameters being used either with cmd wpr, or via optionsin GUI?
  
  Thanks again, Jonny