You have probably seen AndreVa’s message about the new release. I
wanted to add some comments about it.
Our first retail release of “Debugging Tools for Windows”, version
1.0.6.0 is now on the web at http://www.microsoft.com/ddk/debugging. We
have also put our native 64-bit package out there as a beta release.
If you see the old page, then hit the refresh button.
Uninstall any preivous BETA debuggers before installing.
Please send any bugs or feature requests to xxxxx@microsoft.com (this
is not a geneneral support alias - we don’t help people debug their
code, just debuggin issues)
We have also created a newsgroup for people to discuss WinDbg issues.
It is microsoft.public.windbg
With this debugger you can debug many different types of targets. The
supported targets are:
Kernel Mode
Live & Dump files
NT4 x86 & alpha
Win2k
Whistler x86 & IA64
User Mode
Live
NT4 x86
Win2k
Whistler x86 & IA64 (including native IA64 & x86
on IA64)
Dump
NT4 x86 & alpha
Win2k
Whistler x86 & IA64
The debugger release includes updated documentation. Please read it as
you will find lots of information that should help you.
The debugger release also contains an SDK with some simple samples. You
must do a “custom” install in order to install it. The samples build
fine with the latest released DDK & SDK. The SDK contains everything
you need to write extensions to the old or new extension interfaces.
With the new interfaces extentions can do all kinds of powerful things.
These interfaces can also be used to wrap a new client around the
debugger engine. Basicly this is all the Windbg does. That means
someone could develop thier own “Windbg” UI and not have to mess around
with the ugly debugger details like how to implement breakpoints,
disassembly, symbol handlers, etc… So you could leaverage all the
work we did in the engine & basicly extend functionality or write a new
UI. The one piece of bad news is that the documentation for the SDK is
not yet done. So one have to rely on the method names, etc…
Some feature highlights (please see the docs for more detail):
Workspace naming - save workspaces by name & load then by name
(even from the command line)
Remoting - by starting a debugger with -server one can connect
using -remote. This enables source level debugging on your office
machine of a machine sitting in another room (or over the Internet).
Context changing commands - .cxr, .trap, .tss, .thread,
.context, etc… change the context of the debugger. This makes it
easier to debug exceptions, bugchecks. It also allows easier debugging
of user mode processes when kernel debugging.
Noninvasive attach - This allows you to debug a UM process
without attaching as the offical debugger. This enables you to look at
processes being “debugged” by other processes. It also gives you a way
to detach the debugger from processes in NT4 and Win2k without killing
them. The limitations of doing this are similar to what you can do with
a dump file. You can read/write memory and that’s about it. Of course
this enables stack walking, looking at variables, and most extensions
work. You just can’t do breakpoints, exception handling, etc…
Symbol server - You can use symbol server to “index” symbols
from multiple versions into one place. Then the debugger does symbol
lookup based on information in the image header rather than the name.
This enables having one sympath that works for all OS versions you may
debug. If you ever had to play with symbol paths to get it work when
you put a few chk binaries on a fre machine you should love this. See
the docs for detail on how to build a symbol server and how to use it in
the sympath.
Hope you enjoy using this version.
Nathan Nesbit
Windows Debugger Team - http://dbg