Debugger 6.2.9200.16384 AMD64

NTDEV
1

What a joy is this giant piece of … well-formed code! Ha! Somebody please
point out what I’m doing wrong (since it MUST be me right?) for it to
sometimes break, sometimes not, sometimes break, sometimes not - driving me
nuts! I know it’s getting to the breakpoint(s) in the driver but it is
tough to debug code when the debugger is so petulant about deciding whether
it wants to honor the breakpoint or not. BTW, the lines don’t colorize half
the time either but the B.P. IS always being set - combined with the
not-breaking scenario this forces me to do a lot BL’ing - or is that BS?

Target machine: Win7-64 free build, ‘Test Mode’, 1394 debug connection.
Driver: built with Win7 x64 Checked Build Env.

TIA,
Bill C.

2

When are you seeing this? If it is at the start of the driver, the break
point does not necessarily get activated, I’ve noticed it. This could be
tricky, so what I usually do is the following…

.symopt+0x40 ((assuming that .symfix & .sympath is already used to point
to the correct symbols of your driver)). Then before loading ( either by
reboot or demand load) the driver, bu to make it armed, and break when the
code gets there…

For boot start driver, I often use Shift+Alt+K to have early break into
krnl, then do the sym setting etc…

On the other hand, if the break point is based on the dispatch-paths that
you can control from an app or another krnl component, you can always use
the .symopt, .symfix, .sympath commands to set the syms correct, then load
it, the check it like kd> x !*, to see if the symbols are
loaded, then set bp…

-pro

On Tue, Aug 28, 2012 at 5:08 PM, Bill Casey wrote:

> What a joy is this giant piece of … well-formed code! Ha! Somebody
> please
> point out what I’m doing wrong (since it MUST be me right?) for it to
> sometimes break, sometimes not, sometimes break, sometimes not - driving me
> nuts! I know it’s getting to the breakpoint(s) in the driver but it is
> tough to debug code when the debugger is so petulant about deciding whether
> it wants to honor the breakpoint or not. BTW, the lines don’t colorize
> half
> the time either but the B.P. IS always being set - combined with the
> not-breaking scenario this forces me to do a lot BL’ing - or is that BS?
>
> Target machine: Win7-64 free build, ‘Test Mode’, 1394 debug connection.
> Driver: built with Win7 x64 Checked Build Env.
>
> TIA,
> Bill C.
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

3

That’s how computers work… bugs in, nuts out
– pa

4

I’m using the last windbg from the last traditional WDK 6.12.0002.633
and you will have to pry this version of windbg from my cold dead
dinosaur claws, 'cause it just friggin works.

Of course I never use firewire any more because all my firewire windbg
experiences included lots of time debugging the firewire connection,
so I avoid that mess like the plague.

Mark Roddy

On Tue, Aug 28, 2012 at 8:08 PM, Bill Casey wrote:
> What a joy is this giant piece of … well-formed code! Ha! Somebody please
> point out what I’m doing wrong (since it MUST be me right?) for it to
> sometimes break, sometimes not, sometimes break, sometimes not - driving me
> nuts! I know it’s getting to the breakpoint(s) in the driver but it is
> tough to debug code when the debugger is so petulant about deciding whether
> it wants to honor the breakpoint or not. BTW, the lines don’t colorize half
> the time either but the B.P. IS always being set - combined with the
> not-breaking scenario this forces me to do a lot BL’ing - or is that BS?
>
> Target machine: Win7-64 free build, ‘Test Mode’, 1394 debug connection.
> Driver: built with Win7 x64 Checked Build Env.
>
> TIA,
> Bill C.
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

This problem is nothing new. If you really want the debugger to break
add a call to KdBreakPoint() to your code at the appropriate location.
Alternately, you can use the debugger to write the break instruction
into the code, e.g. by overwritting the hot patch instruction:

eb cc
eb 90

Works like a charm. After the debugger breaks you can use the “eb”
command to restore the original instructions (if needed).

6

Nothing new? It is to me. I’ve haven’t used a debugger since around 2007
and while I had issues with these earlier versions, I sure don’t remember
THIS problem. Wasting time futzing with this instead of producing working
driver code - not happy!!

Bill Casey
?
== VirDIS? & VirtualSCSI? Target Mode Solutions ==
Advanced Storage Concepts, Inc.???(409) 762-0604
2200 Market Street, Suite 810??xxxxx@virtualscsi.com
Galveston, TX USA 77550-1532???www.virtualscsi.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of George M. Garner Jr.
Sent: Wednesday, August 29, 2012 8:56 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Debugger 6.2.9200.16384 AMD64

This problem is nothing new. If you really want the debugger to break add a
call to KdBreakPoint() to your code at the appropriate location.
Alternately, you can use the debugger to write the break instruction into
the code, e.g. by overwritting the hot patch instruction:

eb cc
eb 90

Works like a charm. After the debugger breaks you can use the “eb”
command to restore the original instructions (if needed).

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7
  1. When the host goes to hibernation, all breakpoints are patched back. You need to enable an initial break, and issue .reload.
  2. If you rebuild the driver, make sure to remove a breakpoint and set it back, if it’s set as symbol+offset.
  3. It helps to always have an initial breakpoint and issue .reload on the system start, if your driver is a bootstart.
  4. Use ‘bu’ command to set a breakpoint, if your driver is not always loaded.
8

Hardware breakpoints are more reliable: ba e1

. However, they
can slow the debugger to a crawl. Also, make sure that the symbols are
loaded for the module where you are setting the breakpoint. ".reload
module = ". I usually just add a KdBreakPoint() to my code
at the appropriate location, which is guaranteed to work. If you only
want to break once you can use a static boolean variable and set it to 0
when the breakpoint is no longer needed:

static BOOLEAN bBreak = 1;

if(bBreak)
KdBreakPoint();

Better to add a couple of lines of code to your debug builds than to
curse the dark. :-)
9

George:
That (KdBreakPoint()) seems like the best bet for now - until
someone at MS decides to tame this beast! All the other tips from you and
others should NOT be needed. All one should need to do is: 1) place the
cursor on the source line and 2) take (any) finger and depress F9 - PERIOD!

Bill

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of George M. Garner Jr.
Sent: Wednesday, August 29, 2012 10:04 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Debugger 6.2.9200.16384 AMD64

Hardware breakpoints are more reliable: ba e1

. However, they can
slow the debugger to a crawl. Also, make sure that the symbols are loaded
for the module where you are setting the breakpoint. ".reload module =
". I usually just add a KdBreakPoint() to my code at the
appropriate location, which is guaranteed to work. If you only want to
break once you can use a static boolean variable and set it to 0 when the
breakpoint is no longer needed:

static BOOLEAN bBreak = 1;

if(bBreak)
KdBreakPoint();

Better to add a couple of lines of code to your debug builds than to curse
the dark. :-)

---
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer