Mark's Sysinternals Blog

Group policy settings are an integral part of any Windows-based IT environment. If you’re a network administrator you use them to enforce corporate security and desktop management policy, and if you’re a user you’ve almost certainly been frustrated by the limitations imposed by those policies. Regardless of which you are, you should be aware that if the users in your network belong to the local administrator’s group they can get around policies any time they want.

There are two steps to circumventing a group policy setting: identifying the setting’s location and preventing the setting from being applied. There are many group policy references available, but since machine group policy settings store in the HKEY_LOCAL_MACHINE branch of the Registry and per-user group policy settings store in HKEY_CURRENT_USER, if you don’t know the location of the setting that’s preventing you from doing something you want you can use Regmon to find it.

The number of desktop lockdown settings available to group policy administrators is enormous. They can prevent you from doing anything from changing your desktop appearance and start menu to running certain applications. Two commonly applied settings include a pre-configured screen saver program so that users don’t waste resources on frivolous screen savers, and a screen saver timeout so that systems aren’t left indefinitely accessible when a user steps away. When these settings are in effect Windows omits the screen saver tab of display properties control panel applet or doesn’t let you modify the screen saver or its timeout. I’m going to show you how to use the power of being a local administrator and Regmon to track down these settings and override them on your own system.

The first step is to launch Regmon and capture a trace of policy setting being read by whatever process enforces it. Explorer implements most policies, reading some at the time you login and others when you perform specific actions. If the policy setting is read during the logon process you must run Regmon in the local system account so that it captures a trace of your logon. You can do that by using psexec:

psexec –s –i –d c:\sysint\regmon.exe

The instance of Regmon that launches will survive subsequent logoffs and logons and capture all activity during those activities.

Explorer doesn’t show the display properties dialog, but to easily determine which process hosts a configuration dialog such as the display properties dialog, simply run Process Explorer and highlight the dialog with Process Explorer’s window-finder toolbar button. Process Explorer selects the owning process in response, which for the display properties dialog is a Rundll32.exe process (look at its command line in its Process Explorer properties dialog to see how it launches).

Next, search or visually scan the resulting Regmon trace for strings that you think might be in the name of the Registry key or value related to the policy setting you are targeting. For example, if you scan a trace of the display properties execution you’ll find a query of HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System\NoDispScrSavPage. In the trace displayed below the value is set to 1, which means that a per-user policy is in effect and that the screen saver page won’t show on the display properties.



Once you’ve identified a policy’s Registry value you can prevent the policy from being applied by removing all access to the Registry key in which it’s stored. Double-click on the value in Regmon’s trace to open Regedit to the value, move to the parent key and open the security editor. In most cases the security of the key is inherited so you won’t be able to just remove the existing access entries. Instead, you’ll have to open the permissions editor’s advanced security dialog and remove inherited security. If you try to edit the permissions of the key and you are denied access use the advanced security dialog to make yourself owner of the key (since the local administrator’s group has the Take Ownership privilege assigned to it) and then you’ll be able to modify its security.

The next time you open the display properties dialog it won’t be able to read the policy settings and will behave as if the policy is undefined. Unfortunately, the HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System key doesn’t store the screen saver selection or timeout policies, so if those are defined you’ll see a dialog like this:



If you capture another Regmon trace and look through it for relevant values you’ll find these queries:



Once you remove all access to HKCU\Software\Policies\Microsoft\Windows\Control Panel\Desktop you’ll be able to reopen the display properties dialog and select the screen saver of your choice. I recommend that you leave the timeout to whatever your network administrator has defined (or lower it) so that you don’t get into real trouble by violating the security policy (as opposed to the usage policy you violate by changing the screen saver).

This demonstration highlights the fact that networks that run with users as local administrators have no way to police the usage of their computers. The reason that most networks leave their users with so much power is that many line-of-business applications violate basic security programming guidelines and won’t run otherwise. However, by using Regmon and Filemon to find the Registry keys, files and directories that an application is unable to access as a limited user, and then defining security group policy settings so that limited users have access to those resources, network administrators can run users in limited accounts and gain real control of corporate computer usage and security policies.

The other day I was intently editing code in Visual Studio and hit F7 to compile my latest batch of changes when I was interrupted with a dialog box that informed me that my file couldn’t be saved to disk:



I viewed the suggested cause with suspicion because I had been working with the file for about an hour, saving and recompiling modifications as I went without a problem. The first step in my investigation was to therefore run Filemon and determine the actual error underlying the dialog box:



The sharing violation error highlighted in the Filemon trace confirmed the dialog’s message that Visual Studio was unable to update the file. This error results when a process attempts to open a file that another process has previously opened in such a way as to prevent concurrent read, write, or delete access, or a combination of those access types.

What application would possibly want to open a source code file while I was working on it? To get the answer to that question I turned to Process Explorer. I opened Process Explorer, clicked on the Find Handle toolbar button, and entered “dfrgcmdr.cpp”, the name of the file in question, as the search text. Process Explorer populated the search results with one entry that identified the guilty process and when I double clicked on the entry I was taken to the specific handle representing the open of the file in Process Explorer’s handle view for that process:



