-
I had never considered the prospect of debugging a display driver on
one machine. That is a really, really terrible thought.
-
I have long considered the question of how to make the
documentation of the commands better, because I just can’t seem to
remember certain commands, and the only option left is search, which
will produce far too many hits than the I have patience deal with, for
most any of the basic concepts which a command involves. The one that I
can never seem to remember is “dg,” because I seem to have the idea in
my head that there is a “!gdt,” and searching for “descriptor” produces
28 hits, while “global descriptor” yields zero. After much
consideration, I have arrived a nothing, except having long aliases more
or less entirely for this purpose. This seems a little extreme.
-
As far as issues with documentation goes, a lot of commands simply
don’t have any. Ever open up the most recent README and tried to look
up one of the highlighted new commands or new options for any existing
one? It’s rather difficult.
To me the benefit of SI, while situational, was a very practical one
when it existed. Attaching online at least for a first look beat going
to site with a serial cable. This was frequently not an option, but
when it was the price and situational instability didn’t seem all that
bad.
But they’re still pirates.
mm
>> xxxxx@probo.com 2007-01-17 13:58 >>>
Daniel Terhell wrote:
Interesting issues people here are raising are:
-Wouldn’t it be nice if we could do kernel debugging over a network
connection ?
Yes, but that requires a configured network stack and driver,
independent of the operating system, available at boot time. That’s a
Big Deal.
-Wouldn’t it be nice if we didn’t need to carry around a bunch of
hardware
including multiple systems just to be able to do debugging but
instead could
just do it on one single machine ?
Yes, but experience has shown that the Heisenberg principle is at work
here. Doing single machine debugging inevitably impacts the system
under test in unpredictable and undesirable ways. In particular, it
is
darned near impossible to single-machine-debug a display driver.
A cheap laptop dedicated as a WinDbg host is pretty easy.
-Wouldn’t it improve the quality of WinDbg if there were some
competition
and another kernel debugger were around ?
I’m not convinced of that. I can’t think of another example of an
operating system with multiple sets of kernel tools. It requires such
detailed and intimate knowledge of the internals of kernel –
knowledge
that a proprietary operating system vendor might reasonably be
unwilling
to share.
-Would WinDbg still be so popular if we had to pay for it ?
If we were paying for it, we all would have complained about it until
it
got better.
-Was MS right to knock out SoftIce from the competition by inducing
heavy
kernel restrictions with Patchguard ?
This is not the reason. SoftIce was fading rapidly long before
PatchGuard came into being.
-Wouldn’t it be nice if installing the debugger, getting the symbols
and
connections right wouldn’t actually be a much harder task than
anything else
in kernel land including writing an encryption file system filter
driver ?
That’s just silly. I can remember a time when we dedicated the first
two days of every contract to screwing around with RS232 cables and
adapters and connectors to get the kernel debugger connected. Today,
it
Just Works.
-Why WinDdbg doesn’t comply to the user interface guidelines of MS?
Wouldn’t
it be nice if they just wouldn’t hexdump the crap out of us just
because we
are kernel developers and we can read opcode anyway ? This Windbg is
using
an absurd unintuitive syntax which is totally incompatible with both
short
term and long term human memory, paged or non paged.
I don’t want a kernel debugger video game with blinky lights and
transparent flaming logo buttons. I want something that shows me
registers and opcodes, quickly, with no distractions. Indeed, I often
eschew the GUI altogether and run i386kd from a command line.
On the other hand, I agree that the command set is a bit arcane. Part
of that comes from maintaining backward compatibility with every
debugger since the MS-DOS debug.com, but that doesn’t help me choose
between dot-this and bang-that. It’s handy that many commands now
suggest to me the next command to try. The KMDF extension (wdfkd.dll)
is especially good at that.
However, there are one hell of a lot of commands in WinDbg. How would
you make them more clear? I have also used gdb. It is (ironically)
wordier than WinDbg, but every bit as arcane. Do I want “info”,
“display”, “show”, “print” or “examine”?
SoftIce is also arcane, although the context-sensitive help was a big
aid.
If you have any comments, I would really appreciate your or other
experts
views on these. My vision is that the people behind SoftIce really
tried
hard and deserve merit for it.
For a while, they certainly did so, and in the mid-90s I gave them
some
of my hard-earned dollars. As the kernel got more complex and
component
interactions became more intertwined, it just became impossible for
them
to provide the same functionality with each new version. Too many
special cases and weird configurations.
No matter what debugger is used, I see
debugging as a non-constructive evil which is sometimes unavoidable
and like
a poisonous drug should only be used as a last recourse if really no
other
options are available.
I’m not sure I agree with that. Printf-style debugging using
something
like dbgview.exe can tell you a lot of information, but there are
things
that cannot be understood without watching breakpoints and single
stepping.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
