Edit
  • Article

[Newsletters Archive ^] [< Volume 2, Number 3] [Volume 2, Number 5 >]

The Systems Internals Newsletter Volume 2, Number 4

www.sysinternals.com
Copyright © 2000 Mark Russinovich

August 30, 2000 - In this issue:

  1. EDITORIAL

  2. WHAT'S NEW AT SYSINTERNALS

    • ListDlls v2.23
    • HandleEx v2.26
    • ElogList v2.02
    • LoggedOn v1.1
    • Bluescreen v2.21
    • PageDefrag v2.01
    • LoadOrder v1.1
    • ClockRes v1.0
    • BgInfo v1.0
    • Inside Windows 2000, 3rd Ed.
    • Sysinternals at Microsoft

  3. INTERNALS INFORMATION

    • The power of the DEBUG privilege
    • New APIs in Win2K SP1?
    • WinDev 2000 West

  4. WHAT'S COMING UP

    • Tokenmon

CO-SPONSOR: WINTERNALS SOFTWARE

The Sysinternals Newsletter is sponsored by Winternals Software, on the Web at 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 Software's ERD Commander 2000 is the latest release in its award-winning ERD Commander product line. ERD Commander 2000's new features, including built-in Registry and file editors, make it the most advanced Windows NT and Windows 2000 recovery tool in existence. You can install ERD Commander 2000 on floppy disks, a CD-ROM, and even a system's hard drive for quick access, and its install wizard makes adding third-party SCSI and other mass storage drivers a breeze. ERD Commander 2000 is $349, or only $49 for existing ERD Commander Professional owners. Find out more and download the trial version at www.winternals.com/products/erdcommander2000.shtml.

CO-SPONSOR: WINDOWS 2000 MAGAZINE

Windows 2000 Magazine contains practical solutions for people who work with Windows NT/2000 everyday. Order a free sample issue now and without risk. If you decide to continue your subscription, you'll receive 13 more issues at 40% off the newsstand price. Subscribe today at: http://www.win2000mag.com/sub.cfm?code=fs00inhs13

Hello everyone,

Welcome to the Sysinternals newsletter. The newsletter currently has 25,000 subscribers.

I spend a lot of time in Regmon, Filemon and DebugView, tools that Bryce and I have developed at Sysinternals. Regmon is a Registry-access monitor (www.sysinternals.com/regmon.htm), Filemon is a file-access monitor (www.sysinternals.com/filemon.htm), and DebugView is a debug-output monitor (www.sysinternals.com/dbgview.htm). Occasionally, I'll come across an application or device driver installed on one of my several systems that generates continuous activity that's visible in one of these tools. I'm not talking about necessary activity, however the actions the software performs are usually of a repetitive nature and examination of the output traces reveals that the software uses a polling technique where the use of some other less intrusive mechanism is possible.

For example, various commercial virus scanners query their virus signature file several times a second to see if it has been updated. One of my systems has a printer driver from a major printer manufacturer that continuously outputs debug statements that, through their inclusion of the word "polling", advertise that they are polling. In one of my favorite examples, a utility advertised as improving system performance from a major utility vendor queries several of the vendor's Registry keys multiple times a second. An example of another type of sloppy coding is in a network adapter from a major networking vendor that includes a user-mode software component containing embedded debug breakpoints that continuously trip as the software executes. If an application needs to detect a change to file it can request a directory-change notification. Similarly, it if needs to detect changes to a Registry key it can request a key change notification, and commercial software should never contain debug output or debug breakpoints that are enabled by default.

Perhaps the most egregious example, however, is the Microsoft Windows Media Program Service that comes bundled with Windows 2000 Server (\Winnt\System32\Windows Media\Server\Npsm.exe): it reads the first 2 KB of \Winnt\System32\Windows Media\Server\ASDB\mdsas.mdb at the rate of about 60 times per second on a system where there is otherwise no activity (including no media serving). There's no excuse for this, especially since this can adversely impact the overall performance of the server.

