Re: [PATCH] gdb/Windows testsuite: Avoid "bad" words in exe names

[Eli Zaretskii <eliz@gnu.org>]

> From: Pedro Alves <pedro@palves.net>
> Date: Thu,  9 Jul 2026 18:43:51 +0100
> 
> Running gdb.base/execl-update-breakpoints.exp on Windows 11 shows this
> FAIL:
> 
>  (gdb) run
>  Starting program: .../gdb.base/execl-update-breakpoints/execl-update-breakpoints1.exe
>  Error creating process .../gdb.base/execl-update-breakpoints/execl-update-breakpoints1.exe (error 740): The requested operation requires elevation.
>  (gdb) FAIL: gdb.base/execl-update-breakpoints.exp: runto: run to main
> 
> Error 740 is ERROR_ELEVATION_REQUIRED.
> 
> Turns out that Windows has an "installer detection" heuristic that
> refuses to launch executables whose filename contains keywords like
> "update", "setup", and "install" without elevation (admin rights),
> unless the PE embeds a manifest declaring
> requestedExecutionLevel="asInvoker".
> 
> I found some older Microsoft documentation claiming that the heuristic
> only applies to 32-bit binaries, but what I observe is that:
> 
>  - It triggers with 64-bit PEs on current Windows.
> 
> And also:
> 
>  - Matches the word (e.g. "update") as a substring anywhere in the
>    filename (not just as a prefix).
> 
>  - Is not drive-dependent.  I thought moving the process to a dev
>    drive might suppress the check, but it does not.

Yes, this happens on 64-bit Windows as well.

> I saw this problem first in a downstream ROCgdb testcase, and there I
> fixed it by adjusting the name of that particular testcase.
> 
> Since this is the second case I'm seeing this already, I thought I'd
> fix it in a more general way this time, one that avoids adding the
> same explanatory comment to several testcases.
> 
> Fix it by making standard_testfile tweak the resulting "binfile"
> output variable to avoid the "bad" words, on Windows.  This way, in
> theory we only need to handle this once, in a central place.

Note that IME, not only programs literally called "install.exe",
"update.exe" etc. are blocked, but also programs whose name begins
with these words.  For example, I had problems with the Texinfo's
install-info.exe.

> +    if {[is_windows_based_target]} {
> +	# Windows' installer detection heuristic refuses to launch
> +	# executables whose name contains the following words without
> +	# elevation, failing with ERROR_ELEVATION_REQUIRED (740).
> +	#
> +	# Map of WORD => REPLACEMENT.
> +	set word_map {
> +	    "update" "up_date"
> +	    "setup" "set_up"
> +	    "install" "inst_all"
> +	}
> +	set binfile_basename [string map $word_map $testfile]
> +    } else {
> +	set binfile_basename $testfile
> +    }
> +    set binfile [standard_output_file ${binfile_basename}]

FTR, another way of overcoming this is by providing a manifest file.
Below is an example of such a manifest I use for patch.exe.  The
manifest must be named PROGRAM.exe.manifest and should be in the same
directory as the executable.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity version="7.95.0.0"
     processorArchitecture="X86"
     name="patch.exe"
     type="win32"/>
  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
	<requestedExecutionLevel
	    level="asInvoker"
	    uiAccess="false"/>
      </requestedPrivileges>
    </security>
  </trustInfo>
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 
  <application> 
  <!-- Windows Vista -->
  <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
  <!-- Windows 7 -->
  <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
  <!-- Windows 8 -->
  <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
  <!-- Windows 8.1 -->
  <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
  <!-- Windows 10 -->
  <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
  </application> 
  </compatibility>
</assembly>