Volume 3, Number 1

Copyright (C) 2001 Mark Russinovich

April 18, 2001 - In this issue:


- PsService v1.01
- PsFile v1.0
- PsExec v1.11
- HandleEx v4.0
- DebugView v4.11
- Inside Windows 2000, 3rd Ed.
- February Windows 2000 Magazine
- Sysinternals at Microsoft

- Cool keyboard shortcuts
- PnP debug messages
- Reverse engineering ruling
- New Windows XP system calls
- Disconnected networking
- WinDev
- TechEd US

- Inside Windows XP prefetching

The Sysinternals Newsletter is sponsored by Winternals Software, on the Web at https://www.winternals.com. Winternals Software is the leading developer and provider of advanced systems tools for Windows NT/2K. Winternals Software products include FAT32 for Windows NT 4.0, NTFSDOS Professional Edition (a read/write NTFS driver for DOS), and Remote Recover.

Winternals is proud to announce Defrag Commander NE version 1.2, a low-cost easy-to-use enterprise defragmentation solution that adds NT 4 support to its existing Windows 95/98/Me and Windows 2000 support. Defrag Commander NE leverages the built-in defragmenters of Windows 2000 and Windows 95/98/Me, and adds its own powerful defragmenter for Windows NT 4. Now you can manage defragmentation schedules across your entire Windows enterprise from a simple MMC snapin - without even having to install any client software on your NT or Windows 2000 systems. A 10-system license is available for on-line purchase for only $169, and aggressive quantity discounts are available. Visit https://www.winternals.com for more information.

Hello everyone,

Welcome to the Sysinternals newsletter. The newsletter currently has 31,500 subscribers.

One of the first things you notice when you install a beta of Windows XP is the redesigned user interface, named Luna. The Luna look-and-feel pervades all aspects of the interface, from the behavior of the startup menu, to the design of application menus and dialog boxes. This total conversion is achieved through the use of a "themes" engine. Themes are described in theme style files (files that end in .msstyles) and the Luna theme file, luna.msstyle, is located in \Windows\Resources\Themes\Luna. Under the same directory you'll find a subdirectory named Shell, in which shellstyle.dll is located. It's not clear how XP uses the DLL - its loaded by Explorer and has an HTML style sheet buried in it, but no exports. Because comdlg.dll and kernel32.dll import it, and every application gets a copy of these DLLs, every process also gets a loaded copy of \Windows\System32\UxTheme.DLL, the themes client library. This DLL exports functions like IsThemeActive, IsAppThemed, GetCurrentThemeName, DrawThemeBackground, and GetThemeColor.

The Registry is where the current theme is specified and theme pervasiveness configured. Look under HKEY_CURRENT_USER\Software\Microsoft\Plus!\Themes and you find a key named Apply where you see values like "colors" and "icons" that specify where the theme should be active. Under the same key the Current subkey has the path to the .msstyles file for the current theme.

Given that "skinning" has become the rage for applications like WinAmp and Windows Media Player, you'd assume that Microsoft would publish a tool that let's third parties develop their own themes, or at least document the format of the .msstyles file and shellstyle DLL so that third-parties could develop theme editors. You'd be wrong, however. In "Microsoft Windows XP: What's in It for Developers?" (posted online at https://msdn.microsoft.com/library/default.asp?URL=/library/techart/winxpintro.htm), Microsoft makes it clear that they have no intention of allowing third-party themes:

"At first glance, the potential for multiple Windows XP styles may look like the skin functionality in such applications as Window Media Player, but there are differences. Themes change the visual style of the operating system, but still provide a consistent UI with earlier versions of Windows. This is important since themes are applied system-wide. The changes applicable to an application skin, such as removal of buttons, are not appropriate at the operating system level. The theme file formats are not public; Microsoft retains the design control for themes, to allow a consistent user interface and ensure design continuity. A theme developer's kit will not be available with Windows XP."

The argument I'm sure they make for such a stance is that third-party themes might somehow break the UI, and users would call Microsoft support for help. Why they don't have the same fear with Windows Media Player, I don't know. Nevertheless, there are ways to apply a theme-like appearance to the desktop and applications. Visit https://www.wincustomize.com/ to find Windows desktop skins, like the new Aqua-Soft (a WindowBlinds skin - https://www.windowblinds.net) that gives Windows the look and feel of Apple's OS X desktop. And given the skinning community's persistence at figuring out how to skin everything released, I'm sure that there are people right now reverse engineering Microsoft's theme format. It's only a matter of time before someone releases a theme editor, regardless of Microsoft's policy on controlling themes.

