Open MagicAndre1981 opened 5 months ago
The cause of this is the driver protecting System Informer. The following svchost.exe
process requires excessive permissions to the protected process in order to create the process.
If I specifically craft a driver to omit that process the problem goes away:
I did some digging into the HWiNFO64
application manifest and it turns out they have uiAccess="true"
.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"
xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<assemblyIdentity name="HWiNFO64" processorArchitecture="amd64" version="1.0.0.0" type="win32"></assemblyIdentity>
<description>HWiNFO64</description>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls"
version="6.0.0.0" processorArchitecture="amd64" publicKeyToken="6595b64144ccf1df"
language="*"></assemblyIdentity>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="true"></requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
<asmv3:application xmlns="urn:schemas-microsoft-com:asm.v3">
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
<ms_compatibility:compatibility
xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1"
xmlns="urn:schemas-microsoft-com:compatibility.v1">
<ms_compatibility:application
xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1">
<ms_compatibility:supportedOS
xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1"
Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"></ms_compatibility:supportedOS>
<ms_compatibility:supportedOS
xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1"
Id="{1F676C76-80E1-4239-95BB-83D0F6D0DA78}"></ms_compatibility:supportedOS>
<ms_compatibility:supportedOS
xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1"
Id="{4A2F28E3-53B9-4441-BA9C-D69D4A4A6E38}"></ms_compatibility:supportedOS>
<ms_compatibility:supportedOS
xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1"
Id="{35138B9A-5D96-4FBD-8E2D-A2440225F93A}"></ms_compatibility:supportedOS>
<ms_compatibility:supportedOS
xmlns:ms_compatibility="urn:schemas-microsoft-com:compatibility.v1"
Id="{E2011457-1546-43C5-A5FE-008DEEE3D3F0}"></ms_compatibility:supportedOS>
</ms_compatibility:application>
</ms_compatibility:compatibility>
</assembly>
The same behavior happens with osk.exe
:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Copyright (c) Microsoft Corporation -->
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="*"
name="Microsoft.windows.osk"
type="win32"
/>
<description>OSK</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="true"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
I am not going to fix this in the driver. The protections are working as intended. I am unsure if Microsoft should be protecting that appinfo.dll
svchost.exe
process. The appinfo.dll
svchost.exe
is requesting PROCESS_DUP_HANDLE
and PROCESS_CREATE_PROCESS
when uiAccess="true"
. This seems like it intends to carry out the work to create the process and attach it to the parent. We leverage the protected process boundary to mitigate leaking of those types of handles where they shouldn't be. Since that svchost.exe
process isn't protected - we deny those permissions. I don't think any of that matters, as interesting as it might be, the driver is doing the right thing here.
Maybe we could come up with a way to invoke ShellExecuteEx
from another System Informer process that isn't being actively protected.
The workaround for now, if you want to invoke a uiAccess="true"
process via the Run dialog in System Informer - do it when the driver isn't active.
An alternative would be getting HWiNFO64
to remove the uiAccess = "true"
from their manifest. Although that might not be possible depending on their requirements.
thanks for locking into it. I compared the manifests for 7.72 and 8.00 and here it was changed so this triggered the issue.
ok, this also happens with Microsoft Windows Performance Recorder UI (WPRUI.exe), it also has uiAccess="true"
set in the manifest.
@MagicAndre1981 - This issue started with HWiNFO v7.73-5370 and all newer builds which is mentioned here due to the new OSD feature: https://www.hwinfo.com/forum/threads/hwinfo-v7-73-5370-beta-released.9513/ and in the following thread: https://www.hwinfo.com/forum/threads/hwinfo-v7-73-5380-beta-released.9537/
The OSD feature is mentioned here: https://www.hwinfo.com/forum/threads/hwinfo-osd.9495/
What you need to do is per Microsoft as seen here and confirmed by HWiNFO's author: https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations
This policy setting enforces the requirement that apps that request running with a UIAccess integrity level by marking UIAccess=true in their app manifest must reside in a secure location on the file system. Relatively secure locations are limited to the following directories:
C:\Program Files\ including subdirectories C:\Windows\system32\ C:\Program Files (x86)\ including subdirectories for 64-bit versions of Windows
Even the autostart feature did not work until the fix was when autostart is enabled, it would create a HWiNFO64Launcher.exe file which would open HWiNFO64.exe. When autostart is disabled, it would delete HWiNFO64Launcher.exe.
I am currently running HWiNFO64.exe v8.01-5420 under systeminformer-3.0.7578-canary:
I just noticed you do have it under C:\Program Files\ I just tried restarting the HWiNFO64.exe process in SI and it seems like the process gets killed but does not start the process. Maybe starting a thread on the hwinfo forums might help even though I just mentioned it on https://www.hwinfo.com/forum/threads/hwinfo-v8-01-5420-beta-released.9656/
@jxy-s - When you said "The workaround for now, if you want to invoke a uiAccess="true" process via the Run dialog in System Informer - do it when the driver isn't active." - Do you mean using System -> Run as... and then checking the "Create UIAccess" box? How do specify the start in folder so it will read the .ini file from the correct place?
Thanks!
Problem is that applications with uiAccess=true cannot be started via CreateProcess (or similar) but require ShellExecute. That's why HWiNFO64 is now using a HWiNFO64Launcher.exe to start from TaskScheduler.
The issue is launching the HWiINFO
via the System Informer System > Run...
(which uses ShellExecuteEx
) with the driver enabled System > Options > Enable kernel-mode driver
. The issue only presents itself when the driver is enabled since we strip handle permission from the appinfo.dll
svchost.exe
process. Without the driver enabled there is no issue.
The workaround then is to disable and unload the driver System > Options > Enable kernel-mode driver
and stop the KSystemInformer
service.
@jxy-s - I am on Windows 11 Beta Insiders and my System > Options > Enable kernel-mode driver has always been unchecked and I don't have the KSystemInformer service running but I still have the same problem as the OP.
Oh sorry, I missed this line:
I just tried restarting the HWiNFO64.exe process in SI and it seems like the process gets killed but does not start the process.
To confirm, you mean right clicking the HWiNFO64.EXE
process and choosing "Restart"? Or do you mean starting a second instance of HWiNFO64.EXE
?
Few observations on my end:
HWiNFO64.EXE
works for me with or without the driver enabled. The process exists and the new process takes its place. Looks to succeed here and not take the ShellExecuteEx
path:
https://github.com/winsiderss/systeminformer/blob/ff4fc005c3f7ecf8b7df5fcdc6e52db13ea1359c/SystemInformer/actions.c#L2426-L2437HWiNFO64.EXE
. The program seems to detect that another instance is running and exits. Same behavior as if you were to start it any other way.I meant right clicking the HWiNFO64.EXE process and choosing "Restart".
It seems to start correctly this time but didn't when I wrote my earlier reply here: https://github.com/winsiderss/systeminformer/issues/2037#issuecomment-2073495523
Brief description of your issue
error message "access denied" when trying to run HWiNFO64.exe.
But I was able to run it in the past and when I copy/paste it to windows run dialog I get the UAC prompt and the application runs fine.
Steps to reproduce (optional)
Expected behavior (optional)
I can start HWiNFO
Actual behavior (optional)
I get error message "access denied"
ProcMon show no
access denied
only this:HWiNFO can be started fine from ProcExp
Environment (optional)