-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
error message "access denied" when trying to run HWiNFO64.exe #2037
Comments
The cause of this is the driver protecting System Informer. The following If I specifically craft a driver to omit that process the problem goes away: I did some digging into the <?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 <?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 Maybe we could come up with a way to invoke The workaround for now, if you want to invoke a An alternative would be getting |
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 |
@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/ The OSD feature is mentioned here: What you need to do is per Microsoft as seen here and confirmed by HWiNFO's author: 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 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\ |
@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 The workaround then is to disable and unload the driver |
@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:
To confirm, you mean right clicking the Few observations on my end:
|
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: |
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)
The text was updated successfully, but these errors were encountered: