Edit
  • Article

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

The Systems Internals Newsletter Volume 4, Number 1

http://www.sysinternals.com
Copyright (C) 2002 Mark Russinovich

January 7, 2002 - In this issue:

  1. EDITORIAL

  2. WHAT'S NEW AT SYSINTERNALS

    • Sync v2.1
    • DiskExt v1.0
    • NTFSDOS v3.02
    • PsSuspend v1.2
    • PsLogList v2.2
    • PsInfo v1.2
    • PsExec v1.3
    • BgInfo v2.0
    • Process Explorer v5.2
    • Filemon v4.34 for Win64/Itanium
    • Filemon v1.1 for Linux
    • Sysinternals at Microsoft

  3. INTERNALS INFORMATION

    • Inside Windows 2000, The Interactive DVD
    • Inside Windows 2000/XP: The Seminar
    • Windows XP Manifest Files
    • What's in an X-Box?
    • Random Windows XP Statistics
    • New Improved Windbg

  4. WHAT'S COMING UP

    • Using BootVis to profile the Windows XP boot process

SPONSOR: WINTERNALS SOFTWARE

The Sysinternals Newsletter is sponsored by Winternals Software, on the Web at http://www.winternals.com. Winternals Software is the leading developer and provider of advanced systems tools for Windows NT/2K/XP. Their products include the award-winning Administrator's Pak, ERD Commander 2000, and NTFSDOS Professional Edition.

Winternals is proud to announce Defrag Commander version 1.32, the fastest, most thorough enterprise-defragmenter available. 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 http://www.winternals.com/39 for more information or to download and use free for 30 days.

Hello everyone,

Welcome to the Sysinternals newsletter. The newsletter currently has 34,000 subscribers. Please pass the newsletter to friends you think might be interested in its content.

Windows XP, Microsoft's flagship operating system, went "gold" in late August. Windows XP is the latest release of the Windows NT line that started with Windows NT 3.1 in 1993, and it builds on the technological evolutions and innovations of the past eight years. The operating system definitely represents the cutting edge in terms of functionality and features, many of which David Solomon and I studied and wrote about in the December MSDN Magazine article "Windows XP: Kernel Improvements Create a More Robust, Powerful and Scalable OS" ( http://www.msdn.microsoft.com/msdnmag/issues/01/12/XPKernel/XPKernel.asp ).

And with millions of installed Windows NT and Windows 2000 systems, and hundreds of thousands or millions of beta testers, you'd expect Microsoft to have tweaked, tuned and fixed Windows XP to run virtually flawlessly. After all, their advertisements tout XP as being "virtually crash proof". I certainly never expected to run into problems - but I was wrong.

I kept Windows 2000 Professional as the operating system on my primary system throughout the XP beta and release candidate cycle. I had learned from the Windows 2000 development cycle that even release candidates leave behind debug cruft after upgrading to the final bits. When I received build 2600, the final release, from the beta program, I decided it was time to move. The XP compatibility wizard found only minor issues on my Windows 2000 system (like that the version of Partition Magic I had installed did not understand XP NTFS) so I proceeded with the upgrade path.

After running in text-mode and installing setup files to my hard disk, XP Setup rebooted into my partially-upgraded Windows XP installation to complete the upgrade in graphical mode. It's in this mode that you specify locale and time zone settings, Setup performs device detection, and you configure your network. Things went smoothly until the "Installing Devices" phase. When the progress bar hit about 2/3rds and Setup reported that time remaining was 34 minutes, Setup ceased being productive. The "XP is the best thing that's ever happed to you" banners continued to alternate and the little flashing buttons in the lower right continued to rotate, but even two hours later I still had 34 minutes left to go.

That's when I began to worry. Several frantic hours of trying every thing I could to get past the problem, including rebooting to let Setup try again, updating the BIOS, checking the MS Knowledge Base (nothing), yielded no result. I finally gave in, scratched the half Windows 2000-half Windows XP installation, and performed a fresh install of XP, spending the better part of a day reinstalling the couple of dozen applications I use.

Things with my new XP installation were good. Not to say that I haven't been disappointed with unexplained crashes, GUI flakiness and otherwise strange system behaviors, but at least I could be productive. I knew that the beta program CD was a trial CD, and that I'd have to upgrade to the full version when I received it through MSDN, but I expected that to be no problem.

