ProBook 450 with high CPU usage

[muscken]

Just for confirmation, we have n. 3 laptop g5 in the company. mine was the only one who had the problem. yesterday my colleague has updated the audio drivers and from today magically has the problem of the processor.
So i confirm that the problem is Conexant ISST Audio 

[Gary-CH]

There is an “Event Tracing for Windows” (ETW) provider that gives some insight into Windows ACPI behavior: Microsoft-Windows-Kernel-Acpi

A log of the events generated by this provider can be created (given sufficient access rights, such as those of the Administrator) by commands such as:

logman start HPbug -ets -p Microsoft-Windows-Kernel-Acpi -o x.etl

The following command stops the logging of events:

logman stop HPbug –ets

When this problem is occurring, events are logged at a very high rate and the text of the events follows this pattern:

ACPI method \_GPE._L61 has high frequency 32076

ACPI method \_GPE._L61 evaluation has started

ACPI method \_SB.PCI0.RP02._ADR has high frequency 160450

ACPI method \_SB.PCI0.RP02._ADR evaluation has started

ACPI method \_SB.PCI0.RP02._ADR evaluation has finished

ACPI method \_SB.PCI0.RP03._ADR has high frequency 160450

ACPI method \_SB.PCI0.RP03._ADR evaluation has started

ACPI method \_SB.PCI0.RP03._ADR evaluation has finished

ACPI method \_SB.PCI0.RP04._ADR has high frequency 160450

ACPI method \_SB.PCI0.RP04._ADR evaluation has started

ACPI method \_SB.PCI0.RP04._ADR evaluation has finished

ACPI method \_SB.PCI0.RP07._ADR has high frequency 160452

ACPI method \_SB.PCI0.RP07._ADR evaluation has started

ACPI method \_SB.PCI0.RP07._ADR evaluation has finished

ACPI method \_SB.PCI0.RP08._ADR has high frequency 160455

ACPI method \_SB.PCI0.RP08._ADR evaluation has started

ACPI method \_SB.PCI0.RP08._ADR evaluation has finished

ACPI method \_SB.PCI0.RP10._ADR has high frequency 160455

ACPI method \_SB.PCI0.RP10._ADR evaluation has started

ACPI method \_SB.PCI0.RP10._ADR evaluation has finished

ACPI method \_SB.PCI0.RP11._ADR has high frequency 160527

ACPI method \_SB.PCI0.RP11._ADR evaluation has started

ACPI method \_SB.PCI0.RP11._ADR evaluation has finished

ACPI method \_GPE._L61 evaluation has finished

ACPI method \_GPE._L61 has high frequency 32077

ACPI method \_GPE._L61 evaluation has started

 GPE is a General Purpose Event and L61 is a Level-triggered event 0x61

SB is the System Bus, PCI0 is a PCI branch of the namespace and RPxx is Root Port xx.

Devmgmt.msc on my ProBook shows (under System devices):

So the Root Ports being hit at a high rate are those where no device is attached. It seems that a level triggered event remains in the triggered state and is not cleared.

The Root port assignments on my device are:

\_SB.PCI0.RP01.PXSX NVIDIA display adapter

\_SB.PCI0.RP05.PXSX Realtek network adapter

\_SB.PCI0.RP06.PXSX Intel network adapter

\_SB.PCI0.RP09.PXSX Standard storage controller

\_SB.PCI0.RP12.PXSX Realtek PCIE CardReader memory technology device

The ACPI name of a device can be viewed on the details tab of the device (as the property BIOS device name):

 

Also useful (see later in this message) is the “Device instance path”:

 

The tip from this forum about “rescanning for hardware changes” is useful – a quick look at devcon.exe with a debugger and disassembling devcon!cmdRescan shows that its implementation is very simple. The following C# implements (more or less) the same functionality:

using System;

using System.Linq;

using System.Runtime.InteropServices;

class A

{

    static int Main(string[] args)

    {

                try

                {

                    if (CM_Locate_DevNode(out uint devinst, args.FirstOrDefault(), 0) == 0) Console.WriteLine(CM_Reenumerate_DevNode(devinst, 0));

                }

                catch (Exception ex)

                {

                    Console.Error.WriteLine(ex);

                }

                return 0;

    }

    [DllImport("cfgmgr32.dll", CharSet = CharSet.Unicode)]

    static extern int CM_Locate_DevNode(out uint devinst, string device, uint flags);

    [DllImport("cfgmgr32.dll")]

    static extern int CM_Reenumerate_DevNode(uint devinst, uint flags);

}

Scan for new hardware usually uses null for the device name, but actual device names (actually Device instance paths) can be used to limit the extent of the scan. Without command line arguments, this program also uses null and this usually clears the problem for me. I also tried using the device path "ACPI\PNP0A08\0" (the System device with the friendly name “PCI Express Root Complex”) and this works too. More interestingly, I tried the paths of the five devices mentioned above and only the “Realtek PCIE CardReader” has any effect (in fact, it has always worked for me).