The MSNGather.exe process, which describes itself as the MSN Desktop Search (MDS) executable, had opened two handles to the file I was working on. MDS was apparently indexing the file’s contents because it noticed that the file had recently changed. The file is relatively small so I expected MDS to be able to index it in a matter of seconds, but I had already spent about a minute looking into the error dialog’s cause and MDS still had not closed the file. In fact, it was not for another several minutes before MDS finally finished with the handle and let me get on with my work.

This experience uncovered what I believe are two MDS bugs. The first is that MDS is holding files open for indexing without allowing them to be modified. This can interfere with system and user file activity and, in any case, I don’t see it as necessary. MDS can’t keep its data current with the most recent modifications of all files without indexing changes as they occur, an approach that would introduce an unacceptable performance impact, so why should it care if a file is updated as its being indexed?

The second bug is that MDS holds files open for long or indefinite periods. The CPU usage for MSNGather.exe was zero for most of that time so my theory is that that MDS began indexing the file, but paused when it detected system activity in the form of my compiles in order to keep indexing a background operation. MDS should close handles to files that its scanning while paused so that it doesn’t interfere with foreground file activity such as deletions and renames.

My last blog entry on the memory bloat of managed (.NET) applications generated the controversy and misinterpretation of my primary points that I expected, so I’m following up with some clarification.

First, I stated that managed code is ideal for client-server applications, especially on the server side. On a server security is critical, and because server applications are long-running, avoiding memory leaks is also critical. For client-side only applications, however, security is only important if the client is network-enabled and connects to arbitrary and potentially compromised servers (like Internet Explorer does). Memory leaks are not as important because most client applications don’t require continuous access and restarting the application (or rebooting if necessary) resets a leak.

Memory footprint is much important for a client-side-only application since there can be many such applications running concurrently and clients often have limited memory. Someone stated that by the time that Longhorn ships most new systems will have 1 to 2 GB of memory. In corporate environments clients have at least 3-year life cycles and home users even in prosperous nations might upgrade less often. In developing nations you’ll see system configurations lagging the mainstream by 5 years. That means that most of the world’s computers won’t have 1-2 GB of memory until several years after Longhorn finally ships.

It’s amazing to me that no matter how much memory we add, how much faster we make our CPUs, and how much faster we make our disks spin and seek, computing doesn’t seem to get faster. If you have a Windows NT 4 system around compare its boot time and common tasks with that of a Windows XP system. Then compare their system specs. Then ask yourself what you really can do on the Windows XP system that you can’t do on the Windows NT 4 system.

A few years ago Microsoft embarked on an anti-Java campaign called .NET, spinning .NET as a revolutionary technology (while failing to explain that it’s really Microsoft’s own implementation of the JVM concept with new languages layered on top of it). The .NET hype has died down somewhat in the last couple of years, but the multiyear marketing blitz has had its inevitable effect: lots of people are writing .NET applications (also known as managed applications). In fact, my Dell laptop includes a managed Dell utility that tells me when there Dell security alerts.

Both the client and server side of Web applications are ideal candidates for a managed environment, since the .NET runtime handles much of the complexity of cross-network communication and simplifies memory management. However, the proliferation of managed applications has extended to client-only applications. Microsoft already includes several with Windows XP Media Center Edition and Tablet PC Editions and many more are coming in Longhorn.

The reason I’m scared at the prospect is that managed applications have essentially no consideration for performance or system footprint. I’ll use Notepad as an example because I can compare a managed Notepad with the unmanaged one (unmanaged applications are also known as native applications – not the same as a native application from the point of view of Windows NT, which are applications that use the native API) that ships with Windows XP. You can download the managed Notepad with source code at http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=84.

In this experiment I’ve simply launched both versions and will look at their performance-related information with Process Explorer. In Process Explorer’s process view you’ll see the managed version highlighted in yellow, which is the default highlight color for processes that use the .NET runtime:



