An End to Unwanted UAC prompts

By Stephen Kellett
25 May, 2014

We have just updated all of our software tools so that they no longer require administrator privileges to run. No more unwanted User Account Control prompts!

I’m going to explain why we used to require administrator privileges, why we’ve removed that requirement and what impacts that has for you the user of the software.

The past: Our software tools up until 24 May 2014

Memory Validator desktop icon with admin

If you’ve ever used our tools on Windows Vista, Windows 7 or Windows 8 you’ll know that our tools required Administrator privileges to run.

Because of this each time you start the software you are faced with a User Account Control dialog. There is a pause, the screen darkens and then the User Account Control dialog is displayed. You can’t do anything other than interact with this dialog. It’s a “Yes I want to run this. No I don’t want to run this.” deal. But of course you want to run this software, you just started it. Hal really should open the pod bay doors.

This gets even more frustrating if you’ve used our command line interface to automate your testing or if you need the software under test to run without administrator privileges.

Memory Validator desktop icon without admin

The ideal scenario would be for the software to run without requiring administrator privileges, just like most applications on your computer. This would improve the usability of the software, make automated testing smoother and just be better all around.

 

Reasons for change

When our tools require administrator rights to run there are multiple consequences of that requirement:

Memory Validator User Access Control dialog

 

  1. A User Account Control dialog is displayed, interrupting the user’s flow.
  2. Automated tests require someone present to approve each tests’s run because a User Account Control dialog is displayed. This either partially or completely defeats the purpose of automating the tests.
  3. The software under test is now run with Administrator privileges. For most applications that isn’t an issue but for some applications this is not the correct privilege level for that application to run at.

The first issue isn’t ideal and adds frustration to the user’s life.

The second issue is horrible.

The third issue is a deal breaker for the few people that must test their application’s at a specific privilege level.

As you can see we had to change this state of affairs.

Working without Administrator Privileges

When running the software without administrator privileges the only thing you’ll notice is no administrator privileges. You can launch and monitor applications without administrator privileges. You can also monitor services that are linked to the NT Service API associated with the tool without administrator privileges. Only the Inject into Application and Wait For Application functionality (C++ tools only) prompt you for administrator privileges. Other than that the software works the same as usual.

Memory Validator inject dialog with administrator privileges required warning

 

If you run the software without administrator privileges the software will communicate with SVLAdminServiceX86 or SVLAdminServiceX64 as appropriate. The service will do the work required.

The C++ tools now work with desktop application, services running on LocalSystem account and services running on LocalService account.

Desktop context menu, run as admin

You can still right click the software and run the software with administrator privileges. If you choose this the software will behave exactly as it did in the previous release, it will do all the actions itself and not ask the SVL Admin Service to do the work.

If you want to Inject into a running process or Wait for an application to start we can still do that with the C++ tools but you will need to run with administrator privileges to do that. This is principally because CreateRemoteThread from a service doesn’t work when the target application is not running in the same Windows session. This is a Windows security improvement. Until we can provide a workaround for this these two activities require administrator privileges. The software will automatically prompt you for this process elevation.

Similarly if you launch an application using CreateProcess (the recommended method) you don’t need administrator privileges. But if you choose any of the other options you will be prompted for administrator privileges.

 

Why did we require administrator privileges?

Our software tools are dynamic analysis tools that analyse the behaviour of software at runtime. As such our tools use a variety of techniques to invade the user space of the software under test and to communicate the collected data back to the user interface. If the software is a desktop application then different security environments are in force compared to if the software is a service. When dealing with a service such as Internet Information Server then you are dealing with a very locked down process. Some of these processes are very hard to interact with. You may be able to inject into the process but then not communicate with the user interface.

To cope with this early versions of our software simply used global shared memory (prefix the shared memory name with \Global) and ran with appropriate debug security privileges. This worked really well. Then came Vista with the new security regime. I’m sorry to say that our initial response was lazy. We simply put admin privileges on everything as a temporary workaround until we could get around to fixing things so they’d work without admin privileges.

So what happened?

