Freigeben über

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

  • Artikel

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

  • Anonymous
    July 01, 2015
    Thank you Aaron. Hope this finds you doing well.

  • Anonymous
    July 06, 2015
    The comment has been removed

  • Anonymous
    July 10, 2015
    The comment has been removed

  • Anonymous
    July 22, 2015
    @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.

  • Anonymous
    July 22, 2015
    The comment has been removed

  • Anonymous
    July 22, 2015
    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.

  • Anonymous
    September 21, 2015
    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.

  • Anonymous
    September 21, 2015
    Oh... and disabling the feature via Group Policy is not acceptable, as Group Policy is not a universally available Windows feature.

  • Anonymous
    December 04, 2015
    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

  • Anonymous
    February 26, 2016
    The comment has been removed

  • Anonymous
    March 08, 2016
    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.

  • Anonymous
    March 22, 2017
    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.

  • Anonymous
    May 05, 2018
    The comment has been removed