The Case of the Notepad that Wouldn't Run
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:
- If the executable image includes a Vista manifest file that specifies a desire or need for administrator rights (this would be added by the developer who creates the image).
- If the executable is in Vista’s application compatibility database as a legacy application that Microsoft has identified as requiring administrator rights to run correctly.
- If the user explicitly requests an elevation using Explorer’s “Run as administrator” menu item in the context menu for executables (also can be set as an advanced shortcut property). Note that this does not run the executable under the Administrator account, but rather under the account of the logged in user, but with the Administrator group enabled in the process security token.
- If the executable is determined to be a setup or installer program (for example, if the word “setup” or “update” is in the image’s name).
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!
Comments
Anonymous
January 01, 2003
Last night on TBS was an old Friends episode, The One With the Ultimate Fighting Champion. In it, PeteAnonymous
January 01, 2003
PingBack from http://dancmorgan.wordpress.com/2006/10/02/the-case-of-the-notepad-which-wouldnt-run/Anonymous
January 01, 2003
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?Anonymous
October 02, 2006
Hi Mark,
As usual, a very nice writeup that's so helpful to us who sometimes have to investigate why Windows does what it does. I just wanted to warn you that there are two editor's notes (in brackets) still embedded in your entry.
Thanks, and keep up the good work!Anonymous
October 02, 2006
The comment has been removedAnonymous
October 02, 2006
> Then I launched it, expecting to see a
> Consent dialog like the one below ask me to
> grant the renamed Notepad administrative
> rights:
Yikes. I thought that dialog was only asking for consent to run the program.
For safety that dialog ought to be modified to provide three possibilities:
Run the program with administrative rights.
Run the program with ordinary rights.
Don't run the program.
For a lesser amount of safety, just change the wording to say what it will do in each case:
Run the program with administrative rights.
Don't run the program.
The reason the latter change is less safe is that users who want to run the program will surely choose to run it as administrator rather than not running it.Anonymous
October 02, 2006
Interesting, but I did not catch how new Vista technology would provide better security? Is it somehow restricted to run all these things (to become an admin for some particular file) in scripts.Anonymous
October 02, 2006
Thanks again for another great post. It does bring up a question.Why is there an assumption that all setup programs require admin access? Since there is no limitations on running programs from your profile (although that would be interesting) as long as the program doesn't enhanced access why single out installers? There may be a few situations where you want to install a program just on one user or test out a program in the relative safety of limited user.I also wonder that since limited user only has full write access to their profile, where should an program should be install into by default? Create a %USERPROFILE%Program Files... ? Thinking about any nt based windows, not just vista. And not just .msi files.Anonymous
October 02, 2006
Gaetano: how would you stop an application constantly trying to perform administrative functions and spamming the user with consent dialogs? How would you handle programs which work fine on Windows XP as a limited user, which correctly handle the error return values when attempting to perform some administrative task? UAC creates a consent dialog at the start of a program, and that's it.Ilya: UAC only kicks in when a program is run from Explorer. No consent dialogs appear when running a program from a command prompt, from within a script, or programmatically. They run with the permissions of the parent process (typically CMD.EXE). To perform administrative tasks from a command window, right-click a Command Prompt shortcut and select Run As Administrator.Anonymous
October 02, 2006
Monday, October 02, 2006 5:31 PM by Mike Dimmick> Gaetano: how would you stop an application> constantly trying to perform administrative> functions and spamming the user with consent> dialogs?Not being Gaetano, my answer might be different.When an application tries to perform an administrative function, Windows will ask the user. If the user approves, the application gets the privileges. If the user disapproves, the application gets the denial. If the user asks to be asked again later, then Windows will make some decision about this time but will ask the user again the next time the program tries to perform an administrative task.There is precedent for this. When a program tries to access the network, Windows Firewall asks the user. The user can say to approve, disapprove, or be asked again later. If the user chooses to be asked again later then Windows decides whether or not to grant the access this particular time.Of course the precedent also shows an improvement that could be made: the user could be given a chance to deny this time but be asked again later.Anonymous
October 03, 2006
Mike: I would imagine that a sort of granted-security-permissions cache is present, so that after an app. has triggered a 'need more perms' dialog once, subsequent provileged calls will not trigger it anymore (afaict both sudo and macosx do it).I also strongly agree with catfish: why should a security dialog pop up if the software just wants to be installed in the user folders / reg hive, and needs no special admin privileges?Besides, I can only imagine that the 'bad guys' will immediately make sure their self-installing code has the correct name and resource strings to escape this basic security anlysis, so there seems to be little security added in doing the 'guestimate'.Also, I do not see how asking beforehand for admin privileges would change with apps "which correctly handle the error return values when attempting to perform some administrative task".I am not too versed in windows development, but I can imagine keeping backwards compatibility with 'bad' apps can be a gret hinderance. Isn't the introduction of a new OS the best (only?) opportunity to deprecate old habits and force third party developers to straighten up their act?ps: Note to self: always count to a hundred before posting flames.Anonymous
October 03, 2006
The comment has been removedAnonymous
October 03, 2006
I have the same concern that many others have--if users weren't stopped from clicking through warnings on running unknown executables on XP SP2, why should we expect them not to click through the dialogs to allow an install of a piece of malware with the filename "setup.exe"?Anonymous
October 04, 2006
The comment has been removedAnonymous
October 05, 2006
I like your article Mark, very informative. But in next articles can you turn off some strong colors like you do in this article. They look pretty much like flowers.Anonymous
October 05, 2006
"Popping it up at the start provides a consistent experience."Agree, but it looks like UAC itself is not providing any new protection in such case. You only need to give the consent once at program startup, through dialog confirmation - just like you do today.Given the extremely intrusive nature of UAC, the question is: was it worth implementing in the first place?Anonymous
October 05, 2006
The comment has been removedAnonymous
October 05, 2006
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.Anonymous
October 05, 2006
"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".Anonymous
October 06, 2006
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.Anonymous
October 10, 2006
Scotlandard: Those colors are from Windiff.Anonymous
October 13, 2006
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.Anonymous
October 13, 2006
The comment has been removedAnonymous
October 22, 2006
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.Anonymous
October 23, 2006
The comment has been removedAnonymous
October 25, 2006
The comment has been removedAnonymous
October 29, 2006
Mike Dimmick: Try running diskpart.exe in command prompt and you will get a UAC prompt.Anonymous
October 31, 2006
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! StanislavAnonymous
November 01, 2006
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.Anonymous
November 08, 2006
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.Anonymous
November 12, 2006
Hi Mark, 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, DeimosAnonymous
December 01, 2006
==================== "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." So what would stop the bad guy to write the same manifest in a malicious software?Anonymous
April 04, 2007
I am surprised only one person has commented at all on NOTEPAD's inablity to find the mui file. I feel even though it's included with windows that it is quite surprising the assumsion was made to hardcode the relative folder path to the ".mui". I can't say that I usually make additional copies of notepad.exe (although WinPE disk are a good example) but, why would there not be a check (say, a REG key) for the default MUI location? Then check the relative path, and maybe the folder the EXE started from. Last resort fall back on staticly linked strings table in the EXE. I know including the strings would impact filesize but, as large as things are these days, what's a few string's (could even be abbrievated since it's a fallback option). On the other hand MS has never cared about bloat have they? Regaurdless there should have at least been a 'MUI File not Found ERROR'.Anonymous
February 08, 2008
I've grown to loathe the UAC in Vista. Falconz, the default locations and overall folder structure changes in Vista I'll never understand.