33 Seconds lost at boot…

Imagine you are an enterprise customer who has several thousand desktops that boot slow.  Inordinately slow…slow enough that your user base resists requests to reboot them for patch cycle or power savings efforts or diagnostics.

So imagine you do the right thing, you keep the BIOS and firmware up to date, you update drivers, you do everything you are supposed to be doing, and they still boot slow.  So you call us in.  And we find (amongst other things mind you) a bug in either the firmware or driver of your storage controller card in all your desktops.

The delay looks like this:


CPU sampling is at 100% for a core, then at 15 seconds, flops to another core, and finally at the 34 second mark, it releases whatever pent up frustrations it has and things get back to normal…


So at 33.949 seconds, we successfully enumerate a PnP ID


I look up the PnP ID here to get my offender, its in the properties of the ETL trace…


Note above, storport.sys!RaDriverPnpIrp starts at .747 seconds and ends at 32.696

At 32.696, we start the storport.sys!RaidAdapterStartMiniport function…

This is a perfect example of Windows falling victim to third party code.  We cannot proceed at boot until this driver/firmware initializes, as SYSTEMROOT resides on it…

More details to follow, customer has escalated to the hardware vendors (two known OEMs so far have this component problem.


  1. Nice article. Thanks.

    I do have a question that I think might fit well here in the comment section:

    I've been looking like a maniac for the xperf binaries lately.

    I know they used to be part of the windows SDK installer, but I can no longer find xperf when I install the Windows SDK 7.1

    Is there a guide on how to install xperf from Windows SDK 7.1 anywhere?

Leave a comment

Your email address will not be published. Required fields are marked *

Exit mobile version