So what will Microsoft do when Windows XP theme editors and third-party themes start appearing? We'll have to wait and see, but Apple's behavior might be giving us a preview. A few days ago Apple issued a company developing a theme editor for the Mac OS a cease and desist order: https://www.macworld.co.uk/news/main_news.cfm?NewsID=2773. Theme developer beware.

Please pass the newsletter to friends you think might be interested in its content.



========== WHAT'S NEW AT SYSINTERNALS ==========
The NT 4 and Win2K Resource Kit's have had a command-line service control utility, SC, for as long as I can remember. SC lets you view and change the state and configuration of Win32 services on the local or remote systems. PsService is a freeware clone of SC that has a few extra features.

The first is that PsService lets you connect to remote systems using alternate user credentials. This is useful in cases where the account from which you run it doesn't have administrative privileges on the remote system, but you have access to an account that does. The second is PsService's search capability. If you've ever forgotten which system in your network is running the DNS, DHCP, or some other service, you'll find the search facility useful, because it lets you specify a service name and reports the computers running the service.

PsService relies on the Service Control Manager API, for which you can find complete documentation in the Platform SDK, and PsService requires no client software installation.

Download PsService v1.01 at https://www.sysinternals.com/ntw2k/freeware/psservice.shtml.

PsFile is a tool that I created in response to requests for something that overcomes the limitations of the "net file" command in Windows NT/2K. You can use the built-in "net" command on NT and Win2K with the "file" option to list the files that other computers have opened on shares exported by the system. However, the net command truncates long path names and only works on the local system.

PsFile uses the same APIs (appropriately enough, the "Net" API, which is documented in the Platform SDK) as the net command, but it doesn't truncate file names and works both locally and remotely, with no need for client software installation.

Download PsFile v1.0 at https://www.sysinternals.com/pstools.htm.

PsExec is a command-line application for Windows NT/2K that lets you execute programs on remote systems. What makes it especially powerful is that it remotely-enables console programs so that you can run them interactively. For example, if you launch the command prompt executable (cmd.exe) on a remote system using PsExec you effectively have a remote shell - and you don't need to install any client software.

Besides serving as a lightweight telnet, PsExec allows you to remote-enable "local only" applications. IpConfig, the built-in tool that shows you the networking configuration of a system, isn't able to show you the configuration of remote systems. With PsExec, however, you can launch it remotely and view its output locally.

In some cases the account in which an application runs is important. The application might need to run in your account so that changes it makes to the Registry or files occur in the correct security context. In other cases it might be desirable to run the application in a different one than the one in which you run PsExec, and yet other times you might want to have the remote application run in the System account. PsExec supports all these situations.

By default, PsExec executes programs in an "impersonated" security context. This means that if you run PsExec in the administrator's account, the remote process will run in the administrator's account. Due to restrictions on the power of impersonation, the remote process won't have access to network resources on the remote system. If you specify a username and password on PsExec's command line, PsExec launches the remote process in the alternate account, and the remote process has access to any network resources that are accessible from that account. Finally, a command-line option lets you direct PsExec to run the remote process in the System account - the same account that Win32 services run in.

Download PsExec v1.11 at https://www.sysinternals.com/ntw2k/freeware/psexec.shtml.

HandleEx is a multifaceted tool that shows you the list of processes active on a computer, as well as the handles to operating system resources they have open and the DLLs they have loaded. Its search facility and detailed presentation of process, handle, and DLL properties make HandleEx the perfect tool for tracking down DLL version problems, handle leaks, and the process that is accessing a particular file or directory.

If you've been following Sysinternals updates, then you'll note that HandleEx has jumped two major version numbers in the past several months. The first major update, v3.0, introduced a number of features such as application icons in the process view, tooltips for all listview items, a much more efficient refresh, and an improved search feature where you can click on result items in the find dialog and have HandleEx jump to the appropriate handle or DLL entry.

Perhaps the most useful features for developers, however, are "refresh highlighting" and relocated-DLL highlighting. Refresh highlighting refers to HandleEx's behavior when you refresh the view. New items, including processes, handles, or loaded DLLs, that weren't present before the refresh are highlighted in green, whereas items that no longer exist are highlighted in red. Besides visually tipping you off to changes, this lets you vividly see handle leaks in progress, where newly opened handles show up in green after a refresh.