I'm sure that if you've used Regmon, Filemon or DebugView for any length of time you've probably come across similar examples. When you see one, don't just set a filter and forget about it, e-mail the vendor complaining about their sloppy programming.

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

Thanks!

-Mark

WHAT'S NEW AT SYSINTERNALS

LISTDLLS V2.23

ListDLLs is a command-line utility that shows you detailed information about the DLLs that processes have loaded. For example, ListDLLs displays the base memory address, size, version, and complete path of each DLL. This new version shows you the command-line that was used to launch a process, including any parameters that were passed on the command-line. This can help you distinguish between multiple processes and troubleshoot problems related to specific command-line options.

Download ListDLLs v2.23 at www.sysinternals.com/listdlls.htm.

HANDLEEX V2.26

HandleEx is an application that presents information about which handles and DLLs processes have open or loaded. Its display consists of two sub-windows. The top always shows a list of the currently active processes, including the names of their owning accounts, whereas the information revealed in the bottom window depends on the mode that HandleEx is in: if HandleEx is in handle mode you'll see the handles that the process selected in the top window has opened; if it is in DLL mode you'll see the DLLs and memory-mapped files that the process has loaded.

The latest release of HandleEx includes several new features. First, like ListDLLs, it now shows the command-line that was used to launch a process when you view the process' properties.

One of the shortcomings of HandleEx prior to this version was that, although it displayed the name of the account in which system processes and processes of your login session were executing, it was incapable of circumventing the Windows NT/2000 security model to show the owner of processes started from other user accounts (the Pview program from the Windows NT/2000 Resource Kits also suffers this limitation). This was painfully evident in NT 4 Terminal Server and Windows 2000 Terminal Services environments, where HandleEx indicated that processes started from other user sessions had unknown owners. HandleEx v2.26 implements a trick so that it can determine the owning account for all processes, without exception, making it an ideal tool for Terminal Services environments.

The final new feature of HandleEx v2.26 allows you to force closed any open handle. I added this feature after receiving many requests for it. I recommend that you use it with extreme caution, however, because applications generally aren't written to expect that handles might suddenly become invalid, and applications with handles forced closed may behave erratically or crash as a result.

Download HandleEx v2.26 at www.sysinternals.com/handleex.htm.

ELOGLIST V2.02

The Windows 2000 Resource Kit include a tool named ELogDmp that lets you dump records from an event log on the local or a remote computer. ELogList more powerful than ElogDmp because it also lets you specify an optional account name and password so that you can access a computer's event logs from a different account than the one from which you are running the tool. In addition, whereas the ElogDmp tool shows event log entries in their raw form, making the output difficult to interpret, this ElogList update formats event log entries to show text as it appears in the Windows NT/2000 Event Viewers. Even when you display event logs from remote systems, ElogList uses the correct message files on the remote system for its formatting string data.

Download ElogList v2.02 at www.sysinternals.com/eloglist.htm.

LOGGEDON V1.1

LoggedOn is a command-line applet tells you who is logged onto a particular computer, either locally or via resource shares. The version 1.1 update lets you search your network for logon sessions associated with a particular user. This feature is useful in situations where you want to perform updates to a user account and need to verify that the user is not currently logged on.

Download LoggedOn v1.1 with full source at www.sysinternals.com/misc.htm.

BLUESCREEN V2.21

Most of you are by now no doubt familiar with the famous Sysinternals Blue Screen screen saver, which accurately depicts a Windows NT or Windows 2000 crash and reboot. Since its initial release I've continuously received requests from Windows 9x users that want to run the screen saver on their computers, so I've finally ported it to Windows 9x. On Windows 9x it simulates a Windows 2000 crash and reboot.

The only requirement for using the Sysintenals Blue Screen screen saver on Windows 9x is that you obtain a copy of a Windows 2000 Ntoskrnl.exe file to place in the \Windows\System directory - Blue Screen requires the file for the Windows 2000 splash screen.

Now you can really confuse unsuspecting Windows 9x users that come back to their computer only to discover that it's stuck in a Windows 2000 crash and reboot cycle!

