yyang

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

Could you provide a work email? I'm allowed 1 PM each day...

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.

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.

The boot log file is PMed to you. Thanks!

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.

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.

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.