LUA Buglight public [pre]-release


LUA Buglight™ is a tool I’ve been working on that is designed to help both developers and IT Pros (sysadmins) identify the specific causes of “LUA bugs” in desktop applications running on Windows XP, Windows Server 2003, or Windows Vista.  Once the specific causes have been identified, the bugs can more easily be resolved by fixing the app’s source code, or by making configuration changes, allowing the app to work correctly for non-admin users.

I have written a number of pieces about LUA bugs and how to fix them (see list below).  The problem has been that before you can fix them, you need to identify them.  The available tools for doing so have been lacking.  LUA Buglight exists to try to solve that problem.

LUA Buglight remains a work in progress, but you can download the current version here.  The download is a .zip file containing a self-extracting executable that simply extracts its contents to a folder of your choosing.  Those contents include a 34-page Word document — please read it.  It should answer many of your questions.

One important note:  not every item that appears in the output indicates a bug that needs to be remediated!  Before making any system changes, please refer to the following guidance:

What is a “LUA Bug”?  (And what isn’t a LUA Bug?)
Not every “access denied” indicates a LUA bug!
http://blogs.msdn.com/aaron_margosis/archive/2006/02/06/525455.aspx

Fixing “LUA bugs”, Part I
A systematic approach for working around LUA bugs that avoids unnecessary exposure
http://blogs.msdn.com/aaron_margosis/archive/2006/02/16/533077.aspx

Fixing “LUA bugs”, Part II
A systematic approach for working around LUA bugs that avoids unnecessary exposure – the “rest of the story”
http://blogs.msdn.com/aaron_margosis/archive/2006/03/27/562091.aspx

Changing Access Control on Folders vs. Files
More info on the risks of changing access control lists to fix LUA bugs.
http://blogs.msdn.com/aaron_margosis/archive/2006/06/19/638148.aspx

I’ll write more about LUA Buglight in the near future.

[Updates:   Oct 2006 MSDN webcast; and Feb 15 2007 LUA Buglight updated information]

Update, November 6, 2008:  LUA Buglight 2.0 Second Preview is now available here.  Removing 1.0 from the download.