You can see that Process Explorer has also highlighted Outlook and SharpReader as managed applications. Outlook isn’t a managed application (at least not the Office 2003 version), but I installed Lookout (http://www.lookoutsoft.com/Lookout/lookoutinfo.html), which is a managed Outlook search add-on that loads as a DLL into the Outlook process. SharpReader (http://www.versiontracker.com/dyn/moreinfo/windows/28759) is the RSS feed aggregator that I use, and it’s obviously written in .NET.

If you open the process properties of both Notepad applications and compare the performance pages side-by-side you’ll see why I hope that Independent Software Vendors (ISVs) and Microsoft stay away from .NET for client-side-only applications. The properties for the managed version is on the top with those of the native instance below:





First notice the total CPU time consumed by each process. Remember, all I’ve done is launch the programs – I haven’t interacted with either one of them. The managed Notepad has taken twice the CPU time as the native one to start. Granted, a tenth of a second isn’t large in absolute terms, but it represents 200 million cycles on the 2 GHz processor that they are running on. Next notice the memory consumption, which is really where the managed code problem is apparent. The managed Notepad has consumed close to 8 MB of private virtual memory (memory that can’t be shared with other processes) whereas the native version has used less than 1 MB. That’s a 10x difference! And the peak working set, which is the maximum amount of physical memory Windows has assigned a process, is almost 9 MB for the managed version and 3 MB for the unmanaged version, close to a 3x difference.

Is 8 MB of private memory a big deal? Not really, but then again this is basically a zero-functionality application (it doesn’t even have search or replace). Once you start to implement features in .NET the private byte usage really grows. SharpReader, for example, consumes close to 42 MB of private bytes to store data related to around 20 different feeds, and the user interface for SQL Server 2005 beta 3 (written in managed code) consumes 80 MB when run on a fresh installation.

Compare that managed application bloat with the memory usage of fully-featured unmanaged applications that have 10 times the complexity of the managed examples I’ve listed: Microsoft Word weighs in at around only 6 MB after starting with no document loaded and Explorer on my system is consuming only 12 MB.

Now imagine a future where a significant percentage of applications are written in .NET. Each managed application, ignoring the memory overhead of document data and shareable memory like code and file system data, will eat somewhere between 10 and 100 MB of your virtual memory. If you think your system is slow now, wait until several of these applications are active at the same time and competing for physical memory.

It makes me wonder if Microsoft gets a cut of every RAM chip sold…

If you’ve replaced Task Manager and run Process Explorer at all times in your tray (like you should) and you’ve run Regmon you probably have noticed Services.exe repeatedly querying the entire HKLM\System\CurrentControlSet\Services branch of the Registry:



The Regmon trace indicates that Services.exe is querying the ObjectName value of each service. The ObjectName value stores the name of the user account in which the service executes. If the account is not specified the services runs in the local system account.

This polling by the Service Control Manager stops when you exit Process Explorer so there’s clearly a connection. One of Process Explorer’s features is its services-process highlighting. By default, it highlights in a beautiful pink color (I think anyway – I chose it :-) ) any processes that host Windows services. It also displays a services tab in the process properties dialog for those processes that shows you which services the process contains along with the descriptions of the services (if descriptions are available). Process Explorer gets this information by using the EnumServiceStatusEx function, which is the only way to obtain a mapping of services to their processes.

Unfortunately, the Service Control Manager for some reason queries the services Registry database (HKLM\System\CurrentControlSet\Services) to retrieve some of the other information returned by the API, rather than relying on its in-memory copy of the database - thus the polling. Attaching to Services.exe with Windbg results in a hang of both Windbg and Services.exe (if you use the symbol server) since Windbg relies on APIs implemented by Services.exe, so the only way to get a stack trace of one of the polling Registry queries is with a kernel debugger. This is a screenshot of the Compuware Numega Softice kernel debugger showing the stack of Services.exe when it’s querying the database in response to Process Explorer’s call to EnumServiceStatusEx.

A couple of posts ago I talked about the negative effects of polling the Registry and file system from an application. A developer on the MSN Desktop Search responded to the MSN Desktop Search polling example I presented by saying that they are fixing the problem and thanking me for reporting it. In hopes that someone from the Explorer team is out their listening I’m reporting on the Registry polling that I see Explorer performing on my system.

When I run Regmon I see Explorer query a set of subkeys under HKLM\System\CurrentControlSet\Services\Tcpip\Parameters twice per second:



The values include names like EnableDHCP, DhcpServer, and LeaseObtainedTime so Explorer is obviously interested in one of my adapter’s DHCP settings.

Why does Explorer care about DHCP settings? To answer this question I did the same thing I did when I investigated the MSN Desktop Search polling: I opened Windbg (from Microsoft’s Debugging Tools for Windows), attached to Explorer, and set a breakpoint on ZwQueryValueKey. ZwQueryValueKey is native API that the Windows Registry-value query-APIs use underneath. Looking at the stack of the thread that almost immediately hit the breakpoint revealed that Explorer isn’t directly querying:



Rather, Stobject.Dll, which describes itself as the “Systray shell service object” is executing a thread that executes CNetStatisticsCentral::RefreshStatistics in Netshell.Dll (the Network Connections Shell library) when a timer fires. The refresh function calls into HrGetDHCPAddressType, which calls GetAdapterInfoEx in Iphlpapi.Dll (the IP Helper API library). The GetAdapterInfoEx API, which incidentally is undocumented (much of the IP Helper API, including GetAdapterInfo, is documented in the Platform SDK) pulls parts of its information from the configured adapter information stored in the TCP/IP registry key, which results in the Registry queries.

The next question I had is, what in the system tray is related to adapter statistics? The answer was blinking at me right in the face in the form of the tray icon representing the network connection. The icon updates to show incoming and outgoing networking activity and the combination of the Registry trace and stack dump indicates that it relies on polling to get the information.

Is there a way to get adapter statistics without involving Registry polling? I suspect there is, but without seeing the source code I can’t say for sure. The work around is to uncheck the “Show icon in notification area when connected” check box in the properties dialog of the network adapter.

Anyone from Explorer out there?