LUA Buglight 2.3, with support for Windows 8.1 and Windows 10


LUA Buglight is a utility for identifying admin-permissions issues (a.k.a., “LUA bugs“) in desktop applications. That is, it identifies the specific reasons that a particular application works only when run with administrative rights. Version 2.3 is attached to this blog post and adds support for Windows 8.1, Windows Server 2012 R2, and Windows 10.

It has been well-established for many years that for security and reliability reasons, users should log on with standard user rights and that their applications should not require administrative rights.  Windows Vista began the movement toward making that the default for Windows.  Although Windows Vista and Windows 7 include technologies to help applications that had required administrative rights on earlier versions of Windows to run correctly with standard user rights, many users and organizations “solved” their application compatibility issues by disabling User Account Control (UAC) and continuing to run with full administrative rights.  Windows 8.x and Windows 10 increasingly depend on features that are absent when UAC is disabled, so the “never notify” Control Panel slider option that used to disable UAC now sets the “silent elevation” option and keeps UAC enabled.  That means that unless apps specifically request elevation, they’ll run with standard user rights, and continuing to run everything with full administrative rights will become more difficult and inconvenient.  LUA Buglight can help you identify the causes for many of the compatibility issues and point to solutions.  (See below for some solutions.)

To test an application, you must be logged on as a member of the Administrators group and with UAC enabled. (*)  Run LuaBuglight.exe without elevation.  Specify the executable to test, any command line parameters, and the starting directory, and click Start.  LUA Buglight prompts for elevation and then starts the target application.  Run the program and test all functional areas of interest.  When done testing, click the Stop Logging button.  LUA Buglight will display a tabbed report showing issues that it found.  (As noted in the “LUA bugs” link above, just because an “access denied” is recorded doesn’t mean there’s a bug that needs to be fixed!)

LUA Buglight works by instrumenting the program being tested, intercepting hundreds of API entry points.  LUA Buglight runs the target program with standard-user rights.  When it detects an API failing with “access denied” or “privilege not held”, it impersonates the user’s admin/elevated token (obtained when it prompted for UAC elevation) and repeats the operation before returning control back to the program.  If the API call failed with standard user rights and succeeded with administrative rights, LUA Buglight logs details about the API call, including all parameters of interest and the call stack. (**)

Admin permissions are one cause of application compatibility problems.  The prioritized list of preferred solutions for app-compat issues goes along these lines:

  1. Retire or replace the app
  2. Get an updated version of the app that fixes the issues from the app owner (i.e., the vendor or your developers)
  3. Modify the installer via transforms or post-install scripts (for “run-once” issues where the app needs to be executed with admin rights only the first time it is run). Another option is to add junctions or directory symbolic links.
  4. Let UAC file/registry virtualization do its magic.  (For older apps where file/reg virtualization would work, but were rebuilt with newer versions of Visual Studio, which adds an embedded manifest that declares compatibility with UAC and turns off virtualization.)
  5. For writes to .ini files in protected directories, use an IniFileMapping redirection; for writes to HKCR, pre-create equivalent keys under HKCU\Software\Classes..
  6. Apply application-compatibility shims.  (For some types of shims, this can be moved up ahead of #4.)
  7. Surgically change permissions on files, directories, registry keys, or other objects.  (Unlike the previous six options, this one introduces risk of unauthorized elevation of privilege, so caution is required.)

Note that automatic-elevation products are not on this list.  I recommend against their use.

Here’s some additional tips I wrote a few years ago about using LUA Buglight.

(*)  LUA Buglight should still work with Windows XP and Windows Server 2003, but I haven’t tested to verify that recently.  On those pre-UAC platforms, run LUA Buglight as a standard user; you will be prompted to enter the credentials of a separate administrative account.

(**)  LUA Buglight can capture symbol information as part of the call stack, but it doesn’t support use of symbol servers, so symbol files must already be downloaded and the _NT_SYMBOL_PATH variable must point to the symbol directory.

 

LuaBuglight.zip

Comments (12)

  1. Allen Weise says:

    Thank you Aaron. Hope this finds you doing well.

  2. Eddy Current says:

    LUA Buglight CAN'T work on Windows XP/2003: you built it with for Windows and Subsystem version 6.0, see

    DumpBin /Headers, so CreateProcess() returns error 193 "invalid Win32 application"

    [Aaron Margosis] Good catch – thanks. I built it with a newer version of Visual Studio, which must have automatically updated that build setting.  OK, then, no more support for Windows XP or Server 2003.

  3. Anon says:

    Is there any way to detect and determine why an application is being detected as an installer?

    More importantly, has anyone at Microsoft investigated ditching the idiotic "Installer Detection" BS? It is constantly breaking our application on networked systems.

  4. Grim Reaper says:

    @Anon: [redacted]

    Both technet.microsoft.com/…/jj574202.aspx and technet.microsoft.com/…/dd835540.aspx tell how installer detection worls.

    And technet.microsoft.com/…/dd835564.aspx tells how to disable it, since NINE long years!

    [Aaron Margosis] Mr. Reaper: Thanks for providing those links.  Name-calling is unnecessary and unprofessional, and I won't allow it on this blog. I've edited out that part of your response.

  5. Grim Reaper says:

    It's your blog.

    JFTR: what is "idiotic … BS"?

    [Aaron Margosis] I don't agree with his assessment of installer detection either, but there's a difference between saying insulting things about a technical feature and saying insulting things about a person.

    BTW, Anon, you should be able to avoid installer-detection by ensuring that your executable has an embedded manifest with a requestedExecutionLevel.

  6. Grim Reaper says:

    People who are unable to search a manufacturers well-known site to find the information they miss, but instead just rant about it without substance, are unprofessional, and of course clueless. I dare to say that.

  7. Anon says:

    Embedding a manifest isn't disabling it. Instead, the application crashes when Installer Detection attempts to force-elevate and is blocked by the manifest.

    We fixed the problem once by removing all references to setup/install/etc., but Installer Detection recently began detecting our non-installer as an installer again.

    Since no one has ever provided a working solution, we'll just continue forcing customers to disable Windows security features and directing them toward MS support when something goes wrong.

    [Aaron Margosis] Can you send an example?

    [Aaron Margosis] What you're describing doesn't make sense. The manifest won't block elevation – it just states whether elevation is required.

  8. Anon says:

    Oh… and disabling the feature via Group Policy is not acceptable, as Group Policy is not a universally available Windows feature.

  9. Eddy Current says:

    Group Policies only set well-known and well-documented registry entries, like technet.microsoft.com/…/dd835564.aspx

    Nobody prevents you from setting these yourself in EVERY edition of Windows: per .REG or .INF, per REG.EXE or REGEDIT.EXE, …

    Also well-known and well-documented is the environment variable __COMPAT_LAYER which might contain the string "RunAsInvoker". See MSKB 286705 MSKB 317510

  10. rajivharris2 says:

    This is a very good tool. Can this program be launched from command line by passing the required parameters?

    [Aaron Margosis] Sorry, no.

  11. John Wygonski says:

    Can this utility detect issues in a legacy DLL that my app calls into? The DLL resides in the same folder as the app, if that helps.

    [Aaron Margosis] Sorry for the delay in responding – when they changed the blog platform I stopped getting notifications about pending comments.
    Yes, if the DLL you’re calling runs into permissions issues where it works only with admin rights, LUA Buglight should be helpful.
  12. Neil says:

    Hi Aaron, I have some results from using Buglight in a W10 Pro environment that I wonder if you wouldn’t mind helping me to understand?

    [Aaron Margosis] Sure, post them here.
Skip to main content