HandleEx relocated-DLL highlighting is related to DLL relocation, a the term that describes the behavior of the module loader in Windows where it can't honor the preferred "base address" developers specify when they build a DLL. The code that a linker (the tool used for the final phase of DLL or EXE building) produces for a DLL has intra-DLL memory references set with the assumption that the loader will honor the DLL's base address. The range of memory in the process loading a DLL that starts at the base address and accommodates the size of the loaded DLL image must be free for the DLL to load at its preferred base address. When the base address is honored for several processes, memory-usage efficiency is achieved because all the processes share the same DLL code memory.

When the loader cannot honor a DLL's base address, for instance when another is already using the desired address range, the loader must perform "relocation", which involves updating all the intra-DLL memory references to reflect the DLL's actual load address. Besides slowing the load time of the process (usually imperceptibly), the relocated DLL image cannot be shared with other processes that have the DLL loaded at the preferred base address. This means that you effectively get a second copy of the DLL consuming memory.

When you're in DLL mode you can select the "Highlight relocated DLLs" option, resulting in HandleEx showing entries for DLLs that are not loaded at their preferred base address in yellow. Developers can reset their DLL base addresses to avoid relocations.

What about HandleEx's jump to version 4.0? This latest version of HandleEx brings complete handle viewing to the Win9x/Me platform. Now you can select a process and see the handles that they have open, the same as you can when you run HandleEx on WinNT/2K/XP. Not only that, but also like on WinNT/2K/XP, viewing the properties of events, mutexes, and semaphores reveals information about their state (held, signaled).

Download HandleEx 4.0 at https://www.sysinternals.com/ntw2k/freeware/handleex.shtml.

DebugView is a developer utility that lets you capture debug output from applications or drivers on the local system or a remote one - even from multiple systems simultaneously. This latest release adds compatibility with Windows XP Beta 2, some usability features and a feature aimed at device driver developers on WinNT/2K/XP.

DebugView's filtering dialog lets you define include and exclude filter masks to narrow in on the debug output you're interested in seeing. In addition, you can specify up to 5 different highlighting filters, each with a different customizable color. Previously, if you had projects that required different filters you had to reenter the filters each time you switched projects. With DebugView 4.11 you can save filters to a file for quick reload. Like before, DebugView starts with the filters that you had active the previous time you exited it.

Sometimes its necessary to capture a debug output trace for later analysis, or comparison with other traces. Prior to the new version of DebugView the only way to view a log file was to load it into a text editor, which meant that you couldn't apply helpful highlighting filters. Now you can load a DebugView log file back into DebugView, making it possible to see the output the way you saw it when you originally captured it. Using multiple DebugView windows lets you compare traces.

The final new feature, boot-time logging, compliments DebugView's crash dump support in NT/Win2K. With DebugView's crash dump support you capture output from a device driver, and if the driver crashes the system and you have crash dumps enabled (full or kernel), use DebugView to extract the driver's debug output from the dump - letting you see the driver's output right up to the point of the crash.

Boot-time logging lets you capture output from drivers that load during the boot process as boot-start or system-start drivers. The DebugView driver captures and buffers up to 1 MB of debug output during the boot after you enable boot-time logging. After the system is up, running the DebugView application imports the buffered output for viewing. And if your driver crashes during the boot and you have crash dumps enabled, DebugView's crash dump support lets you see the output the driver generated prior to the crash.

Download DebugView v4.11 at https://www.sysinternals.com/ntw2k/freeware/debugview.shtml.

The official book on the internals of Windows 2000 is now available! This edition, coauthored by David Solomon (www.solsem.com) and Mark Russinovich, is over 40% larger than the previous, with new coverage of networking, plug-and-play, power management, services, the Registry, WMI, boot and shutdown, and storage. It also includes a CD with several powerful tools, not available anywhere else, for investigating Windows 2000 internals.

If you go to the Amazon.com page for the book, https://www.amazon.com/exec/obidos/ASIN/0735610215/o/qid%3D957490318/sr%3D8-1/ref%3Daps%5Fsr%5Fb%5F1%5F1/103-5793119-3499040/systemsinternals/107-2386425-6078131, you'll note that just two reviews have been posted since the book's release in September. If you have the book, we strongly encourage you to share your opinions with other prospective readers.

See the book's table of contents and order now through https://www.sysinternals.com/insidew2k.htm.

Check out the February issue of Windows 2000 Magazine for my article on NT/Win2K crash dump analysis. The article starts by taking you through the basics of configuring crash dumps and explains how the operating system creates a crash dump (with hints about why a dump might fail to generate). Then I explain where you can get the latest dump analysis tools and walk through the use of a powerful new Microsoft utility, Kanalyze. Finally, I take quick look at using a kernel debugger to examine a dump. Even if only a small fraction of dumps reveal their cause with analysis, you should find the information useful.

