Since I’ve upgraded my system from Windows 7 to 10 on my HP ProBook 6570b with 16 gigabytes of RAM and an SSD disk, I’m experiencing a slow boot when “restarting” the computer. Windows shows a black screen with the Windows 10 logo in the middle for several seconds.
A trace capture taken with Windows Performance Recorder shows that the “Pre Session Init” boot phase, has taken 22 Seconds. Which is big duration for this phase!
So what’s going on ?
Using Region of Interest graph and choosing the “Thread Activities” view, you can see that “Boot-PnP-SystemStart-Phase” takes 20 Seconds and the Thread 8 of system process 4 and is involved in this delay.
Let’s take a look at CPU Usage Sampled Table to see what Thread 8 is doing during this amount of time;
When digging in the call stacks, you can see “IopLoadDriver” function call that load Drivers. At this point I can assume that the delay is related to driver loading operation.
So let’s move forward and look for other clues. At the bottom we can see an interesting functions calls related to the Hash validation. These functions are called from CI.dll module which is the Code Integrity Module responsible of Drivers’ signature checking at the boot phase.
We can see this more clearly in the “Generic Events” table. By expanding “ValidateFileHash” taskname under “Microsoft-Windows-CodeIntegrity” column, you can see that the Hash validation starts at 2,433540242s for “\Device\HarddiskVolume2\Windows\System32\drivers\dxgkrnl.sys” file and ends at 22,569235172s !
For all the other drivers the code integrity check operation took a few milliseconds !
So the question is; why it took so long for checking “dxgkrnl.sys” file integrity ?
dxgkrnl.sys is a Microsoft DirectX graphic driver; At the begining I thought that my dxgkrnl.sys was not up to date (10.0.10586.672), beacause I was running Windows 10 1511 version.
So I’ve applied all the latest updates for Windows 10 version 1511; the dxgkrnl.sys files version was updated to “10.0.10586.873”, but the boot time remains the same !
My next step was upgrading to Windows 10 Creator Update, whithout this solving my problem !
I’ve also the same problem on my other HP ZBook Laptop with 16 gigabytes of RAM and an SSD disk !
On the Internet many people reported this kind of issue, but none gave a definitive solution !
The story continues …
What I did next is take a trace from another Windows 10 PC which boot normally, without delay, and make a comparison between the two traces. I created a comparative window and put in the CPU Precise Graph. I drilled in the call stacks of Thread 8 and try to catch any difference between the two call stacks. And what I saw in the top of the stack seemed interesting. There are calls to functions in the Wof.sys module that are not present in the call stack of the computer without boot delay!
Wof.sys is a File System Filter Driver. And according to MSDN page https://msdn.microsoft.com/en-us/windows/hardware/drivers/ifs/what-is-a-file-system-filter-driver- ;
“A File system filter Driver is 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 when a file I/O is performed on dxgkrnl.sys file it’s intercepted by a program which try to do something with !
So pushing my curiosity further, I took another trace with the “WDF Driver Activity” option enabled.
The generic Events table shows me a new task which perform just before Dxgkrnl driver initialization. A code integrity applied vmbkmclr.sys driver.
vmbkmclr.sys is a part of Hyper-V backup integration components for VMs. Armed with this information, I made a test by uninstalling the hypervisor from my machine and now the boot time is faster !
The Pre Session Init boot phase goes from 22s down to 8s.
Now the big question is; The Hypervisor is really the culprit ? or a misconfiguration of my system ? As a reminder, I’m facing the same issue on my other windows 10 machine, with the Hyper-V service running on it.
So this is just a workaround not a definitive fix.