> 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.windbgWith 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 & IA64The 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