error message "access denied" when trying to run HWiNFO64.exe

[MagicAndre1981]

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)

• start Systeminformer as admin
• try to run "C:\Program Files\HWiNFO64\HWiNFO64.EXE" from System->run

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)

3.0.7574
Windows 10 19045.4291 or 17763.5696 (I run Win11 only in vmware so I can't test it)

[jxy-s]

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.

[MagicAndre1981]

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.

[MagicAndre1981]

ok, this also happens with Microsoft Windows Performance Recorder UI (WPRUI.exe), it also has uiAccess="true" set in the manifest.

[Almighty188]

@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/

[Almighty188]

@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!

[malikm]

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.

[jxy-s]

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.

[Almighty188]

@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.

[jxy-s]

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:

1. Choosing "Restart" for 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:
   

   systeminformer/SystemInformer/actions.c

   Lines 2426 to 2437 in ff4fc00

   	status = PhCreateProcessWin32Ex(
   	PhGetString(fileNameWin32),
   	PhGetString(commandLine),
   	environment,
   	PhGetString(currentDirectory),
   	&startupInfo.StartupInfo,
   	PH_CREATE_PROCESS_SUSPENDED | PH_CREATE_PROCESS_NEW_CONSOLE | PH_CREATE_PROCESS_EXTENDED_STARTUPINFO | PH_CREATE_PROCESS_DEFAULT_ERROR_MODE | flags,
   	tokenHandle,
   	NULL,
   	&newProcessHandle,
   	NULL
   	);

2. Starting another instance of HWiNFO64.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.

[Almighty188]

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:
#2037 (comment)