We got side tracked. We spent a lot of time focussing on other things, supporting different operating systems, different Visual Studio, porting the software to 64 bit, floating licences, improving the UX of tools like C++ Coverage Validator. And because we were at the time developing on Windows XP x64 we didn’t feel the pain of using the new security regime all the time. We’d use Windows 7 for our email machines, personal laptops and for testing but not for daily development.

Why were we using Windows XP x64?

The answer is simple. The compressed start menu on Windows 7 is harder to use than the flyout menu on Windows XP. The search functionality on Windows XP is so much easier to use than that built into Windows 7, especially if you are searching for words inside a document (think Visual Studio project, manifest, source code, etc). Yes I know Windows 7 search has great power built into it, but it’s slow, hard to use as it’s crammed into one tiny window and in my experience often doesn’t work. Whereas the Windows XP search experience is simple, easy, reliable and fast (three fields, file name, content to search for, where to search). Sadly Microsoft has made search on Windows 8 even worse (right click on a search result and if you open the location you lose the search results – how is that useful?). And of course the start menu has gone.

A long break

Anyway, as the end date for Windows XP support, April 8th, loomed we started getting queries about our software that we’d never fielded before. Most were related to the User Account Control issues already described. People who had been using Windows XP and Windows XP x64 for development were abandoning ship, moving to Windows 7 or Windows 8. By the time we got to the start of March I knew we had to drop everything we were doing, annoy some of our existing customers by putting certain work on hold, and make our software run without administrator privileges. No User Account Dialogs!

Usually we issue one or two software releases per week. Or maybe one every two weeks. Our last software release was March 19th, over 10 weeks ago. This has been the longest break between software releases we’ve ever had. The scope of the work has been huge. We’ve had to write a service that the software talks to to do anything that would normally require administrator privileges. Then we had to identify every area that was impacted by the change in privilege levels. This meant some areas of the software had to be completely re-written. For example our Registry handling software now also has to be able to write to files and memory so that we can pass that data to the service so that the service can populate certains parts of the Registry on behalf of the software tool. Another area that has changed is shared memory. You can no longer just prefix everything with \Global and expect it to work. As such shared memory handling has had to change. This is particularly important if you are working with services. Copying files to certain locations is no longer possible. Writing files to certain locations is no longer possible. All these things we’ve had to address. We’ve had to update the installers to correctly install the service (and uninstall it first if we’re replacing it with an updated version). We’ve had to test on Windows XP, Windows x64 (to ensure our XP customers still get the experience they expect) and on Windows 7 and Windows 7 x64, Windows 8 to ensure everything works correctly. The different security handling for services between XP and Windows 7/8 causes some interesting problems to be worked around. We’ve tested everything to bits.

And along the way we’ve re-factored some of our software and also exposed and fixed some low level bugs in our hooking software (some of which are a side effect of recent optimisations in the way Microsoft build their operating system DLLs). Error reporting on the Diagnostic tab has improved.

Weren’t we dog-fooding?

You might think we weren’t dog-fooding. That is, using our own software to test our software. Yes, we do use our own tools.

But we were not using our tools in an environment that would cause these issues to be apparent to us. We had chosen to eat at our favourite restaurant rather than at the best restaurant in town. Having just spent two weeks on a cruise ship this analogy is sound, we quickly concluded that we preferred the Bistro over the fancy restaurant.

In fact we had deliberately chosen Windows XP x64 because we found it easier to use for the reasons already stated. In hindsight, although this was a good choice for ease of development it was a poor choice from the point of view of experiencing what the bleeding edge of our customers use.

Our new development environment

Our current development environment is Windows 7 but we’ll be moving to Windows 8 as soon as the new machines arrive. For Windows 8 we’ll be adding the Stardock Start8 Start menu. We’ve also written some search tools that although crude, allow us to search files more easily than using Windows 8 built in search functionality. We’re writing more tools to make our development work easier, even as Microsoft’s own UX efforts make what we want to do harder.

Conclusion

The move from administrator privileges required has been a time consuming, challenging experience. We’ve learned a lot along the way and had to change how our software works. However the result is that you, our customers, the users of our software now have an easier time using the software. I hope you agree the effort was worth it.

Fully functional, free for 30 days