The article is posted online through a link at https://www.sysinternals.com/publ.shtml, where you can find links to all our publications.

Sysinternals has made an appearance in yet more Microsoft Knowledge Base
(KB) articles since the last newsletter, bringing the total that I've found referencing Sysinternals tools to 17.

Q274038: PRB: ASP Error 8002801d "Library not registered"
This article directs users to Regmon to troubleshoot Active Server Pages errors.

Q232830: HOWTO: Determine File Handle Ownership
Want to know what process has a file opened? This KB article directs you to HandleEx.

Q2163868: PRB: Access Violation During Application Setup When File In Use
Visual Basic Setup applications can crash if a file they are attempting to copy is in use. HandleEx makes the ideal tool for tracking down the process that's interfering.

Q286198: HOWTO: Track "Permission Denied" Errors on DLL Files
Using Filemon (the article also mentions Regmon) you can see which process of a COM or MTS application is getting an "access denied" error.

Q246199: BUG: Changed Locale Settings in Extended Stored Procedure May Cause Incorrect Results
This article recommends using ListDLLs to see what version of the C-runtime library SQL Server is using.

Q196453: Troubleshooting NTVDM and WOW Startup Errors
Users experiencing problems when they start 16-bit applications are pointed to Filemon to see what files the 16-bit environment subsystem (NTVDM) has errors accessing.

================== INTERNALS INFORMATION =============

Many of you probably view the Windows key on newer keyboard as a key simply taking up space. I was that way until recently, when I stumbled upon a Windows-key keyboard shortcut for an operation that I frequently perform, and now I'm wearing the logo off the key with my frequent usage. I thought that I'd share some keyboard shortcuts I find useful, all of which work on all versions of Windows.

Launch task manager ctrl+shift+escape
Display System Properties dialog Windows+Break
Minimize all windows Windows+m
Maximize all windows Windows+M
Open My Computer Windows+e
Search for a file Windows+f
Open the run dialog Windows+r

After I determined these through trial and error, David Solomon pointed out that they're documented in Windows 2000 help under "Natural Keyboard shortcuts".

If you're developing plug-and-play drivers for Windows 2000 you might be surprised to learn that you can coax even the retail build of Windows 2000 to produce extensive plug-and-play system debug messages during its enumeration and driver loading process. Have your kernel debugger break at the start of the system boot and set the internal kernel variable PnpEnumDebugLevel to 2 (most messages trigger with a level of 1). Here's an example of the output you'll see, which shows the PnP Manager loading the swenum driver (software enumeration bus driver):

IopCallDriverAddDevice: Processing devnode 0xfe503208
IopCallDriverAddDevice: DevNode flags going in = 0x000019
IopCallDriverAddDevice: Will load driver
IopCallDriverAddDevice: Opening registry key Root\SYSTEM\0000
IopCallDriverAddDevice: Class GUID is {4D36E97D-E325-11CE-BFC1-08002BE10318}
IopCallDriverAddDevice: Unable to open GUID\Properties key {4D36E97D-E325-11CE-BFC1-08002BE10318} - 0xc0000034
IopCallDriverAddDevice: Value Service [Type 1, Len 14] @ 0xe14ee82c
IopCallDriverAddDevice: Service Name swenum
IopCallDriverAddDevice: DriverName is \Driver\swenum
IopCallDriverAddDevice: Driver Reference 0xff3a8af0
IopCallDriverAddDevice: Adding Services (type 0)
IopCallDriverAddDevice: Adding Services (type 1)
IopCallDriverAddDevice: Adding Services (type 2)
IopCallDriverAddDevice: Adding driver 0xff3a8af0
IopCallDriverAddDevice: Routine returned 00000000

Those of you that have followed Sysinternals know that I don't have access to any Windows source code (other than for the driver sources that ship in the DDK), and that I learn the intricacies of its implementation through laborious use of SoftICE and my own custom disassembler.

I've come across a an article, "Reverse Engineering: Necessary Function or Illegal Activity?" (https://www.planetit.com/techcenters/docs/security/news/PIT20010123S0001), that describes a January ruling by the 9th U.S. Circuit Court of Appeals in a case between Sony and Connectix that will interest those of you that do likewise. Sony brought the case against Connectix after Connectix developed its "Virtual Game Station", a program that lets you run Sony PlayStation games on a PC, and the court ruled that Connectix was within the law when it reverse engineered the PlayStation (through disassembly) so as to allow them to develop their emulator.

