high CPU usage with Windows 10 on HP Compaq Pro 6300

[SupremeLaw]

I worked with Microsoft Customer Support for 7 hours yesterday.
Windows 10 Version 1903, OS Build 18362.175 appears incompatible with
the HP Compaq Pro 6300 Small Form Factor PC. MS technician tried
to isolate the problem, but he failed. He thinks the problem is most
likely an outdated device driver. The symptom is a very high CPU
utilization percentage, exceeding 50% all the time. The three processes
that are using the bulk of that 50% are: Service Host: Diagnostic Policy Service,
Service Host: Diagnostic Service Host, and the kernel process "ntkrnlmp.exe".
We tried to locate the latest drivers at the HP website, but the latest are
for Windows 8.1 The Technician said he is prohibited from contacting HP directly,
so I agreed to do so. This PC was purchased via Newegg from a Microsoft
Authorized Refurbisher. And, this problem only started to occur after the
Windows 10 Version 1903 update was installed.  When I cancel the 3

internal processes above, this PC's CPU utilization is still about 43%

with nothing else running except the Operating System.

[SupremeLaw]

I'm trying to troubleshoot the original problem, and in that effort I found the following:

Sleep Study CPU Usage and System Interrupts in Windows 10
https://forums.overclockers.co.uk/threads/sleep-study-cpu-usage-and-system-interrupts-in-windows-10....

[begin quote]

I know most people don't have this issue but I thought I'd post it here because I've come across it a few times now in Windows 10 and it can take a while to find an answer if you're not aware (anyone searching google hopefully).

I've come across a few PC's (Desktops and Laptops) where the CPU usage was pegged at maxing out one core and also Disk usage was constantly writing to the SSD (not good) or hard drive.

After looking into resource monitor, you can see it's the "System" and "System Interrupts" that's causing it, writing loads of information to a log file called SleepStudy/UserNotPresentSession.etl on the C drive (huge clue there!).

Turns out that if certain PC's or laptops (perhaps hardware specific) don't wake up properly or there is a powercut when it was sleeping, next time you boot the system keeps logging all the system devices that would be using power in sleep mode.

Problem is, the computer is no longer sleeping so that would be a huge amount of devices and interrupts it starts to log! Sleep study continues when the user IS present and in a fully powered up state - hence the huge logging and system interrupts being hammered.

My brother complained of a slow dual I3 series 4 desktop PC, it has literally written GBs of data to the SSD and been maxing out one core and hammering the interrupts process until I put it to sleep and woke it up again then everything was fine (shutdown/reboot didn't stop the logging)

Just a heads up as it seems this sleep study has a few bugs still in Windows 10.

[end quote]

[SupremeLaw]

[SupremeLaw]

[SupremeLaw]

Somewhat in desperation, because I had run out of options, I opened the chassis

and inspected several of the data and power connections.

I did the following:

(1)  fully seated one of the 8GB DIMM sticks: I don't think that was the problem,

because this PC was reporting the full 32GB of DDR3, with no hardware errors

detected in any of the DRAM;

(2)  an auxiliary Molex 4-pin connector was fully seated in a

USB 3.0 adapter installed in a PCIe 2.0 x1 expansion slot:

I don't think that was the problem either, because an

external Western Digital USB "Passport" external HDD

has been running AOK when connected to that adapter;

(3)  I removed 4 x 6G SATA cables from 2 x SATA backplanes,

both Icy Dock models:  one installed in the 3.5" floppy disk drive bay,

and one installed in the 5.25" optical drive bay:

Here are those two backplane enclosures at Newegg:

https://www.newegg.com/p/N82E16817994148?Item=N82E16817994148&Tpk=N82E16817994148

https://www.newegg.com/p/N82E16817994230?Item=N82E16817994230&Tpk=N82E16817994230

The backplanes of both of the latter were powered ON,

and 4 x 6G SATA cables were connected to a Highpoint

RocketRAID 2720SGL RAID controller, but no

SATA SSDs were installed in those 4 x 2.5" trays.

The primary set of 4 x SATA cables are connected

to 4 x M.2 SATA SSDs which host the Operating System

and those SSDs are obviously working AOK.

It was the secondary set of 4 x 6G SATA cables

that were connected to backplanes withOUT

SSDs installed in the corresponding drive trays.

So, my BEST GUESS now is that the 2 x Icy Dock backplanes

were generating some kind of feedback signal, which made the

2720SGL RAID controller decide that storage devices

were connected and needed to be frequently "polled"

to confirm their presence.

This faulty signal, in turn, activated some sort of

feedback into an OS kernel process that was

frequently run to respond to that faulty signal.

The latter is still only my "theory";  however,

CPU utilization during idle has returned to NORMAL,

so my original problem is now solved.

(Whew!  On a scale of 1 to 10, that was a 7 or 8.)