Applications with embedded breakpoints

OSR_Community_User · December 12, 2005, 4:41pm

One of my “pet peeves” (which isn’t really a WinDBG issue per-se, but
rather an OS handling of embedded application breakpoints that impacts
on the usability of WinDBG) has been that if you boot the kernel with
“/debug” (which is necessary for proper local debugging - such as I do
when demonstrating data structures in class) then ANY application with
an embedded breakpoint will drop into the debugger.

For example, I’m currently running the “windows update” process in a
machine I have that I use for debugging; since I’m not doing development
I didn’t start up the debugger. It appears, however, that the Windows
Media 10 folks decided to leave embedded breakpoints in their code (I
connected the debugger and it immediately attached. The stack backtrace
is all in user mode. I had to type “g” five times in order to get it to
continue.)

Why is this a WinDBG issue? Only because it limits the effectiveness of
local kernel debugging if, by specifying “/debug” to lock down the
debugger structures, you also then open yourself to random applications
that have embedded a breakpoint. Perhaps a “/kmdebug” switch would be a
nice option, so that USER level breakpoints are ignored and kernel level
breakpoints are not. That would make local kernel debugging safe again.

Ah, and now there’s another one. Make it six breakpoints… (ok, this
one is in WM-DRM enabled media player, not Media Player 10.) Another
five - ten total. So its probably in some DLL they both call.

Alternatively, we could round up a firing squad to shoot people who ship
production code with embedded breakpoints. Could be fun - there’s a
shooting range just down the street (on Bel-Red road.)

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com

OSR_Community_User · December 12, 2005, 4:47pm

If you are using Windows Server 2003 or newer (I’m pretty sure it
doesn’t require SP1) you can use kdbgctrl.exe from the debugger packages
to turn this off.

kdbgctrl -du

will disable reflection of UM breaks and single-steps to kd. This is a
global machine state and so is either on or off for all processes.

We have also added some config options for booting. In Windows Server
2003 SP1 you can put /debug=noumex instead of just /debug to start with
user-mode exception reflection disabled.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Monday, December 12, 2005 1:37 PM
To: Kernel Debugging Interest List
Subject: [windbg] Applications with embedded breakpoints

One of my “pet peeves” (which isn’t really a WinDBG issue per-se, but
rather an OS handling of embedded application breakpoints that impacts
on the usability of WinDBG) has been that if you boot the kernel with
“/debug” (which is necessary for proper local debugging - such as I do
when demonstrating data structures in class) then ANY application with
an embedded breakpoint will drop into the debugger.

For example, I’m currently running the “windows update” process in a
machine I have that I use for debugging; since I’m not doing development
I didn’t start up the debugger. It appears, however, that the Windows
Media 10 folks decided to leave embedded breakpoints in their code (I
connected the debugger and it immediately attached. The stack backtrace
is all in user mode. I had to type “g” five times in order to get it to
continue.)

Why is this a WinDBG issue? Only because it limits the effectiveness of
local kernel debugging if, by specifying “/debug” to lock down the
debugger structures, you also then open yourself to random applications
that have embedded a breakpoint. Perhaps a “/kmdebug” switch would be a
nice option, so that USER level breakpoints are ignored and kernel level
breakpoints are not. That would make local kernel debugging safe again.

Ah, and now there’s another one. Make it six breakpoints… (ok, this
one is in WM-DRM enabled media player, not Media Player 10.) Another
five - ten total. So its probably in some DLL they both call.

Alternatively, we could round up a firing squad to shoot people who ship
production code with embedded breakpoints. Could be fun - there’s a
shooting range just down the street (on Bel-Red road.)

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · December 12, 2005, 4:51pm

That suggests an obvious acceptance test, all tests must run unchanged and
unbroken with the local debugger enabled. Make it part of HCT and
whatever app tests are required for the “Designed for …” logo programs.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Monday, December 12, 2005 2:37 PM
To: Kernel Debugging Interest List
Subject: [windbg] Applications with embedded breakpoints

One of my “pet peeves” (which isn’t really a WinDBG issue per-se, but
rather an OS handling of embedded application breakpoints that impacts on
the usability of WinDBG) has been that if you boot the kernel with
“/debug” (which is necessary for proper local debugging - such as I do
when demonstrating data structures in class) then ANY application with an
embedded breakpoint will drop into the debugger.

For example, I’m currently running the “windows update” process in a
machine I have that I use for debugging; since I’m not doing development I
didn’t start up the debugger. It appears, however, that the Windows Media
10 folks decided to leave embedded breakpoints in their code (I connected
the debugger and it immediately attached. The stack backtrace is all in
user mode. I had to type “g” five times in order to get it to continue.)

Why is this a WinDBG issue? Only because it limits the effectiveness of
local kernel debugging if, by specifying “/debug” to lock down the
debugger structures, you also then open yourself to random applications
that have embedded a breakpoint. Perhaps a “/kmdebug” switch would be a
nice option, so that USER level breakpoints are ignored and kernel level
breakpoints are not. That would make local kernel debugging safe again.

Ah, and now there’s another one. Make it six breakpoints. (ok, this one
is in WM-DRM enabled media player, not Media Player 10.) Another five -
ten total. So its probably in some DLL they both call.

Alternatively, we could round up a firing squad to shoot people who ship
production code with embedded breakpoints. Could be fun - there’s a
shooting range just down the street (on Bel-Red road.)

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Gary_Little-2 · December 12, 2005, 4:53pm

Agreed, and their feet get placed in the fire until they quiet their debug
spew for released code . Don’t you just enjoy the SMBios crap in the
middle of your debug session?

How about some kind of a published “Thar be Monsters” list for these lazy
folks?

Gary G. Little

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Monday, December 12, 2005 3:37 PM
To: Kernel Debugging Interest List
Subject: [windbg] Applications with embedded breakpoints

One of my “pet peeves” (which isn’t really a WinDBG issue per-se, but
rather an OS handling of embedded application breakpoints that impacts on
the usability of WinDBG) has been that if you boot the kernel with
“/debug” (which is necessary for proper local debugging - such as I do
when demonstrating data structures in class) then ANY application with an
embedded breakpoint will drop into the debugger.

For example, I’m currently running the “windows update” process in a
machine I have that I use for debugging; since I’m not doing development I
didn’t start up the debugger. It appears, however, that the Windows Media
10 folks decided to leave embedded breakpoints in their code (I connected
the debugger and it immediately attached. The stack backtrace is all in
user mode. I had to type “g” five times in order to get it to continue.)

Why is this a WinDBG issue? Only because it limits the effectiveness of
local kernel debugging if, by specifying “/debug” to lock down the
debugger structures, you also then open yourself to random applications
that have embedded a breakpoint. Perhaps a “/kmdebug” switch would be a
nice option, so that USER level breakpoints are ignored and kernel level
breakpoints are not. That would make local kernel debugging safe again.

Ah, and now there’s another one. Make it six breakpoints. (ok, this one
is in WM-DRM enabled media player, not Media Player 10.) Another five -
ten total. So its probably in some DLL they both call.

Alternatively, we could round up a firing squad to shoot people who ship
production code with embedded breakpoints. Could be fun - there’s a
shooting range just down the street (on Bel-Red road.)

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · December 12, 2005, 4:55pm

Thanks for the hint Drew. Unfortunately, my laptop (for example, which
is where I first experienced this) is XPSP2, as is the machine in
question. But this is a good trick for XP 64-bit and W2K3. Apparently
I’m not the only person who was annoyed by this.

Does this mean we don’t get to use these app developers for target
practice?

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 24-27, 2006.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Monday, December 12, 2005 4:47 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Applications with embedded breakpoints