Mark Russinovich’s technical blog covering topics such as Windows troubleshooting, technologies and security.
Dave Solomon was on campus a couple of weeks ago presenting a Windows internals seminar to Microsoft developers. Before I joined Microsoft I taught the classes here at Microsoft with him, but now with my other responsibilities here I step into the class and guest present a module or two if my schedule permits. This time I presented the security module, which describes logon (authentication) and the access check (authorization) model. It also includes a separate section on Vista’s User Account Control (UAC) feature, which consists of several technologies including virtualization and a new Mandatory Integrity Control (MIC) security model that’s layered on top of the existing Discretionary Access Control model that Windows NT introduced in its first release.
UAC allows for users, even administrators, to run as standard users most of the time, while giving them the ability to run executables with administrator rights when necessary. There are several mechanisms by which executables can trigger a request for administrator rights:
Perhaps the most common need for administrator rights comes from setup programs, which generally can’t install properly without write access to HKLM\Software and \Program Files, two locations that only administrators can modify. As an ad-hoc demonstration of the last request method, during the presentation I copied \Windows\Notepad.exe to my account’s profile directory, renaming it to Notepad-setup.exe in the process. Then I launched it, expecting to see a Consent dialog like the one below ask me to grant the renamed Notepad administrative rights:
To my consternation, no such dialog appeared. In fact, nothing happened. I reran it and got the same result. I was thoroughly confused, but didn’t have time to investigate in front of the class, so I moved on.
When I later got a chance to investigate what had happened, I started Notepad-setup.exe using Windbg (part of the free Debugging Tools for Windows) by clicking “File->Open Executable” followed by “Debug->Go” (or you can press F5). I then stepped through the initial instructions of Notepad’s entry point, Winmain. I saw it call an initialization function named NPInit that invokes LoadAccelerators to load Notepad’s keyboard accelerators. Strangely, LoadAccelerators was failing, causing NPInit to return an error to Winmain and Notepad to silently exit. But why would Notepad fail to load its accelerators, which should be included in the Notepad image itself?
My next step was to see if the file’s name was somehow causing the different behavior so I tried running a copy of Notepad.exe with the original name from my user directory, but got the same behavior (or lack thereof). It was time to watch what was happening with Filemon.
This scenario called for logging the operation of Notepad’s successful execution and comparing that to the log of the failing execution. I started Filemon, set the Include filter to Notepad.exe and the Exclude filter to list the processes that reference Notepad’s image when Notepad launches, including Svchost (where the prefetcher runs) and Explorer (which I was using to launch Notepad):
I collected both traces, but before I could compare them I had to remove the columns that are always different in different execution traces: Sequence, Timestamp, and Process. To do this I loaded the traces into Excel, selected the data in the first three columns, deleted it, and saved the traces back out as tab-demitted text. You can get the two trace files here.
There are a number of text comparison tools available, but one that’s both free and that serves the needs of this type of comparison is Microsoft’s Windiff. Simply open both files and red and yellow lines highlight differences.
The first few lines that Windiff flags are Notepad reading its prefetch file, which has a different name in each trace because the name encodes the full path of the Notepad image it is associated with in a hash number:
The next set of differences are operations present only in the successful run of Notepad, and appear to be queries of some kind of global Windows resource cache that’s new to Windows Vista:
It wasn't clear to me why one run references the cache and the other doesn’t, so I continued to scan through the differences. The next group of differences are at lines 47-51 and are simply due to the different paths of the two Notepad copies:
Finally, at line 121 I came across something that looked like it might be the source of the problem:
The execution of \Windows\Notepad.exe successfully reads a file named Notepad.exe.mui from the \Windows\En-us subdirectory. Further, at line 172 in the trace comparison the failed launch of Notepad tries to read a file of the same name from an En-us subdirectory, but fails because the subdirectory doesn’t exist:
I knew that .mui files store language-dependent resources like strings and accelerators, so I was pretty certain that Notepad’s failure to load its accelerators was due to its inability to find the appropriate resource file for my local, US English (En-us). To verify this I made an En-us subdirectory in my profile directory and copied Notepad.exe.mui into it, reran Notepad from my directory, and it worked.
Previous versions of Windows used .mui files to separate language-specific data from executables, but didn’t know that in Windows Vista this capability is exposed for applications to use. The nice thing about the .mui support is that resource-related functions like LoadAccelerators and FindResourceEx do the magic of the language-specific resource files so application developers don’t need to do anything special coding to take advantage of it.
Now that I had Notepad working outside of the Windows directory I turned my attention to why I hadn’t been presented with a UAC Consent dialog asking me to give it permission to run with administrator rights. What I discovered empirically and then confirmed later in the Understanding and Configuring User Account Control in Windows Vista article on Microsoft.com, is that heuristic setup detection only applies to files that don’t have an embedded manifest that specifies a security TrustLevel. Notepad, like all the Windows executables in Windows Vista, does include a manifest. You can see it when you do a dump of Notepad’s strings with the Sysinternals Strings utility:
So, thanks to Filemon, the case of the Notepad that wouldn’t run was closed!
The real benefit of UAC is that the user account is running as a user instead of an administrator, unless they opt-in to an escalated context.
It is true that you cannot stop someone from destroying their PC if they really want to. Installing a piece of software is always a risk, even from established vendors (never had an Office install go horribly awry?). But UAC adds real value because it adds a tangible layer of protection when not installing software.
When the majority of applications that a user runs don't prompt them to authorize the application, they should realize there is a difference between normal applications and the one that's asking for permission and think twice about why the application is causing the computer to look funny.
I have issues with UAC, but I've learned to live with it for the most part. It is annoying, but there are enormous benefits to not having admin rights all the time. Trust me, it beats the snot out of running as a user in XP.
"But UAC adds real value because it adds a tangible layer of protection when not installing software."
As you can see above, it's trivial to make UAC think you're installing something. 'setup' or 'update' in the filename is enough. Maybe there are some benefits of UAC, but malware will easily work around its "protection".
The reason why it did not launch the app should be logged to the event log. It should not take a person of Mark's capbilities just to figure out why an application did not run. A failure like that should leave some breadcrumbs somewhere in the system to help diagnose the problem.
Another good one Mark! May I suggest you do the same investiagtion on Adobe Reader next time? Even the full version 7.0 seems to bring even the best PCs to it's knees. What is this program doing that causes the long delays?
Scotlandard: Those colors are from Windiff.
Interesting!!! I went one step ahead to find what is in an exe that lets UAC decide that this is setup or not and i could find this by opening the file I named notepad-setup.exe in notepad itself. I noticed that it had something like "I n t e r n a l N a m e N o t e p a d" in this file. Which when i replaced by "I n t e r n a l N a m e S e t u p " (Taking care of not removing white spaces, assuming they are mere white spaces) and saved this file.
Next time running notepad-setup.exe i could see the Consent UI launching.
Last thing i wanted to point here is a correction/addition to your article that when you copy .mui file to your profiles directory then you also need to change the name to notepad-setup.exe.mui to get things working.
This is really an echoing of catfish's sentiments regarding "/Program Files." Is there really a pressing need for every setup.exe to use this directory? And why isn't there, as catfish says, some userland version of "Program Files", for applcations which, in their normal execution, don't require elevated privileges. I guess it redounds upon the developers to isolate aspects of their applications which require privileges - the execution of which would prompt a user for his admin password - from the run-of-the-mill processes that don't need elevation. Mark's investions, as always, are comprehensive. But I can't see my neice following the debugging output wheneven her ponys.exe doesn't work.
It's funny reading the complaints about Notepad's original code not handling these errors gracefully or to some silly n'th degree.
Did it occur to you people that Notepad was coded with some assumptions in mind so that the errors that Mark forced to happen probably didn't justify the cost involved in handling them.
I'd love to see some of your code and then see how you live up to your own expectation of others.
When you made the change of "I n t e r n a l N a m e S e t u p " in the file, you probably messed up the signing (hash value, or whatever), making the new .exe appear to NOT be an orriginal MS program (which it isn't anymore).
That is why you saw the Consent UI.
Mark, this is a bit off topic, but I would be interested to see you blog about the controversy over "Patch-Guard" that has been publicized in the last month. I'd like to see an unbiased opinion of whether patch-guard is something that will improve Window's security or whether it will cripple security solutions' ability to fight malware.
Just a suggestion.
Try running diskpart.exe in command prompt and you will get a UAC prompt.
Mark - nice article! It is pitty you do not write more often. Does it mean, that now when in Microsoft, you see there are so many things to fix(?)...- and therefore do not have time for blogging?.
Anyway, thanks for any upcomming articles! Stanislav
Preheps it'll be better if certain warning message will show up if ther mui file cannot be found.
Or perheps if Windows treat it as the ".file" content folder when you save a webpage in IE with "Webpage, complete" option, that if you move it around, the folder will be moved too.
What I want to know, is whether regedit.exe still opens a UAC prompt.
Under Vista beta 1 (i think) I was /unable/ to run regedit as a limited user.
I just did realize that you have moved into Microsoft.
First thought i had when I realized that it wasn't a mistake when i tried to reach your old site, was that you somehow had betrayed all of
us, but now i'm considering the idea that this could bennefit all of us. For you i guess is a great oportunity, and for us because sure you will mark a difference inside there.
I want to thank you for all the GREAT work you have bring to us, and i hope that with you inside microsof, it will finally become a OS, an OS that really works the way it should!
Best regards and whishes,