Jump to content

High CPU caused by powershell.exe during screen lock


Recommended Posts

With ESET Internet Security 17.1.11.0 on my Windows 11 laptop, powershell.exe is almost always automatically launched in the background during screen lock. This is similar to what's reported here and here.

WPR shows the command line:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NonInteractive -Command if (((Get-AppxPackage -Name 'EsetContextMenu').length -ne '1') -Or ((Get-AppxPackage -Name 'EsetContextMenu').version -ne '10.43.27.0')) { Get-AppxPackage -Name 'EsetContextMenu' | Remove-AppxPackage; Add-AppxPackage -Path 'C:\Tools\ESET\EsetContextMenu.msix' -ExternalLocation 'C:\Tools\ESET\' }

It seems that the culprit is Get-AppxPackage -Name 'EsetContextMenu').version -ne '10.43.27.0'. If I execute this line manually, the reported package version is 17.1.11.0, as expected. So this command checks the wrong version number and performs package removal and installation again and again.

By the way, a raw string search shows that quite a few .exe and .dll files in the ESET installation directory happen to contain 10.43.27.0, including ekrn.exe, egui.exe, shellExt.dll, etc.

A workaround would be highly appreciated.

Edited by yyang
Link to comment
Share on other sites

  • Administrators

Please raise a support ticket. Integration in the context menu should be performed only once during installation.

Link to comment
Share on other sites

Posted (edited)

Thanks! Ticket submitted. I'll leave this open for the time being, and post the solution for other users to see.

By the way, on my laptop with a brand new installation of Windows 11 Simplified Chinese Edition, the context menu is still broken, in the same manner as shown by @TOM111 here.

Edited by yyang
Link to comment
Share on other sites

  • Administrators

I'd like to have a look into it so please provide:
1, The output of running the command:
Get-AppxPackage -Name "Eset*"

2, A Procmon boot log.

Link to comment
Share on other sites

Thanks again! The package info:

RunspaceId             : af3c5853-c924-4d3e-8b89-fbe60713791c
Name                   : EsetContextMenu
Publisher              : CN="ESET, spol. s r.o.", O="ESET, spol. s r.o.", L=Brati
                         slava, C=SK, SERIALNUMBER=31333532, OID.2.5.4.15=Private
                          Organization, OID.1.3.6.1.4.1.311.60.2.1.3=SK
PublisherId            : f55j32bkf4yvt
Architecture           : Neutral
ResourceId             :
Version                : 17.1.11.0
PackageFamilyName      : EsetContextMenu_f55j32bkf4yvt
PackageFullName        : EsetContextMenu_17.1.11.0_neutral__f55j32bkf4yvt
InstallLocation        : C:\Program Files\WindowsApps\EsetContextMenu_17.1.11.0_n
                         eutral__f55j32bkf4yvt
IsFramework            : False
PackageUserInformation : {}
IsResourcePackage      : False
IsBundle               : False
IsDevelopmentMode      : False
NonRemovable           : False
Dependencies           : {}
IsPartiallyStaged      : False
SignatureKind          : Developer
Status                 : Ok

I can reboot my machine and add the boot log in about an hour.

Link to comment
Share on other sites

  • Administrators

The Procmon log didn't show high CPU utilization. Are you able to reproduce it when running the following command as an administrator?

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NonInteractive -Command if (((Get-AppxPackage -Name 'EsetContextMenu').length -ne '1') -Or ((Get-AppxPackage -Name 'EsetContextMenu').version -ne '10.43.27.0')) { Get-AppxPackage -Name 'EsetContextMenu' | Remove-AppxPackage; Add-AppxPackage -Path 'C:\Tools\ESET\EsetContextMenu.msix' -ExternalLocation 'C:\Tools\ESET\' }

Is there any reason why ESET is installed in C:\tools instead of C:\Program Files?

Link to comment
Share on other sites

Posted (edited)

The installation directory is my long-time preference for a reasonably short and no-space-in-between path. Almost all my non-"green" programs are installed under C:\Tools if there is a choice. It works fine for decades.

As far as I can tell, this issue only appears about 30s after the screen is locked (when the fan starts to spin, as also confirmed by a couple of WPR recordings). The boot log can help to investigate the context menu issue, I suppose.

As reported above, (Get-AppxPackage -Name 'EsetContextMenu').version equals 17.1.11.0 on my machine. So we can be certain that the package will be removed and installed in vain, right?

I can provide a WPR recording for my lock-screen use case, if that's helpful. You can clearly see the CPU spikes caused by powershell.exe and the package management service.

Edited by yyang
Link to comment
Share on other sites

  • Administrators

I've checked the logs but didn't find any signs of high CPU utilization. However, it took quite long to run powershell although all particular operations were finished quickly. The speed may be affected by Microsoft Store since a check of the installation status of the UWP application EsetContextMenu.msix is queued, however, that wasn't probably the case according to the Procmon log.

If you can reproduce high CPU utilization by running the above Powershell command, please carry on as follows:

  1. Enable advanced operating system logging under Tools -> Diagnostics -> Advanced logging in the advanced setup
  2. Stop logging after 30--60s
  3. Collect logs with ESET Log Collector and upload the generated archive to a safe location (e.g. OneDrive, Dropbox,...) and drop me a personal message with a download link.

 

Link to comment
Share on other sites

Posted (edited)

Hi, I have to say that I don't expect the boot log to contain high CPU info. It only occurs after the screen is locked.

Would you accept a WPR recording? I can generate one quickly. That reflects my lock-screen use case, not manually executing the powershell command.

I believe the key is why and under what condition the powershell process is launched. Why does it insist on 10.43.27.0, instead of the obviously correct 17.1.11.0? And if this behavior can be disabled, everything will be fine.

Edited by yyang
Link to comment
Share on other sites

  • Administrators

We should run powershell only when the computer starts. Please provide a WPR recording for perusal.

Link to comment
Share on other sites

  • Administrators

You can upload the file to a safe location, such as Google Drive, OneDrive, Dropbox, etc. and drop me a private message with a download link.

Link to comment
Share on other sites

Posted (edited)

I just realize that I can reply to the previous PM without exceeding the PM quota. Sorry!

Edited by yyang
Link to comment
Share on other sites

  • 2 weeks later...
Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...