Volume 4, Number 1

Copyright (C) 2002 Mark Russinovich

January 7, 2002 - In this issue:


- 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

- 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

Using BootVis to profile the Windows XP boot process

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” (

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

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 .



========== 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

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

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

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
Download the entire PsTools package at

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

Download PsLoglist v2.2 at
Download the entire PsTools package at

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
Download the entire PsTools package at

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
Download the entire PsTools package at

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

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 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

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

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

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

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

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
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

Download Filemon for Linux at

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

Fatal Exception Error Message Occurs During Setup

FP2000: Files of Type List for Database Drivers Is Empty

HOWTO: Troubleshoot Error 1928 "Error Registering COM+ Application"

PRB: Conflict with EOF When Using #import with ADO

PRB: DLLs Not Unloaded After Calling CoFreeUnusedLibraries

PRB: Error 80004005 "The Microsoft Jet Database Engine Cannot Open the
File '(Unknown)'"

PRB: FileMon Shows That DAO360.dll Fails to Load MSJet49.dll,
MSJet48.dll, and Other MSJetxx.dll Files

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

================== INTERNALS INFORMATION =============
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!

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

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
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">
name="Process Explorer"
<description>Process handle and DLL viewer</description> <dependency>

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.

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

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

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

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
- Number of Frappuccino’s® served: 86,400
- Dollars raised for Seattle Ronald McDonald House (local charity): $2
- Number of test cases for system restore feature: 1.6 million
- Number of Direct3D graphics test cases run since Windows XP RC1:
- 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:
- 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

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

================ WHAT'S COMING UP =================
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.

Comments (0)

Skip to main content