Download Bluescreen Screen Saver v2.21 at www.sysinternals.com/bluescreen.htm.

PAGEDEFRAG V2.01

PageDefrag is a defrag utility that runs at boot time to defragment your system's paging files and Registry hives. PageDefrag was the first utility able to defragment Registry hives, but since its release that functionality has been added to several commercial defraggers. However, PageDefrag is still free, and version 2.01 works on Windows 2000 as well as Windows NT 4.

If you're interested in the defrag interface provided by Windows NT 4 and Windows 2000, you can learn about it and download source code to an interactive file defragmenter at www.sysinternals.com/defrag.htm. Sysinternals documented the defrag interface years before Microsoft included it in the Platform SDK, and several commercial defragmenters made use of our documentation and sample code.

Download PageDefrag v2.01 at www.sysinternals.com/pagedfrg.htm. View the defrag interface documentation at www.sysinternals.com/defrag.htm.

LOADORDER V1.1

Have you ever wondered in what order device drivers and services load and initialize? Now you can easily find out. LoadOrder is a utility that processes the information under HKLM\System\CurrentControlSet\Services to build a picture of driver and service load order.

Download LoadOrder v1.1 at www.sysinternals.com/misc.htm.

CLOCKRES V1.0

In my articles on the scheduler I've talked about the fact that Windows NT/2000 thread quanta (the length of a thread's turn to run on a CPU) is based on the resolution of the system clock. The clock's resolution also affects the latency of Windows timer-based events. The article at www.sysinternals.com/timer.htm even discusses the way that the applications can manipulate the resolution of the clock. On most SMPs, the resolution is 15ms, and on uniprocessors its 10ms, values that are set by the standard SMP and uniprocessor HALs (Hardware Abstraction Layer).

While most systems uses the common values listed above, how can you determine the actual resolution of the clock on your computers? The answer lies in the GetSystemTimeAdjustment Win32 API, which tells you whether the system is applying a periodic adjustment to the time-of-day clock. It just so happens that this API also returns the interval of the clock. The ClockRes applet uses the API to tell you the resolution of a system's clock.

Download ClockRes plus source at www.sysinternals.com/misc.htm.

BGINFO V1.0

If you are an administrator in charge of multiple servers you probably spend a significant amount of time popping open various information dialogs to remind yourself of the values of various system properties such as installed service pack version, IP addresses, computer name, memory size and processor speed. Now you can have all this information in plain view on each server's desktop using the BgInfo utility that Bryce developed.

When you run it, BgInfo creates a desktop background that automatically reports a variety of useful system characteristics. You can put BgInfo in your Start folder so that the information is available to you whenever you log in, and you can modify the data that BgInfo shows, even adding your own. With BgInfo installed on your servers you'll save the time you spent repeatedly looking up easily forgotten information.

Download BgInfo v1.0 at www.sysinternals.com/misc.htm.

INSIDE WINDOWS 2000, 3RD EDITION

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.

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

SYSINTERNALS AT WWW.MICROSOFT.COM

I don't have any new KB articles that reference Sysinternals to report, but Microsoft has added some pretty high-profile links to Sysinternals in the TechNet part of its site. The first is in the "Ask Us About...Security" column at www.microsoft.com/TechNet/security/au022800.asp, where columnist Joel Scambray warns readers that NTFSDOS (www.sysinternals.com/ntfspro.htm) can be used by a malicious user to alter the contents of a Windows 2000 Domain Controller's Active Directory.

The second reference is in the "Inside Microsoft" column at www.microsoft.com/technet/inside/default.asp. The column is Q&A-style and starts with two questions related to determining out what application has a particular file opened. In the course of answering, where readers are pointed at HandleEx (www.sysinternals.com/handleex.htm) and NtHandle (www.sysinternals.com/nthandle.htm), the article's author (the "Mole") states this about Sysinternals: "There is just a TON of great utilities theremany that won't cost you a dime. Even the Mole refers to Sysinternals from time to time (What? You thought perhaps Mole keeps all this information in his head?). Once again, this is where he going to send you." This is about as close to an official endorsement of the site by Microsoft as we can expect.