Comments (45)

  1. This morning on a computer I was setting up I was in Administrator mode…. and I plugged in a SANDISK…

  2. Gabriel Friedmann says:

    It appears the the Local Adminsitrator account must really be a Local Account.  The ability to use a domain account that is an admin would be helpful.

    I agree.  Due to time limitations, I ended up prioritizing a lot of other stuff ahead of it (like writing documentation :-).

    — Aaron

  3. Hi SusanI was hoping to get your thoughts on our current situation. I work within the _____ industry….

  4. A few weeks ago I bought a copy of Nobeltec's Tides and Currents software. Nobeltec is a subsidiary

  5. L’outil d’identification de dysfonctionnements liés à l’absence de privilèges est disponible depuis le…

  6. flipdoubt says:

    My app uses a component that writes to an .INI file in C:Windows. Using runas to run the app as a non-admin, these settings are not persisted. When I look at directory permissions on the C:Windows directory, Users only have read. Yet when I run the app under BugLight as a member of the Users group, I the settings are persisted to the .INI file.

    1. Should Users be able to write to C:Windows?
    2. Why was my .NET app unable to write on its own but was able to write when run using BugLight?

    1.  Users cannot (with default settings) write to .ini files in the Windows folder.
    2.  LUA Buglight is a diagnostic/testing utility that grants the tested application the necessary admin rights in order to get through LUA bugs (such as trying to write to a .ini file in the Windows folder), and logging each occurrence that admin privileges were required to complete an operation.  You can then use this information to determine ways to fix the app and/or to configure the system so that the app works for non-admin users.  See this blog’s Table of Contents for the series of posts about how to fix these kinds of issues.

    HTH

    — Aaron

  7. flipdoubt says:

    Thanks for your response, Aaron, and thanks for the great utility. My only criticism is born out by my previous question: my app ran without error and LUA BugLight logged that a file was written to the Windows directory, which gave me the impression that this is OK. Which is why I asked the question, because my belief is that this is a no no.

    As to how to fix these issues, the writing to the Windows directory is done by a component, Pixel Translations’ ezImage toolkit, so I’m not sure that I have much control over the matter.

    You had said that the app didn’t work correctly as non-admin because it didn’t persist settings that it should have.  LUA Buglight does more than just log the “access denied” issues that occur — it temporarily gives the app the admin permissions it needs to get past those issues.  If it didn’t, then a permission failure that caused an app to stop working would make it impossible to test the rest of the app.  Read the documentation for more info — particularly about how LUA Buglight makes it possible to analyze problems that SysInternals’ Regmon and Filemon can’t.

    As to how to fix problems with components writing to .ini files, take a look at the IniFileMapping solution (#3b) in Fixing LUA Bugs, Part I.

    — Aaron

  8. flipdoubt says:

    Thanks for the valuable advice.

  9. John C. Kirk says:

    Thanks for this tool – I’ve found it useful for a couple of old applications here (e.g. ones that write to a private “.ini” file in the Windows folder).

    However, I’ve had trouble getting it working with Cisco Network Assistant v4.0. Basically, that program works fine if I run it as admin, but the splash screen just sits in an infinite loop if I run it as a basic user. If I then run it inside LUA Buglight, it comes up with an error message: “Prelaunch Message Dialog – Unable to find the required startup resources”.

    Anyway, leaving aside the problems with the Cisco app, this may indicate part of the Buglight tool that needs tweaking a bit?

    (I’m just about to install v4.1 of the Cisco app, and I’m hoping it will work better.)

    Thanks for the feedback – please continue to provide more — good, bad or ugly is all helpful.

    What may be happening is that LUA Buglight is helping you get past the LUA bugs that kept it hanging at the splash screen, but then hit something else that it wasn’t able to handle.  See the documentation for some of the reasons LUA Buglight might stumble.

    — Aaron

  10. Bing Xiao says:

    The Ini file APIs (i.e, WritePrivateProfileString) assumes the ini file is in %windir% directory if the iniFile parameter is not a full path. Are there any reasons why Vista adopts the virtual store approach to redirect the path, instead of modifying the default behavior?

    Modifying the default behavior to what?  Writing the ini file to to the user’s profile instead of %windir%?  That would be a major change to a well-documented and widely used feature.  Apps using an .ini file without specifying a path have been able to assume that the file would be in a shared, machine-wide location.  That would create a lot of app-compat problems.  Note that there are other ways to redirect .ini files without touching the source code (see IniFileMapping references in my blog and elsewhere).  There is also the option to change access control on the .ini file in %windir% for some scenarios to keep it as a shared resource.

    — Aaron

  11. John C. Kirk says:

    Following up on my comment from yesterday, I upgraded to v4.1 of Cisco Network Assistant, but that behaved in exactly the same way. I think the problem may be that it runs in a slightly odd way – you run "prelaunch.exe", and that presumably passes information to some other program for the main app.

    Today I tried giving my user account Modify permissions to the installation folder, and when I did that I was able to run it fine. I then tried using LUA Buglight again, but that still resulted in the same error message (from the Cisco app), and the log file hadn’t been able to record any registry/file access.

    The Network Assistant tool is a free download from the Cisco website (although you have to register for a free user account on their website first), so you (Aaron) might want to get a copy for your own PC so that you can test it with the Buglight app. It doesn’t matter whether you have any Cisco hardware around, since the problem occurs before it gets as far as connecting to a device.

    Anyway, once I’d got this far, I then used a process of elimination to work out which particular file/folder needed special permissions. The confusing thing was that I went through every folder, and none of them had any files that were modified today. It turns out that the solution is to give Modify permissions to:

    C:Program FilesCisco SystemsCisco Network Assistantpackages

    (just that folder, not for files/subfolders). When the program runs, it creates a "LOCK" file in that folder, and then it deletes that file on exit. There is a separate "LOCK" file in:

    C:Program FilesCisco SystemsCisco Network Assistantutilities

    (0 bytes), but that one doesn’t seem to be used for anything.

    I emailed Cisco about this in June, although the only vaguely related contact address I could find was the one for reporting security vulnerabilities. They came back and said that you don’t need to be Admin, so I ought to open a support case with them, but we don’t have a support contract with them at the moment and I was reluctant to pay them money to report their bug. Anyway, I’ll email them again now that I’ve found the specific problem, in case they’re interested.

    What I have been thinking about is that it would be good to have a central repository for this kind of info, maybe as a wiki? I’ve seen a few people compiling separate lists of troublesome apps, but it would be easier if all the info was in one place.

  12. Alexander Suhovey says:

    Hey, Aaron,
    First of all, thank you so much for all your LUA-related stuff, just want to say that it is really appreciated among us sysadmins.
    Now, the question – just recieved MS Download notifications email and it has following entry:
     
    Microsoft Standard User Analyzer
    This application compatibility tool helps developers and IT professionals diagnose issues that would prevent a program from running properly as a standard user without administrator privileges.
    http://www.microsoft.com/downloads/details.aspx?familyid=DF59B474-C0B7-4422-8C70-B0D9D3D2F575&mg_id=10043&displaylang=en

    Didn’t use it yet but just wonder if it also is your child, or maybe based on Buglight idea…

    No, SUA is a different utility from LUA Buglight.  It does similar things, but the core approach is very different.

    — Aaron

  13. I’ll be presenting an MSDN webcast and demoing LUA Buglight next Tuesday, October 17, 2006, 11:00am US

  14. Hi!

    LUA Buglight is simply great.

    I’m using Your program on polish version of XP.

    Can You put Your eye on xml raport import function in LUA Buglight Reporter?

    That program is not accepting polish letters used in OS group names.

    Thank You!

    Artur — Thanks.  Please contact me via the “Email” link on this page.

    — Aaron

  15. I’ve been somewhat remiss of late in my focus on what I consider to be a very important aspect of the

  16. clhug says:

    We’re having trouble accessing network recources running an app through Buglight.  No matter what we do, on the Credentials tab, any drive mappings we set up show up in the bottom window as not being able to be copied to the admin environment.  We are logged into the PC as an active directory domain user ID that does have privaleges to the servers we’re mapping to.  We are not using alternate credentials to map to the servers, but the mappings always appear in the alternate credentials window in Buglight.  Any suggestions on what we might be doing wrong with the drive mappings?  Thank you.

    How are the drive mappings being created?

    — Aaron

  17. clhug says:

    We are mapping the drives using the Map Network Drive function under the Tools menu item in a Windows Explorer window.  We’ve tried just mapping the drive and running Buglight, and we’ve tried using the "Reconnect at login" option and then rebooting and logging in with the drives being automatically mapped that way.  On a side note, when we map to the drives, we are not prompted for any additional authentication.

  18. sbs says:

    I seem to have the same problem and would be interested in this information as well.

  19. JenM says:

    Checking to see if you have had a chance to look into the drive mapping issues sent on Nov. 28th.  Any info or thoughts on our problem with running apps on a server and going through Buglight on the pc’s harddrive???  Any info is greatly appreciated.

    Haven’t had a chance to really dig into it yet.  Can you send me the output from running NET USE at a command prompt?  Please use http://blogs.msdn.com/aaron_margosis/contact.aspx to send it.

    — Aaron

  20. MKTG says:

    This is a great utility, thanks a lot

  21. L’outil d’identification de dysfonctionnements liés à l’absence de privilèges est disponible depuis le

  22. Oliver says:

    It seems the Reporter utility doesn’t like non-ASCII characters in the XML file. On my German Windows I get quite a lot of these e.g. because “LOCAL SYSTEM AUTHORITY” (or whatever the English name was) is called “NT-AUTORITÄT” here. There are a few other such common words that contain umlauts, too. So, currently I always have to run the report file through a search&replace filter before I can load it into the reporter.

    So I guess either Buglight itself has to escape the umlauts or the Reporter has to be made capable of reading them…

    Otherwise, a great tool!!! Keep up the good work! 🙂

    Cheers,

    Oliver

    Oliver — Yeah, sorry about that.  Known bug.  Workaround for now is to hand-edit the XML.  Insert the following line at the beginning of each XML file, then the Reporter should be able to handle it:

    <?xml version=”1.0″ encoding=”windows-1252″ ?>

    HTH

    — Aaron

  23. ogiesen says:

    Aaron,

    perfect! Thanks a lot! 🙂

    Cheers,

    Oliver

  24. So I got this email earlier today….. Hi Susan, Blackthorne is eBay’s auction management software; it’s

  25. Not a beer (but you may need one after using this tool), but LUABuglight will help you to track down the issues with needing admin rights on a pc to run the application – my most recent example being Timeslips…

  26. Linc says:

    for some reason I can’t get this tool to work in windows 2000 Pro. Do I need XP for it to work ? The error I get when I try in 2000 is “Logon failed for local admin account (.Administrator). A required Privilege is not held by the client. (error # 1314 = 0x00000522). I am using the right password for my admin account. I Even tried setting up another local admin account and no go.

    Hope Im not doing something completely stupid.

    Thanks,

    Linc

    Linc:  No mistake on your part.  The tool will not run on Windows 2000 — it requires Windows XP or higher.  (The mechanism that LUA Buglight uses to get the “this-user-as-admin” token requires the “Act as part of the operating system” privilege on Windows 2000, and it is not recommended to grant that privilege to any user account.  That privilege requirement was removed starting in Windows XP.)

    HTH

    — Aaron

  27. Updated information about LUA Buglight.

  28. says:

    "LUA-Bugs" sind Schwachstellen im Code, die verursachen, dass besagter Code nur dann korrekt ausgeführt

  29. LUA Buglight™ is a tool to help both developers and IT Pros (sysadmins) identify the specific causes

  30. Need your help to fix an issue in LUA Buglight.

  31. VistaJuice says:

    Even though Microsoft’s Windows Vista has only been release for a short time, there are already some free additions from Microsoft. Verbatim from Blake Handler’s Blog (The Road to Know Where): WINDOWS VISTA GOODIES Experience Pack includes four programs

  32. VistaJuice says:

    Even though Microsoft’s Windows Vista has only been release for a short time, there are already some free additions from Microsoft. Verbatim from Blake Handler’s Blog (The Road to Know Where): WINDOWS VISTA GOODIES Experience Pack includes four programs

  33. Paul says:

    I have come across an error in LUA Buglight.  I recently had a need to install the ODF Add-in for Microsoft Word (OpenOffice.org document) for one of our users.  After installing I had the user open Word (2003).  The add-in did not work.  Upon further investigation I found the add-in only works when run as an administrator.  I tried to run MS Word with LUA Buglight and it displayed an error.  It said the command completed successfully however nothing happened.  Unfortunately I do not remember the error.  If I have time I will try setting this up again however since I have just installed OpenOffice for this user to solve the problem for now I may not have time.  Time will tell 😉  Anyway I thought I would pass along the steps used to duplicate the error in case you are interested.  I will try hard to make time to get you the error next week.

    The website for the ODF Converter is:

    http://odf-converter.sourceforge.net/

    It needs .NET Framework 2.0 and the Office Compatibility Pack (for Office 2003 to read Office 2007 files)

    Paul – Thanks for the information.  If you get a chance, can you provide more details:  what OS were you testing on, specifics about the error you saw — was Office raising the error, or LUA Buglight?  Did the Office app actually start?

    Thanks again.

    — Aaron

  34. Paul says:

    I was testing on Windows XP SP2.  It appeared to be a LUA Buglight error.  MS Word did not launch.

    Paul:  … and you specified the full, correct path to winword.exe, correct?

    — Aaron

  35. GeorgeSealy says:

    Hi, and thanks for the great tool.  I do have one question though.  Is there likely to be a command line version of Buglight?  

    The reason I ask is that we’re keen to Vista-proof our current product, and running Buglight as part of an automated build has a lot of appeal.  To do this though, we need to be able to run Buglight from the command line…

    Any help would be appreciated.

    GeorgeSealy:  A command line version is not likely at this time.  Sorry.

    — Aaron

  36. PatrickBennett says:

    Sorry, I can’t help but to reply to this:

    “Modifying the default behavior to what?  Writing the ini file to to the user’s profile instead of %windir%?  That would be a major change to a well-documented and widely used feature.”

    So, umm, making it so that all registry operations and file operations to certain areas go somewhere else instead (registry/file virtualization) *isn’t* a change to a *VERY* widely used and well documented feature?  So that an app that has been writing to HKLM for years will suddenly get different copies of its data when different users run it?  You don’t consider that a major change to a widely used and well documented feature??? *laugh*

    PatrickBennett:  You make a good point.  But there’s a substantial difference between a transparent (*) redirection for legacy applications when the user would not be able to perform the operation at all, and changing the default behavior for all programs at all times.  The redirection does not apply to apps that run elevated (would be able to perform the operation), that have a Vista-compatible manifest associated with them, or for which virtualization is explicitly disabled.

    Yes, it is a major change in behavior, which is necessary for application compatibility reasons to accommodate the major change in Windows moving toward standard-user-privilege-by-default.  It can have undesirable side effects, particularly around application management, but apps failing to work at all is worse.

    (*) transparent = “tries real hard to be transparent”

    — Aaron

  37. RyanC says:

    Hi,

    This is the first time I am using this tool. I am using local admin ID under administrator account and domain Id under non-admin account via Citrix environment.

    However when I start the appplication, I get the following error

    Couldnt start process with current user credentials – CreateProcessWithLogonW failed : Access is denied. (Error # 5 = 0x00000005)

    I have also tried changing to other applications like Notepad but still get the above error.

    Kindly assist. Thank you

    Regards,

    Ryan

  38. What&#39;s the cheapest way to make your SBS network more secure? I&#39;ve said this before I&#39;ll

  39. &lt;duh duh da da duh duh music playing in the background&gt; Your job, Mr. Phelps is to devise a way

  40. New Free Product from BeyondTrust Provides Enterprises with Fastest Path to Eliminating Administrative

  41. Russ says:

    The only tab that I have after executing luaBuglight (other than the app info tab) is the File System (1) tab, which shows that I’m opening \.<file-name>, which is the symbolic link to my device driver, and requires GenericRead and GenericWrite access.  Could this be the reason my app won’t run in LUA mode?

    [Aaron Margosis]  Could well be.  That item appearing in the LUA Buglight report indicates that the standard user cannot open it but that an admin can.  If the app needs to access that device interface in order to work correctly, then yes, that could be the sole reason your app currently requires admin rights.  One option would be to change the ACL on the device interface to allow the interactive user to access it (see IoCreateDeviceSecure in the DDK).  HOWEVER — you must be exceptionally careful in the driver to prevent its turning into a vector for unauthorized elevation of privilege (EoP).  Make sure to validate all inputs for size and content before operating on it; also make sure that you’re not exposing functionality that only an admin should be able to perform.

    If the driver access is required only for configuration and is not necessarily needed for normal use, you could factor out that part of the code and expose it only to users running with full admin rights.

    (BTW, the “(1)” on the tab indicates that there is one item on that page of the report.)

  42. Russ says:

    [One option would be to change the ACL on the device interface to allow the interactive user to access it (see IoCreateDeviceSecure in the DDK).]

    Thanks Aaron, that fixed it.  Since I’m using WDF I used WdfDeviceInitAssignSDDLString().

    /Russ

  43. Paul Fekete says:

    Am wanting to use Buglight but when I unzipped 2.0 there is now documentation (user guide?) there. Where can I get the documentation?

  44. Ales999 says:

    No work for Windows7 7100 RC ENG x86 🙁

  45. Andrew Howell says:

    Thanks for your blog, I’m finding it extremely useful and I’m just starting to have a go with LUA Buglight. Is there anywhere I can get any documentation? It sounds as if there was documentation for version 1 but you’ve taken that down. I’m guessing it would be of some use at least for the version 2 preview which I’m using.

    Thanks