I’m not sure if my last post got through (checked after an hour since I’ve posted my last post). But if it didn’t get through, here is my question again:
I have googled a few windbg tutorials on google and found quite a bit on kernel-mode application debugging. However, I can’t quite distinguish from the tutorials on user-mode debugging. First of all, does anyone of you know of a good tutorial on user-mode application debugging? Secondly, for user-mode debugging, is it highly recommended that I use the 2-computer setup when debugging? Thanks.
Well, you’re doing better than most. In fact, I don’t really know anyone who has ever found more than one thing on the web in the
way of a tutorial on kernel debugging. So, as to your questions, the news is mixed.
For the record, it is my opinion, that anyone who has the option of using VS for user mode but instead uses WinDbg is a
confirmed masochist. I do almost no user mode work these days that requires a debugger, and I hate VS, but, when I have to, I use
VS. That being said, if you don’t already own it and you don’t work for someone who will readily pay for it, I can certainly
understand wanting to check out the free one, but if it’s at all an option, you’ll cover the cost of VS in a matter of what seems
like seconds, assuming that your getting paid to do any of this. From here forward, however, I’m only commenting on using WinDbg as
you stated.
I don’t really know, but I very seriously doubt that the two machine setup is even remotely common, especially considering what
I have to believe is a small number of user mode WinDbg users, but I may be wrong about all of that. I can’t think of any
situations in which it would be required, and I can certainly imagine why it would be nice if for no other reason than limited
screen size in GUI situtations, and actually that one could perhaps pose things like z-order issues that might be impractical to
address on a single machine (I don’t know), but I’m the wrong person to ask, and using it on two machines has some issues of it’s
own. What I do feel comfortable saying is that if you’re considering whether to purchase hardware to support this, then the answer
is no, buy VS instead; if you already have what you need, try it and see if you like it.
Doron recommended a really excellent book by MS Press called something like ‘Advanced Debugging’ recently. I have only read one
chapter so far, and it is excellent, but I have no doubt that something recommended by Doron (and one other MSFT person as well,
that I know) is all good, and it is mostly user mode (maybe all). That being said, I haven’t read enough of it to know whether
someone new to all of this would find helpful immediately, and I also don’t remember the name, but I mention it because, it’s one of
a true handful of books on the subject of Windows debugging, and it’s the only one that I’ve looked at that doesn’t suck.
I’m not sure if my last post got through (checked after an hour since I’ve posted my last post). But if it didn’t get through, here is my question again:
I have googled a few windbg tutorials on google and found quite a bit on kernel-mode application debugging. However, I can’t quite distinguish from the tutorials on user-mode debugging. First of all, does anyone of you know of a good tutorial on user-mode application debugging? Secondly, for user-mode debugging, is it highly recommended that I use the 2-computer setup when debugging? Thanks.
Thank you for your reply, mm. It turns out that I’m finding the results that I’m looking for when I searched for “printer driver debugging” on Google. I do own Visual Studio, but the driver would be very difficult to debug using Visual Studio, although it has an “Attach to Process” feature and then show verbose output and maybe even logs onto a dump file or something.
> 3. Doron recommended a really excellent book by MS Press called
something like ‘Advanced Debugging’ recently.
“Advanced Windows Debugging”, by Mario Hewardt and Daniel Pravat
(Addison-Wesley, actually). I bought it on Doron’s recommendation (and
because Mark Russinovich wrote the foreword), and just finished reading
parts 1 and 3 this morning.
It’s really good stuff. I would recommend it for any developer who’s
also responsible for support (like me); the sections on setting up a
public HTTP symbol server and utilizing Windows Error Reporting were
helpful, and they show how to set up an automatically-updated private
symbol and source server as well.
Having said that, though, the book is almost entirely covering WinDbg -
though both in user-mode and kernel-mode (There’s even a section on
“Redirecting a User Mode Debugger Through a Kernel Debugger” that
explains how to debug both user and kernel-mode at the same time).
However, for user-mode only debugging, I have to agree that the Visual
Studio is just plain easier to use. WinDbg seems more applicable for
kernel-mode (and user-mode postmortem) tasks.
It is also very appropriate for debugging user mode to kernel mode
communications problems. Some of the samples in the WDK have both a driver
and user mode component, for example minispy in the filesys area, so windbg
is useful for those areas. I do recommend that you use the Visual Studio
debugger for pure user land and if you can even for the user mode parts when
the problem is not in the interface to the kernel.
“Stephen Cleary” wrote in message news:xxxxx@windbg… >> 3. Doron recommended a really excellent book by MS Press called >> something like ‘Advanced Debugging’ recently. > > “Advanced Windows Debugging”, by Mario Hewardt and Daniel Pravat > (Addison-Wesley, actually). I bought it on Doron’s recommendation (and > because Mark Russinovich wrote the foreword), and just finished reading > parts 1 and 3 this morning. > > It’s really good stuff. I would recommend it for any developer who’s also > responsible for support (like me); the sections on setting up a public > HTTP symbol server and utilizing Windows Error Reporting were helpful, and > they show how to set up an automatically-updated private symbol and source > server as well. > > Having said that, though, the book is almost entirely covering WinDbg - > though both in user-mode and kernel-mode (There’s even a section on > “Redirecting a User Mode Debugger Through a Kernel Debugger” that explains > how to debug both user and kernel-mode at the same time). > > However, for user-mode only debugging, I have to agree that the Visual > Studio is just plain easier to use. WinDbg seems more applicable for > kernel-mode (and user-mode postmortem) tasks. > > -Stephen Cleary >
I personally prefer to use WinDBG to debug everything. It might be my deep
rooted hatred for any VS version post 6.0, but I find WinDBG to be entirely
capable as a user mode debugger. Then again it might be the nature of the
kind of UM debugging I do. It’s generally either debugging some small
console app that had the misfortune of being written by me or trying to
figure out why some random application is failing in a random way when one
of our toolkits is present (particularly fun when it’s something small.
Like, oh, Office or a Vista SP1 install).
Lots of people give much love to OllyDbg also for the latter type of
debugging. I have a version of it installed on my workstation so that I may
someday play with it and see what all the fuss is about. That day has yet to
come, but here’s to hoping…
“David Craig” wrote in message news:xxxxx@windbg… > It is also very appropriate for debugging user mode to kernel mode > communications problems. Some of the samples in the WDK have both a > driver and user mode component, for example minispy in the filesys area, > so windbg is useful for those areas. I do recommend that you use the > Visual Studio debugger for pure user land and if you can even for the user > mode parts when the problem is not in the interface to the kernel. > > “Stephen Cleary” wrote in message > news:xxxxx@windbg… >>> 3. Doron recommended a really excellent book by MS Press called >>> something like ‘Advanced Debugging’ recently. >> >> “Advanced Windows Debugging”, by Mario Hewardt and Daniel Pravat >> (Addison-Wesley, actually). I bought it on Doron’s recommendation (and >> because Mark Russinovich wrote the foreword), and just finished reading >> parts 1 and 3 this morning. >> >> It’s really good stuff. I would recommend it for any developer who’s also >> responsible for support (like me); the sections on setting up a public >> HTTP symbol server and utilizing Windows Error Reporting were helpful, >> and they show how to set up an automatically-updated private symbol and >> source server as well. >> >> Having said that, though, the book is almost entirely covering WinDbg - >> though both in user-mode and kernel-mode (There’s even a section on >> “Redirecting a User Mode Debugger Through a Kernel Debugger” that >> explains how to debug both user and kernel-mode at the same time). >> >> However, for user-mode only debugging, I have to agree that the Visual >> Studio is just plain easier to use. WinDbg seems more applicable for >> kernel-mode (and user-mode postmortem) tasks. >> >> -Stephen Cleary >> > > >
Lots of people give much love to OllyDbg also for the latter type of
debugging. I have a version of it installed on my workstation so that I may
someday play with it and see what all the fuss is about.
Ollydbg is a great tool, both for debugging and for reverse
engineering. It knows what the parameters are for most Windows APIs, so
it provides an annotated commentary showing you which registers mean what.
I use it quite a lot, but it has one rather serious limitation: it
doesn’t understand C code at all. It is strictly an assembler tool. If
you aren’t up on your x86 assembly language, then Ollydbg is not for you.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I like the VS debugger, but I use windbg more, even for user mode work.
Symbol handling is more flexible. Installation is lightweight - I can easily
throw it in a virtual machine or even put it on a QA or end-user system. I
can examine heaps, handles, and locks. As far as I know, there’s nothing
like !heap in VS.
The application I work with is fairly low level, which probably adds to my
bias. Also, perhaps perversely, I’m afraid I’ll forget too much if I don’t
use it regularly!
Gary Kratkin
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
Sent: Friday, May 23, 2008 2:46 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] windbg user-mode driver debugging tutorials
It is also very appropriate for debugging user mode to kernel mode
communications problems. Some of the samples in the WDK have both a driver
and user mode component, for example minispy in the filesys area, so windbg
is useful for those areas. I do recommend that you use the Visual Studio
debugger for pure user land and if you can even for the user mode parts when
the problem is not in the interface to the kernel.
“Stephen Cleary” wrote in message news:xxxxx@windbg… >> 3. Doron recommended a really excellent book by MS Press called >> something like ‘Advanced Debugging’ recently. > > “Advanced Windows Debugging”, by Mario Hewardt and Daniel Pravat > (Addison-Wesley, actually). I bought it on Doron’s recommendation (and > because Mark Russinovich wrote the foreword), and just finished reading > parts 1 and 3 this morning. > > It’s really good stuff. I would recommend it for any developer who’s also > responsible for support (like me); the sections on setting up a public > HTTP symbol server and utilizing Windows Error Reporting were helpful, and
> they show how to set up an automatically-updated private symbol and source
> server as well. > > Having said that, though, the book is almost entirely covering WinDbg - > though both in user-mode and kernel-mode (There’s even a section on > “Redirecting a User Mode Debugger Through a Kernel Debugger” that explains
> how to debug both user and kernel-mode at the same time). > > However, for user-mode only debugging, I have to agree that the Visual > Studio is just plain easier to use. WinDbg seems more applicable for > kernel-mode (and user-mode postmortem) tasks. > > -Stephen Cleary >