INTERNALS INFORMATION

THE POWER OF THE DEBUG PRIVILEGE

Unlike other debug output monitors, including dbmon, my DebugView debug-output monitor (www.sysinternals.com/dbgview.htm) requires local Administrator privileges for execution, because it installs a device driver that captures kernel-mode debug output. As a result, I've received dozens of e-mails from developers complaining that their management won't give them local administrator privileges, only the Debug privilege. The argument goes that the Debug privilege is there for a reason, and its all application developers need to develop. These developers ask me to change DebugView so that it only installs the driver if the user has administrator privileges, and otherwise just collects Win32 debug output.

These requests always give me a chuckle, because what the management that makes the Debug-privilege argument fails to realize is that this privilege opens the door to local administrator privileges. Using the Debug privilege a developer can have a debugger attach to the Local Security Authority process (LSASS) and manipulate it so as to give them local administrator privileges on their next login. Or they can inject code into any process running in the System account that would add their account to the local administrators group. When I explain this to the complaining developers they sometimes respond that their management doesn't buy the argument. Until now, I haven't had anything for them to take back to their management to make their case, but a recent rash of such e-mails has prompted me to take action.

LogonEx, a utility you can download at www.sysinternals.com/logonex.zip, graphically exhibits the clout of the Debug privilege. LogonEx works on Windows NT and Windows 2000. In order to best show it off, create an account that is a normal user account except with the addition of the "Debug Programs" privilege. Log off and login under that account and run LogonEx. You'll need the symbol file(s) for msv1_0.dll for your particular installation (developers usually have system symbols installed), which LogonEx uses to locate the entry point of the MsvpPasswordValidate function and patch it. After LogonEx makes its patch you'll be able to login to the system using any account without specifying a password. Complete the demonstration by logging in as an administrator and adding the account you created to the local administrators group.

LogonEx is just one example of how the Debug privilege enables a developer to take control of a system, but there are plenty of others. I hope that LogonEx convinces management that it doesn't make any sense to not give developers local administrator privileges (Note, however, that I'm not talking about domain administrator privileges, which is another story a local administrator reigns supreme only over their own computer, not any others, whereas a domain administrator rules a network).

NEW APIS IN WIN2K SP1?

After many users encountered problems with NT 4 service packs (SP) causing new bugs, Microsoft adopted a policy of not including any new functionality in a SP in order to minimize the chance that they would introduce new problems while fixing old ones. Or so we thought. Windows 2000 SP 1 was recently released and appeared not to have any new functionality. However, a detailed inspection of Ntoskrnl.exe, the file that contains the Windows 2000 executive and kernel components, and Ntdll.dll, the library that contains the Native API and loader, reveals that a new API made its debut in SP 1.

The new API consists of the following functions:

   RtlTraceDatabaseAdd
   RtlTraceDatabaseCreate
   RtlTraceDatabaseDestroy
   RtlTraceDatabaseEnumerate
   RtlTraceDatabaseFind
   RtlTraceDatabaseLock
   RtlTraceDatabaseUnlock
   RtlTraceDatabaseValidate

The names of the functions are pretty descriptive, so this is clearly an API for logging events. An interesting aspect of the API is that its implementation is duplicated in Ntdll and Ntoskrnl this is different than other Ntdll APIs that call upon the services of an implementation in Ntoskrnl.

Examination of the API's implementation shows that it's used like this: an application creates a trace database, which is stored in the application's virtual memory, and adds entries to the database. At some point the application can enumerate the contents of the database, and when it's done with the database it deletes it. Oddly, there doesn't appear to be a way to delete database entries.

What makes use of this new API? Nothing that's installed on my fairly full-features Windows 2000 Advanced Server installation, so its not clear that anything does. Perhaps this was a debug API that was accidentally included in the SP 1 release code.

Published Wednesday, August 30, 2000 7:07 PM by ottoh

[Newsletters Archive ^] [< Volume 2, Number 3] [Volume 2, Number 5 >]