While the scope of the legality of reverse engineering, especially considering shrink-wrap licenses that prohibit it, is still vague, this case comes down on the side of reverse engineering.

Unlike the move between NT 4 and Windows 2000, the Windows XP kernel has undergone more subtle changes, many of which are aimed at performance improvements. The kernel APIs available for driver developers have fleshed out with over 200 new exported kernel functions, filling in some previous holes. For example, Filemon and other Sysinternals tool obtain the name of the process performing an operation by reaching into the undocumented process environment block - in Windows XP they'll be able to call PsGetProcessImageFileName. There are almost 3-dozen new Ps-calls for obtaining and setting process attributes, new debug output APIs that let you classify the output type and debug level, and a new system call for saving Registry hives. There are also a handful of APIs like ZwQueryBootOptions, ZwSetBootEntryOrder, and ZwDeleteBootEntry for editing the 64-bit Windows XP-equivalent of Boot.ini, which instead of being stored in a file, is stored on nonvolatile memory.

However, there are more significant changes on top of the kernel, most of which rely on device drivers or kernel support. For example, there is a system restore service which, with the aid of a file system filter driver (sr.sys), keeps track of changes to files so that the system can be rolled back to a previous point in time. There's a storage filter driver named volsnap.sys that can, with the cooperation of file system drivers, make a point-in-time copy of a volume. There's a fast user switching service that uses terminal services support built in to the kernel to allow multiple users to be logged in and switched between, and improved defragmentation API support provided by the file system drivers.

Microsoft has published a white paper that describes many of the enhancements at https://www.microsoft.com/hwdev/Whistler/download/Whistler_kernel.zip. There are varying degrees of detail, leaving many questions on implementation and behavior unanswered, but it's a fairly good overall review. Of course you can look to future Sysinternals newsletters and articles, and my Windows 2000 magazine articles, to answer some of them.

Much of my development centers on network-enabled applications, but on Windows 2000 you can't test such applications when you boot up a disconnected computer (like a laptop) in the default configuration. That's because the TCP/IP stack is not activated unless the system detects a network connection. This means for instance, that "dir \\laptop\c$" (where "laptop" is the name of your computer) and "ping" both fail on disconnected systems. If you have a domain-based computer this can also lead to painful delays during boot up.

There are two workarounds to this. One is to install the Microsoft loopback adapter, which is a virtual network adapter installable using the Hardware Wizard. The second is to disable media sense, which prevents the system from detecting that its disconnected, by setting a Registry value as described in Microsoft KB article Q239924: https://support.microsoft.com/support/kb/articles/Q239/9/24.ASP. With either of these approaches the TCP/IP stack is active even on disconnected systems, letting you access the local system via networking APIs and UNC paths (like \\laptop\c$).

Windev, the Windows developer's conference, is being held this year in Boston June 11-15. All the top names in Win32, systems, and .NET programming will be there, and this is the only time this year that you can attend a session on Windows 2000 internals presented by both David Solomon (www.solsem.com) and me. Dave and I are jointly delivering the day-long "Inside Windows 2000 Fundamentals" tutorial on the first day. I'm also teaching a session on programming interprocess communications mechanisms in Windows and one on what's new in Windows XP.

You can see the abstracts to my talks and find a link to the Windev Web site at https://www.sysinternals.com/ntw2k/info/talk.shtml.

TechEd is Microsoft's premier conference, drawing 10,000 people and selling out for the last several years. This year its being held in Atlanta, Georgia from June 17-21, and while the focus is on .NET, Microsoft has invited me to present "A Tour of Sysinternals Tools" and "Introduction to Windows NT/2000 Crash Dump Analysis". David Solomon will also be there, presenting on Windows 2000 memory management and process and thread internals.

For those of you in Europe, you can see David and me present the same sessions at TechEd Europe, which is in Barcelona July 3-6.

View my abstracts and follow a link to the TechEd home page from https://www.sysinternals.com/ntw2k/info/talk.shtml.

================ WHAT'S COMING UP =================

One of the most noticeable enhancements in Windows XP is its fast boot times. Prefetching is the basis of the improvement. XP monitors disk access during a boot, storing the information for use in the subsequent boot where it uses the data to load applications into memory before they are referenced. Next time I'll go inside the prefetching mechanisms to explain how XP implements them.

Thank you for reading the Sysinternals Newsletter.