Exactly 120 days after my aborted upgrade (the timeout, not coincidentally, of a trial version) I experienced an incredible sense of déjà vu. The trial-to-full upgrade actually acts as a full upgrade, and (you guessed it) with 34 minutes left and 2/3rds of the way into "Installing Devices" Setup stopped making progress. Once again, my system was in the middle-of-setup netherworld, totally unusable. After trying all the things I tried 120 days earlier, I resigned myself to another full reinstall.

Then I ran into another problem: the MSDN XP CD is not bootable, as it has both Home and Professional subdirectories. Because I have only one operating system installation (the one that was corrupted by Setup), I couldn't run the Win32 version of Setup from the MSDN CD, and because my system is NTFS-only, I couldn't run the DOS Setup. Nor does the CD provide a way to make Setup boot floppies. I remembered that MSDN Subscriber Downloads has an ISO image of Windows XP Professional, so I went to get it (using another system) to burn a bootable CD, but that line of attack was thwarted by an "Error launching File Transfer Manager. Try again later." error message from the MSDN site.

How did I get myself out of this mess? I replaced the Registry hives of the aborted upgrade with ones from a backup I'd made a few weeks ago. While I couldn't log into the system after a reboot because Windows Product Activation said that it couldn't verify my license, I could boot into safe mode and run the MSDN CD setup from there. I've just about finished reinstalling my applications and am able to be productive again.

What I find utterly amazing about what happened to me (twice) is that Windows XP Setup doesn't have basic safety mechanisms that have been present in the Windows 9x Setups since Windows 95. As Windows 95, 98 or Me Setup runs it records progress points to disk. If the Setup is unexpectedly interrupted it restarts where it left off, and if it was in the "Installing Devices" phase it skips the last driver it had run before it was interrupted. That way if Setup hangs you can reboot the system and Setup will make progress beyond the point of the hang.

Windows 2000 and XP have borrowed a number of nice features from the Windows 9x line, like Safe Mode and System Restore. I wish they'd borrowed some things from Windows 9x Setup.

Speaking of upgrading to XP, humor columnist Dave Barry is thinking of making the jump: http://www.miami.com/herald/special/features/barry/2002/docs/jan06.htm .

Thanks!

-Mark

WHAT'S NEW AT SYSINTERNALS

SYNC V2.1

" Sync", an applet that flushes cached data back to disk, is a core system utility on Unix systems, and I so wrote Sync for Windows NT/2000/XP several years ago. Ensuring that modifications are reflected on read/write removable media before ejecting the media is something that Sync allows you to do. It's also useful for minimizing disk corruption when you run it before exercising a driver you're developing that might crash the system. Someone suggested recently that it would be nice if Sync had an option to eject media after flushing, so that is introduced in v2.1.

Download Sync v2.1 at
http://www.sysinternals.com/ntw2k/source/misc.shtml

DISKEXT V1.0

Another disk-related tool covered in this newsletter is DiskExt, a command-line applet that tells you, given a volume's drive letter, the locations of the partitions that make up the volume; multipartition volumes include spanned, mirrored and striped volumes. DiskExt also reports the location, in terms of the sectors they occupy, of the partitions it lists.

Download DiskExt v1.0 with full source code at
http://www.sysinternals.com/ntw2k/source/misc.shtml#diskext

NTFSDOS V3.02