Tracing the full set of ACPI events during a hibernate/resume (and assuming that the problem occurs – it does not always (or even often) happen to me), also hints that it is the device at RP12 that causes the GPE to be left high. The kernel debugger command “!amli dns /s \_SB.PCI0” suggests that there are Root Ports named RP01 to RP20, but I have never seen anything above RP12 in the ETW traces.

A snapshot of the stack of the ACPIWorkerThread that is consuming the CPU when the problem occurs looks like this:

Child-SP          RetAddr           Call Site

ffffca8b`219326a0 fffff807`ef2c457a ACPI!GetNameSpaceObject+0xac

ffffca8b`21932780 fffff807`ef2c5a9c ACPI!ParseAndGetNameSpaceObject+0x4a

ffffca8b`219328f0 fffff807`ef2c5f73 ACPI!ParseNameObj+0x34

ffffca8b`21932930 fffff807`ef2c4725 ACPI!ParseOpcode+0x14b

ffffca8b`21932970 fffff807`ef2c6a08 ACPI!ParseArg+0x13d

ffffca8b`219329b0 fffff807`ef2726ca ACPI!ParseTerm+0x178

ffffca8b`21932a10 fffff807`ef2bbce1 ACPI!RunContext+0xee

ffffca8b`21932a70 fffff807`ef2b3052 ACPI!DispatchCtxtQueue+0x91

ffffca8b`21932aa0 fffff800`630f2ae7 ACPI!ACPIWorkerThread+0x102

ffffca8b`21932b10 fffff800`631b0b86 nt!PspSystemThreadStartup+0x47

ffffca8b`21932b60 00000000`00000000 nt!KiStartSystemThread+0x16

A quick look at https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Architecture might explain the names of some of these routines.

The ACPI specification can be downloaded from http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf, but at over 1100 pages it is not easy to digest.

The specification, coupled with the extensive ETW tracing and Windows kernel debugging extensions provide more than enough material for further troubleshooting. In the meantime, reports of any results of rescanning individual device paths when the problem occurs would be welcome.

[Johnny_W]

---

@ju1c3wrote:

---

@Johnny_Wwrote:

HP has now informed me, that I would have to wait until the end of May, because HP and Microsoft are working on the problem.

---

They actually said this? Do you have a ticket we can refer to so I can pass it along to our HP rep to ask about? 

---

Here is the original mail from HP Germany with ticket No:

bezüglich der Störungsmeldung: 5012978170, haben wir die Dateien analysiert.

 

Bitte schalten Sie in BIOS Fast Boot aus. Testen Sie es, wenn es immer nicht richtig funktioniert bitte schalten Sie das "Schnell Boot" in Windows aus.

Der Fehler ist bei Microsoft bekannt, und Microsoft arbeitet an der Lösung.

 

Bei Fragen erreichen Sie uns telefonisch unter den Hotline-Nummern in der Fußnote oder schriftlich, indem Sie diese E-Mail beantworten. Um auf diese E-Mail zu antworten klicken Sie einfach auf die Antwortfunktion Ihres E-Mail Programms. Bitte ändern Sie nichts an der Adresse bzw. am Betreff.

 

Für Ihre Mühe bedanken wir uns und verbleiben

 

mit freundlichen Grüßen,

 

HP Computing Support  

[Chocholous]

My support recommended me to install new version Windows (1803). But same behaviour here - problem still persists. I tried also newer Conexant audio from Windows Catalog Update (9.0.196.50) - problem still persists.


Seems that information about this case isn't shared inside HP. Germany's support has some more information than I've received some days ago. HP is a terrible company :-(.

[ju1c3]

Out of curiousity, if you guys go to task manager and kill flow.exe and then kill mictray64.exe does your processor drop off? I've got that to work a few times for me now. 

[ju1c3]

I've renamed MicTray64.exe in c:\windows\system32 and haven't had it break since. It's going on 2 days now so I wont say that the problem is fixed. Just looking for other datapoints. 

[ArtemSnezhny]

---

@ju1c3wrote:

I've renamed MicTray64.exe in c:\windows\system32 and haven't had it break since. It's going on 2 days now so I wont say that the problem is fixed. Just looking for other datapoints. 

---

Probably it helps with problem caused by flow.exe process. For me this did not solve the high CPU usage by ACPI.

[Pat93]

How to solve the high CPU usage (by ACPI):

As an Administrator

Right click on the Power (battery) icon in the notification area, at the far right of the taskbar (on desktop), click on Power options.

Click on Change when the computer sleeps.

Click on Change advanced power settings.

Expand PCI express.

Expand Link sate power management.

On battery, open the drop down menu, select Off.

Plugged in, open the drop down menu, select Off.

Click on Apply and OK.

Restart the computer.

It is not the best configuration for power savings but it works !

Now, you can use sleep modes and turn on Fast startup.

The "System" process will be around 1%.

Hope this helps.

Pat

[ArtemSnezhny]

Thank you for help! But...

it does not work. I've been using these settings for a long time, and the problem still exists.

[JK80]

In the Microsoft Update Catalog is a new version available. It is 9.0.203.0 from 09.05.2018. Can some of you try it? At my HP 450 G5 with Windows 10 1803 it looks very promising.