TR Forums

I wasn't the first one to figure this out so thanks a ton to hammong for helping me solve this! http://www.overclock.net/t/1365892/p9x7 ... an-100-mhz

There is an obscure issue with CPU-Z reporting when using HyperV role enabled Windows 8 or newer systems, regardless of chipset. I presume Windows 10 is affected but not tested it yet, will update later. When I'd enable hardware visualization in the UEFI it would cause CPUz to display wildly inaccurate data. For the longest time I thought it was a system problem (as many others appear to as well), but it appears to be a CPUZ reporting problem.

The bclock, CPU, RAM, and Uncore frequencies are all way off and will fluctuate erratically because the base clock itself bounces randomly around within a 94-97Mhz range with my ASUS Z97 Pro board.

Default CPUZ Behavior BusClock=1




CPUZ BusClock=0





In my case, enabling hardware visualization in the UEFI would cause CPUZ to go wonky as shown above, as it is required for the HyperV role to activate within Windows. It turns out as a separate issue one of my XMP profiles was not quite stable, so when I would enable hardware visualization the system would get very unstable further reinforcing my incorrect notion that this was a hardware issue.

It literally took a very specific google query with just five results listed before I found hammong's thread, hopefully this one will help spread the word about this problem to save others some grief.

Hyper-V also impacts the new Task Manager.

Without Hyper-V the Task Manager will show the dynamic changes in clock speed.

With Hyper-V the Task Manager shows the base clock speed only without any variation, which isn't what the hardware is actually doing of course.

This is because Hyper-V places the hypervisor below the OS and segments the host OS into what Microsoft calls the parent partition. The parent partition is still allowed to directly touch the hardware, but some drivers have difficulties with it.

For example for a very short while, many drivers revisions back, NVIDIA had a problem where their video driver and Optimus fell apart when Hyper-V was enabled.

CPU-Z needs to update the driver the utility uses to show us system information.

By point of comparison the Intel XTU utility is able to properly work and display CPU information through the parent partition.

The whole point of virtualization is to insulate the software from the actual hardware it is running on. It comes as no surprise that there are cases where trying to read information about the physical hardware state doesn't work quite right. Unless the virtualization tools are carefully designed to accurately virtualize all of the underlying mechanisms (e.g. hardware registers used to read current CPU clock speed), and kept up-to-date when new generations of CPUs and chipsets are released, glitches like this are probably inevitable.

Ryu Connor wrote:

Hyper-V also impacts the new Task Manager.

Without Hyper-V the Task Manager will show the dynamic changes in clock speed.

With Hyper-V the Task Manager shows the base clock speed only without any variation, which isn't what the hardware is actually doing of course.

I did not know that, thanks for the info!

Ryu Connor wrote:

CPU-Z needs to update the driver the utility uses to show us system information.

By point of comparison the Intel XTU utility is able to properly work and display CPU information through the parent partition.

They really do, the issue has been known about for 2-3 years now. Now that I know what to look for I see the same fluctuating bclock figures on other systems... it completely undermines the point and usefullness of CPU-Z when everything is 100-300Mhz off actual system speeds. I will have to give Intel's XTU a try I think.

just brew it! wrote:

The whole point of virtualization is to insulate the software from the actual hardware it is running on. It comes as no surprise that there are cases where trying to read information about the physical hardware state doesn't work quite right. Unless the virtualization tools are carefully designed to accurately virtualize all of the underlying mechanisms (e.g. hardware registers used to read current CPU clock speed), and kept up-to-date when new generations of CPUs and chipsets are released, glitches like this are probably inevitable.

To an extent, but there is no impenetrable wall. The OS still trades info with the UEFI and can even adjust processor C states while Hyper-V role is enabled. The "host" can still inject data into hyper-V "guests", even if they don't quite fit those roles under HyperV. Even the ASUS Motherboard tool can adjust system clocks and fan speeds and other hardware settings without a problem.

Of course, ASUS does not allow its software & drivers to install under Windows Server 2012 R2, so I couldn't use it in this case to double-check CPUz's system info. Another reason I'll reinstall my copy of Win 7 and upgrade to Win 10 when it is released, I am tired of brute-forcing or hacking ASUS & Intel drivers to work.

That CPU-Z has an alternate data mode that fixes this problem shows they know about it, but if they are not going to enable it by default then they need to provide a warning when detecting hyper-V enabled systems. CPU-Z is almost useless when literally the CPU speed is off by 300Mhz, the uncore by 200Mhz, and the RAM by 100Mhz. In the past I tried to "fix" those numbers and that meant I was overclocking the system without realizing it, so of course any semblance of stability went out the window when I would try to run the system at what I would perceive as stock.

And just think, x86 isn't able to pull off the greatest feat that mainframe virtualization can do: hardware virtualization of a hardware hypervisor within another instance of a hardware hypervisor. Just think of all the bugs that could introduce.

the wrote:

And just think, x86 isn't able to pull off the greatest feat that mainframe virtualization can do: hardware virtualization of a hardware hypervisor within another instance of a hardware hypervisor. Just think of all the bugs that could introduce.

Not to mention opportunities for malware authors...