NTFSDOS, the utility that launched Sysinternals (at the time of NTFSDOS' release, "Ntinternals") onto the computers of hundreds of thousands of users, allows DOS to read NTFS drives. A minor change to the Windows XP NTFS on-disk structure required a tweak to NTFSDOS for XP-compatibility.

Download NTFSDOS v3.02 at
http://www.sysinternals.com/ntw2k/freeware/NTFSDOS.shtml

PSSUSPEND V1.2

Have you ever wanted to temporarily suspend a network download, disk search, or some other resource-intensive application so that you could run something else? Suspend is one process management feature which has been sorely lacking from the administrative tools in Windows NT/2000/XP. The newest addition to the PsTools tool set is PsSuspend, a utility that suspends and resumes processes. Like all the other tools in the PsTools suite, PsSuspend is a command-line tool that you can direct at the local system or a remote one.

Because there is no suspend-process capability in Windows NT/2000/XP (there is in XP, but it's not exposed via the Win32 API), PsSuspend suspends and resumes the threads running in a target process with the Win32 SuspendThread and ResumeThread APIs.

Download PsSuspend v1.2 at
http://www.sysinternals.com/ntw2k/freeware/pssuspend.shtml
Download the entire PsTools package at
http://www.sysinternals.com/ntw2k/freeware/pstools.shtml

PSLOGLIST V2.2

The tools that compose the PsTools package continuously evolve based on user feedback, and PsLoglist has generated more requests for features than any of the other utilities. This latest version introduces a number of enhancements, including the ability to dump the records in saved event log files, change the single-line format delimiter from a comma to something else (for situations where event log text contains commas), dump records from specified date ranges, and filter on event type (error, warning, or information). As before, PsLoglist can dump local or remote system event logs and has many other options for controlling its operation.

Download PsLoglist v2.2 at
http://www.sysinternals.com/ntw2k/freeware/psloglist.shtml
Download the entire PsTools package at
http://www.sysinternals.com/ntw2k/freeware/pstools.shtml

PSINFO V1.2

A PsTools utility that has been retired is PsUptime, an applet that reported the length of time that the local or a remote system had been up. It's not that that information isn't useful – it is – but it's more appropriate for display by the relative newcomer to PsTools, PsInfo. Therefore, PsInfo v1.2 now reports system uptime, along with a slew of other information, such as OS version, processor speed, memory size, hotfix installations, whether an OS is a trial version and when it will expire, and, on Windows XP, the status of Windows Product Activation.

Download PsInfo v1.2 at
http://www.sysinternals.com/ntw2k/freeware/psinfo.shtml
Download the entire PsTools package at
http://www.sysinternals.com/ntw2k/freeware/pstools.shtml

PSEXEC V1.3

PsExec is a command-line utility that lets you run programs on a remote system without installing any software on that system. If the program you run has a command-line interface then PsExec proxies it for you, allowing you to run it interactively as if it were executing the program locally. These capabilities make PsExec a convenient light-weight remote shell-type utility, and make it easy to remotely-enable command-line programs like ipconfig.

Version 1.3 of PsExec lets you launch Windows applications (as opposed to those that are command-line) on a remote system so that they show up on the interactive desktop. I'm not sure where this might be useful, but I received several requests for this functionality.

Download PsExec v1.3 at
http://www.sysinternals.com/ntw2k/freeware/psexec.shtml
Download the entire PsTools package at
http://www.sysinternals.com/ntw2k/freeware/pstools.shtml

BGINFO V2.0

If you manage more than a few systems then you know about "system-confusion", that state of mind where you walk up to a machine (or switch to it on your KVM) and forget the computer's name, the OS version, installed service pack or IP address. While all this information is accessible through various administrative interfaces, getting at it can be time consuming. That's where Bryce Cogswell's BgInfo comes in: it displays the system information you find most important right on the desktop background so that you instantly have all the information you need.

This latest update to BgInfo makes it more configurable than ever. You can define custom text in a Registry key, specify the desktop background color or bitmap, locate the text on the background, and more. Most useful for large organizations, however, is BgInfo's ability to save and load settings, and even to export them to a database. Using either of these capabilities you can define settings once and then use them on all the systems you manage.

Download BgInfo v2.0 at
http://www.sysinternals.com/ntw2k/freeware/bginfo.shtml

PROCESS EXPLORER V5.2

Process Explorer is a process viewer and control utility that picks up where Task Manager leaves off. Among its extensive list of capabilities, Process Explorer shows you the process creation tree, displays handles that processes have open, lists DLLs that processes have loaded, and enables you to search for the process or processes that have a particular file opened.

Past versions of Process Explorer has worked on both Windows 9x and NT/2K/XP systems, but only with version 5.2 does Process Explorer show process CPU usage information for Windows 9x systems. Another enhancement for v5.2 helps track down leaks on Windows XP and 2000 systems by reporting the number of GDI and USER handles (handles to Win32 GUI resources) that a process has opened in the process properties dialog. Contrary to popular belief, even on Windows 2000 and XP the number of such resources is limited: there's a system-wide limit of 65,536 user handles and a per-process limit of 16,384 GDI handles.

Download Process Explorer v5.2 at
http://www.sysinternals.com/ntw2k/freeware/procexp.shtml

FILEMON V4.34 FOR WIN64/ITANIUM

Microsoft kindly lent me an early Itanium box from Intel so that I could begin porting the most popular Sysinternals applications to Win64/Itanium. The box is impressive: it has 2 733 MHz processors and 8 GB of memory. I decided on Filemon as the first application to port. Filemon consists of a Win32 (now Win32/64) GUI and a device driver, so two different porting efforts were required. What's somewhat unexpected is that you build both Win64 applications and 64-bit drivers on a 32-bit system running Windows NT, 2000, or XP using a cross-compiler.

The latest versions of the platform SDK (available as a free download from Microsoft: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/) include subdirectories containing the 64-bit Itanium compiler and linker, Win64 header files, and Win64 libraries. I made this simple batch file to set my environment to build Win64 executables:

@echo off
set PATH=D:\Mssdk\Bin\win64;%PATH%
set INCLUDE=D:\Mssdk\include\win64;D:\Mssdk\include\win64\crt
set LIB=D:\Mssdk\lib\ia64
echo 64-bit environment set.

Note that you cannot build Win64 applications from Visual Studio, but instead have to do it from the command-line.

A few minor casting issues were the only problems I ran into during the compile. Next, I built the driver. The latest versions of the DDK (no longer available as a free download) include shortcuts to command-prompts that have the IA64 driver build environment configured. You simply build the driver in the 64-bit target environment as you would a 32-bit driver.

The compiler informed me that I needed to more explicit about some casts. For example, the sequence numbers that Filemon assigns to operations are ULONGs, which the compiler wouldn't let me cast to a PVOID for passing as a context parameter to the I/O Manager function IoSetCompletionRoutine. Instead, I had to cast it first to ULONG_PTR and then PVOID. In any case, within a few minutes the driver compiled without errors.

Next, I copied the 64-bit application and driver to the Itanium system and just ran it. The Filemon GUI showed up and then disappeared. That meant that I had to use the Win64 debugger to figure out what was wrong. The Win64 debugger also comes in the Platform SDK and you can run it from a 32-bit or 64-bit machine. It looks like a stripped-down Visual Studio debugger, and only works in remote-mode where you install a debugging client piece on the target computer on which you run the application.

After stepping through Filemon's code for a half an hour or so I finally came to the realization that my Windows procedures needed to declare their lparam parameters as LPARAM – they had been LONG because of some code copied from the SDK back when we wrote the first version of Filemon in 1996. Interestingly, the compiler hadn't complained about this, but it meant that any pointer passed as an lparam was truncated. This showed up in Filemon's WM_MEASUREITEM handler, which interprets the lparam parameter as a pointer to structure. Filemon was faulting in that code. Amazingly, when I fixed that problem Filemon ran flawlessly on the Itanium. Total time for the port: 1 hour.

I'm working on porting Regmon now and will then port DebugView. They should both be challenging, especially DebugView, which has a pretty unorthodox driver.

Download Filemon with full source at http://www.sysinternals.com/ntw2k/source/filemon.shtml

FILEMON V1.1 FOR LINUX

If you've visited Sysinternals in the last couple of months you were probably shocked to see a new entry on the menu bar: Linux Utilities. That's right, I decided it would be pretty neat to have Filemon running on Linux. I had already used Borland's Delphi Rapid Application Development (RAD) environment on Windows, so when Kylix was released (basically, Delphi for Linux) I realized that the GUI would be pretty straightforward.

The question that remained was how to intercept file system activity. Most versions of Unix, including Linux, implement a system call named ptrace() that lets a process intercept all the system calls made by a target process. I considered using ptrace() to monitor file system activity, and may modify Filemon in the future to use it for reasons that will become clear, but decided against it.

The drawbacks to using ptrace() are that Filemon would have to enumerate all the running processes and execute a ptrace() on each one. Further, it would have to also attach to newly created processes and the ptrace() functionality doesn't provide a way to ensure that the first system calls executed by the new process wouldn't be missed. When a process being traced executes a system call the operating system blocks it, sends a signal to the tracing process, and waits for the tracing process to let the process continue. This can cause a severe performance degradation if you want to see all file system activity. Finally, the biggest drawback is that ptrace() changes the behavior of traced processes. While they are being traced, the tracer is the parent process, which means that a traced process' real parent won't see the notifications they would normally see when their child processes cause them.

It would have been nice if I could have written a file system filter driver (a stackable driver in Linux terminology) like the I/O Manager in Windows NT/2000/XP supports, but the current Linux file system architecture doesn't support stackable file system drivers. There's a patch called FiST that you can apply to support it (http://www.cs.columbia.edu/~ezk/research/fist/), and there's also a trace toolkit (http://www.opersys.com/LTT/index.html) for Linux, but both require that end users recompile their kernels, something that I wanted to avoid. So I decided to implement the monitoring using a system call-hooking driver, much like Regmon works on Windows.

There are two concerns that made the project more difficult than doing the same thing on Windows. The first is that Linus Torvalds, the father of Linux and director of Linux kernel development, doesn't believe in the use of kernel debuggers. The reasons are pretty ridiculous (see http://www.lib.uaa.alaska.edu/linux-kernel/archive/2000-Week-36/0575.htm l to read Linus' own explanation) and it's one of several reasons that the Linux kernel will have a hard time keeping up with Windows. A couple non-official kernel debuggers exist, but they require that you patch the kernel and require some effort to use. The second concern is that Linus doesn't believe in guaranteeing backward compatibility with device drivers as new kernels release. The consequence is that any exported kernel API can suddenly change, breaking existing drivers that use the API and requiring them to be recompiled for new kernels.

The lack of a built-in kernel debugger meant that I debugged via debug print statements (I figured I'd spend as much time debugging via printk's – kernel-mode prints – as I would installing and learning a kernel debugger), and the changing kernel APIs and data structures means that Filemon for Linux is kernel-dependent. It works on shrink-wrapped Red Hat 7.1 and 7.2 and SuSE Linux 7.1 and 7.2, and possibly on other commercial distributions, but I have yet to devise a way to insulate the driver from arbitrary kernel changes (one that broke an early version of the driver was the changing of a kernel function's calling convention from standard to fast-call).

Filemon for Linux has the exact same interface as its Windows counterpart and it looks remarkably similar (see the screenshot on the Filemon for Linux page). My conclusions about the ease of developing a general non-kernel dependent file system filter for Linux should be clear: it's difficult if not impossible. By contrast, stackable (filter) drivers in every driver domain (networking, file systems, storage, input, etc) were supported by the Windows NT I/O architecture from the beginning.

Download Filemon for Linux at http://www.sysinternals.com/linux/utilities/filemon.shtml

SYSINTERNALS AT WWW.MICROSOFT.COM

Once again here's the latest installment of Sysinternals references in Microsoft Knowledge Base (KB) articles released since the last newsletter. Note the one that even has Filemon in its title. This brings to 31 the total number of KB references to Sysinternals. You can find a complete listing at http://www.sysinternals.com/ntw2k/info/mssysinternals.shtml

  • Fatal Exception Error Message Occurs During Setup http://support.microsoft.com/support/kb/articles/Q273/9/18.ASP

  • FP2000: Files of Type List for Database Drivers Is Empty http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q308935

  • HOWTO: Troubleshoot Error 1928 "Error Registering COM+ Application" http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q308940

  • PRB: Conflict with EOF When Using #import with ADO http://support.microsoft.com/support/kb/articles/Q166/1/12.ASP

  • PRB: DLLs Not Unloaded After Calling CoFreeUnusedLibraries http://support.microsoft.com/support/kb/articles/Q301/3/57.ASP

  • PRB: Error 80004005 "The Microsoft Jet Database Engine Cannot Open the File '(Unknown)'" http://support.microsoft.com/support/kb/articles/Q306/2/69.ASP

  • PRB: FileMon Shows That DAO360.dll Fails to Load MSJet49.dll, MSJet48.dll, and Other MSJetxx.dll Files http://support.microsoft.com/support/kb/articles/Q306/3/86.ASP

  • SMS: Software Inventory Agent Generates an Invalid Page Fault Error Message http://support.microsoft.com/support/kb/articles/Q302/6/51.ASP

INTERNALS INFORMATION

INSIDE WINDOWS 2000, THE INTERACTIVE DVD

If you missed out on the special pre-release pricing of INSIDE Windows 2000, the interactive DVD tutorial on Windows 2000 internals, we have good news! An INTRODUCTORY PRICE of $950, which is more than 25% off the normal single user price, is still available. To ORDER NOW, or for further information on this exciting new product by David Solomon and Mark Russinovich, go to http://www.solsem.com/dvd.html. Also available in a network distribution format for intranet streaming!

MARK THE DATES: RUSSINOVICH & SOLOMON TEACH TOGETHER AGAIN IN SEATTLE AND BOSTON

Our 3-day Windows 2000/XP internals class in Austin last month was a sell-out success, so we've schedule two more offerings: April 17-19 near Seattle and June 12-14 in Boston (registration will be open soon). The class is based on "Inside Windows 2000, 3rd Edition" and covers environment subsystems, system call dispatching, system threads, startup & shutdown, registry internals, processes and thread scheduling, memory management, security, the I/O system, storage, NTFS, and the cache manager. By understanding the inner workings of Windows XP & 2000 you can take advantage of the platform more effectively and more effectively debug and troubleshoot problems. For details, see http://www.sysinternals.com/seminar.shtml

WINDOWS XP MANIFEST FILES

One of the most visible changes in Windows XP is the new look and feel provided by the Luna desktop. Luna is actually a "theme", and if you run an application that's not theme-aware (any application not written specifically to take advantage of Windows XP themes) the application has the older Windows 2000-style look and feel. However, you can make even older applications have the new look very easily, even when you don't have source code. Simply create an XML manifest file for the application that tells the Windows XP loader that that application wants to use the Common Control version 6 DLL (the comctl32.dll in %SystemRoot%\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1 df_6.0.0.0_x-ww_1382d70a) instead of the non-theme aware version in %SystemRoot%\System32. Here is the manifest file that makes Process Explorer v5.2 theme aware:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly
xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
name="Process Explorer"
processorArchitecture="x86"
version="5.1.0.0"
type="win32"/>
<description>Process handle and DLL viewer</description> <dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="x86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>

Change the application name, version, and description for the application you want to make theme-aware, and then save the file so that it has the same name as the application's executable, except with ".manifest" appended to it e.g. procexp.exe.manifest. If you are the application's developer you can embed the manifest file in the application's resources, like I've done with Process Explorer. See the source code to Filemon for an example of how to do that.

WHAT'S IN AN X-BOX?

If you've followed the console gaming world recently then you almost certainly know that Microsoft's new X-Box console is running a modified version of Windows 2000. While out at Microsoft for a recent Windows XP-research trip for the 4th edition of our book, Dave Solomon and I learned from the Windows 2000/XP development team that the X-Box group decided on Windows 2000 for its driver support. After the decision was made, the X-Box developers got a copy of the Windows 2000 source tree and went away, hardly to be heard from again by the Windows 2000/XP team.

The X-Box has a highly modified, stripped-down version of Windows 2000 that fits in a mere 512 KB of memory. It has all non-relevant subsystems removed (they originally stripped out the Plug and Play subsystem only to add it back after realizing that driver loading depended on it), runs only one process, and has no Win32 subsystem (only the X-Box API). The X-Box has only 64 MB of physical memory and no virtual memory support, so the Windows 2000 Memory and Cache Managers are two subsystems that were removed. With such drastic modifications, you have to consider it a new operating system, not Windows 2000.

You can learn more about X-Box, GameCube and PS2 internals at http://www.e-insite.net/ednmag/index.asp?layout=article&articleid=CA185947&pubdate=12-20-01

RANDOM WINDOWS XP STATISTICS

The following statistics were published by Microsoft on their OEM System Builder's web site (at http://oem.microsoft.com – you can sign up for free), and I thought that you'd find some of them interesting and/or amusing.

Incidentally, the build number of the final release of Windows XP didn't coincidentally fall at 2600 – it was fudged a little (the build number is incremented every time the operating system compiles in the build lab, typically once every work day). Inside sources say that the number was targeted at the 2600-community, a loose-knit group of hackers (http://www.2600.com/), as a message demonstrating the XP team's confidence in the security of XP.

  • Number of days it took to develop Windows XP: 600 (12/20/99 – 8/24/01)
  • Number of focused team members: 5,736
  • Number of testers per developer: 1.4
  • Number of babies born during the project: 452
  • Number of interns employed: 504
  • Amount of macaroni consumed during 40 "Windows Info Meetings": 6,000 lbs
  • Number of Frappuccino's® served: 86,400
  • Dollars raised for Seattle Ronald McDonald House (local charity): $2 million
  • Number of test cases for system restore feature: 1.6 million
  • Number of Direct3D graphics test cases run since Windows XP RC1: 43,114,143
  • Number of applications tested for compatibility: 5,500
  • Number of devices supported out of the box: 12,000
  • Percentage of the most popular PC applications distributed in the last three years that will be compatible with Windows XP: 90%
  • Number of tracks in the largest Digital Media Library test case: 31,000
  • Length in hours of longest single file captured by Windows Movie Maker: 114
  • Number of languages we are localizing to: 24 fully & 9 partially
  • Number of countries participating in the launch on 10/25: Over 50
  • Number of people attending launch events worldwide: over 580,000 in seats … plus online audiences 5,120 system builders worldwide

NEW IMPROVED WINDBG

Windbg is a graphical front end to the kernel-debugging support built into the Windows NT/2000/XP kernel. Until the last couple of years Windbg rightly earned a reputation for being flakey and cumbersome, but that's changed since Microsoft has focused on improving it. The latest version of Windbg, available as a free download from http://www.microsoft.com/ddk/Debugging/, is hugely improved over the old versions and easier to use. There are some new features that even experienced Windbg users might not be aware of, and two commands that are useful to systems administrators trying to diagnose system crashes.

A feature that makes the latest Windbg very easy to use is its support for Microsoft's symbol server. A problem with looking at crash dumps or debugging applications with Windbg has been that you need to have installed the correct debug symbol files for your installation. With service packs, hotfixes, and possibly crashes from different operating systems (e.g. Windows NT versus Windows XP), this can be onerous. With the symbol server support, you simply enter the URL of Microsoft symbol server into the Windbg symbol path dialog and Windbg will download symbols from the server on-demand and store them in the directory you specify. The symbol server has symbols for Windows .NET Server Beta 3, Windows XP and XP release candidates, Windows 2000 and its service packs and hot fixes, Windows NT 4, MDAC 2.1-2.7, IIS, and ISA.

The two commands that are useful for debugging crash dumps are !analyze and .dump. Run !analyze (specify the -v switch) to get an automatic analysis, based on heuristics, of a crash. This command is already quite powerful, and as Microsoft incorporates more historic data from real crashes it will become even more accurate.

The .dump command is useful for both user-mode debugging and kernel-mode crash dump analysis. In some server environments, especially web servers, you might identify a memory leak or other problem, but not be willing to stop and restart the server until the cause is isolated. On Windows XP and .NET Server you can attach to the server process using Windbg, run the .dump command to generate a user-memory crash dump file, and then detach (with the .detach command), pausing the server only briefly. Then a developer can take the generated dump file and analyze it offline.

By default, Windows server systems generate a full-memory dump, which is as large as the amount of physical memory present on a system and can therefore be very large. However, you can load the dump into Windbg and use the .dump command to generate a smaller kernel-memory or minidump from the full dump. The smaller files are easier to exchange and are often all that's needed to isolate the cause of a crash.

Download the latest version of Windbg from http://www.microsoft.com/ddk/Debugging/, and find instructions on configuring Windbg to get symbols from the Microsoft symbol server at http://www.microsoft.com/ddk/debugging/symbols.asp

WHAT'S COMING UP

USING BOOTVIS TO PROFILE THE WINDOWS XP BOOT PROCESS

In order to aid them in tuning the Windows XP boot process, the Windows XP performance team instrumented key points in the operating system and developed a tool called BootVis to display boot traces. In a surprising move they have made the tool freely available. It's very easy to use and it displays an amazing amount of detail, including information about when drivers initialize, when and where disk I/O occurs, and when services and applications start. Next time I'll show you where you can get it and how to use it.

Thank you for reading the Sysinternals Newsletter.

Published Monday, January 07, 2002 7:01 PM by ottoh

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