I agree with Tim - assembler is a must, and most other things (in
particular, single stepping) are kind of difficult without it. That
being said, single stepping is a great way to learn assembler, because
it will unavoidable highlight the rather small subset of x64/x64
assembler that is actually at all common; there are many, many (easily
most) instructions that you can go years and not see in WinDbg. Also,
if you’re going to look at x64, you might want to check out this
material in the WDK about calling convention
(http://msdn2.microsoft.com/En-US/library/ms794533.aspx) early in the
process, because it is quite different than the (otherwise quite
similar) case of x86.
Hope this help,
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, June 18, 2007 13:00
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] What next after !analyze -v
driver developer wrote:
As someone who has just started off on developing windows drivers ,I
would like help on how to proceed next after !analyze -v in winDbg
I find myself stumped on what to do next. Although I found some very
useful articles on http://www.osronline.com
http:</http:>and in the Windbg help files.
Although I would like to have a formal training but my company will
not send me across half the world for ‘just a training’
You don’t say what part of the world you are in; the OSR training
classes do occasionally get held in Europe and Asia. Also, if spending
a few weeks’ salary to send you to a class helps you solve a problem in
two weeks instead of six weeks, that’s clearly a net win. The failure
to understand this might explain the sub-par drivers that we see from
certain parts of the world.
My eyes glaze over when I reach the x86 assembly language stuff .
Although I can decipher what each instruction does by using for
instance x86 instruction manual but I don’t get the big picture.
In my view, an understanding of x86 assembler is critical in driver
debugging. There was a perfect example of this over the weekend, when
“rjunk007” posted his !analyze -v of his mirror driver crash. The
analyze clearly showed a “rep movsd” instruction, and it clearly showed
that the esi register was 0. That immediately tells me that he passed a
null pointer as the “copy from” parameter to memcpy.
Any general ideas on how a comparative newbie can increase his
debugging skills or some tricks/pointers/resources would be welcome.
I understand about using this or Microsoft news groups as a valuable
resource
!analyze -v gives you a huge number of clues. I think it’s fantastic
that analyze now suggests further “windbg” commands you can execute to
explore the problem in more detail. For me, using the debugger to
single-step through working code is a great way to find out how things
are supposed to be working, but again, that’s quite difficult without a
good understanding of x86 assembler.
–
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
