Cracking the Case of Slow Windows Boots: A WPT Investigation

After upgrading my HP laptop from Windows 7 to Windows 10 (16GB RAM, SSD), I noticed that the system takes an unusually long time to boot, specifically when performing a restart. During the reboot, Windows displays a black screen with the Windows 10 logo for several seconds.

To investigate, I used my go-to tool: Windows Performance Toolkit.

The trace captured with Windows Performance Recorder revealed that the “Pre Session Init” phase alone took 22 seconds, which is significantly longer than expected for this stage of the boot process.

So, what’s causing the delay?

By analyzing the Region of Interest graph and switching to the “Thread Activities” view, I found that the “Boot-PnP-SystemStart-Phase” took 20 seconds. The culprit appears to be Thread 8 of the System process (PID 4), which is heavily involved during this delay.

Let’s examine the “CPU Usage Sampled” table to see what Thread 8 was doing during this period.

While digging into the call stack, I noticed a call to the IopLoadDriver function, which is responsible for loading drivers. This suggests that the delay is likely related to a driver loading operation.

To dig deeper, I looked for additional clues—and found something interesting. Near the bottom of the stack, there are function calls related to hash validation. These calls originate from the CI.dll module, which is part of the Code Integrity system, responsible for verifying driver signatures during the boot process.

This becomes even clearer when looking at the “Generic Events” table. By expanding the ValidateFileHash task under the Microsoft-Windows-CodeIntegrity provider, I observed that hash validation starts at 2.433540242s for the file:

CopyEdit\Device\HarddiskVolume2\Windows\System32\drivers\dxgkrnl.sys

…and doesn’t complete until 22.569235172s. That’s a huge gap; almost 20 seconds, just for verifying the integrity of a single driver!

For all the other drivers, the code integrity check operation took a few milliseconds!

So, the question is: why did it take so long to verify the integrity of the “dxgkrnl.sys” file?

dxgkrnl.sys is a Microsoft DirectX graphics driver. Initially, I thought that my “dxgkrnl.sys” driver was the issue; however, I later found that it was not the driver that was outdated (10.0.10586.672) because I was running Windows 10 version 1511.

I installed all the latest updates for Windows 10 version 1511, which updated the dxgkrnl.sys file to version 10.0.10586.873—but unfortunately, the boot time issue remained unchanged.

Next, I upgraded to the Windows 10 Creators Update, hoping it would resolve the problem—but no luck there either.

Interestingly, I encountered the same issue on another HP ZBook laptop as well.

After conducting some research, I discovered that many online users have reported similar boot delays; however, none of the threads provided a definitive solution.

So, the investigation continued…

I decided to capture a trace on another Windows 10 PC that usually boots without delay and compare it with the problematic one.

Using a comparative view with the CPU Precise Graph, I examined the call stacks of Thread 8 from both traces, looking for differences.

That’s when I found something intriguing: in the problematic system’s stack, there were calls to functions within the Wof.sys module—calls that were completely absent from the stack of the system without the boot delay!

Wof.sys is a File System Filter Driver. And according to MSDN page  ;

“A File system filter Driver is an optional driver that adds value to or modifies the behavior of a file system. A file system filter driver can filter I/O operations for one or more file systems or file system volumes. Depending on the nature of the driver, filter can mean log, observe, modify, or even prevent. Typical applications for file system filter drivers include antivirus utilities, encryption programs, and hierarchical storage management systems.”

So my guess is that when a file I/O is performed on “dxgkrnl.sys” file, it is intercepted by a program which tries to do something with it!

So, pushing my curiosity further, I took another trace with the “WDF Driver Activity” option enabled in the Windows Performance Recorder Interface;

The generic Events table shows me a new task that performs just before the Dxgkrnl driver initialization. Code integrity applied to vmbkmclr.sys driver.

vmbkmclr.sys is a part of the Hyper-V backup integration components for VMs. Armed with this information, I made a test by uninstalling the hypervisor from my machine, and then the boot time was faster!

The “pre-session init” boot phase goes from 22s down to 8s.

Now, the big question remains: Is the Hypervisor the culprit, or is it simply a misconfiguration on my system?

Given that I’m experiencing the same issue on another HP laptop running Windows 10 with Hyper-V enabled, it leads me to believe that there may be something specific to HP hardware combined with Hyper-V that’s contributing to this boot delay.

If you’ve found this article helpful or insightful, feel free to share it on your favorite social media platform using the buttons below, so others who face similar issues can benefit too!