Setting a breakpoint makes TARGET extremely slow

WINDBG
1

Once I set a breakpoint in my code by pressing the hand icon in WinDbg, the
targer machine starts to run extemely slow. Once I then use the bd command
to disable the breakpoint, it starts running normally, once I use the be
command to enable it again, the problem immediately returns. So, it looks
like having breakpoints active somehow causes this problem. This happens
with an old WinDbg (as you see in the log below) as well as with the newest
one. It started happening in the recent months or so on at least two
independent machines. Both machines are regularly updated with Windows
Update, and I suspect that some update could have introduced this.

Microsoft (R) Windows Debugger Version 6.2.0007.4

Copyright (c) Microsoft Corporation. All rights reserved.

Using 1394 for debugging

Opened \.\DBG1394_INSTANCE01

Waiting to reconnect…

Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE

Kernel Debugger connection established.

Symbol search path is:
srv*c:\websymbols*http://msdl.microsoft.com/download/symbols

Executable search path is:

Windows XP Kernel Version 2600 MP (1 procs) Free x86 compatible

Built by: 2600.xpsp_sp2_rtm.040803-2158

Kernel base = 0x804d7000 PsLoadedModuleList = 0x805644a0

System Uptime: not avai

2

If the address is paged out, the target will try and reinsert the
breakpoint on every page-in.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ivan Bublikov
Sent: Wednesday, February 23, 2005 2:52 PM
To: Kernel Debugging Interest List
Subject: [windbg] Setting a breakpoint makes TARGET extremely slow

Once I set a breakpoint in my code by pressing the hand icon in WinDbg,
the
targer machine starts to run extemely slow. Once I then use the bd
command
to disable the breakpoint, it starts running normally, once I use the be

command to enable it again, the problem immediately returns. So, it
looks
like having breakpoints active somehow causes this problem. This happens

with an old WinDbg (as you see in the log below) as well as with the
newest
one. It started happening in the recent months or so on at least two
independent machines. Both machines are regularly updated with Windows
Update, and I suspect that some update could have introduced this.

Microsoft (R) Windows Debugger Version 6.2.0007.4

Copyright (c) Microsoft Corporation. All rights reserved.

Using 1394 for debugging

Opened \.\DBG1394_INSTANCE01

Waiting to reconnect…

Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE

Kernel Debugger connection established.

Symbol search path is:
srv*c:\websymbols*http://msdl.microsoft.com/download/symbols

Executable search path is:

Windows XP Kernel Version 2600 MP (1 procs) Free x86 compatible

Built by: 2600.xpsp_sp2_rtm.040803-2158

Kernel base = 0x804d7000 PsLoadedModuleList = 0x805644a0

System Uptime: not avai

You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

What can I do to fix this? Right now the only thing I can do to set a
breakpoint is to insert KdBreakPoint into the source code and rebuild. Is
there a debugger command that I can use to force the OS to page-in the whole
driver? BTW, I have Driver Verifier enabled for my driver. Does it
contribute to the “paged-out” problem. I used DV before but I don’t recall
ever hitting this problem few months ago…

“Jason Shay” wrote in message
news:xxxxx@windbg…
If the address is paged out, the target will try and reinsert the
breakpoint on every page-in.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ivan Bublikov
Sent: Wednesday, February 23, 2005 2:52 PM
To: Kernel Debugging Interest List
Subject: [windbg] Setting a breakpoint makes TARGET extremely slow

Once I set a breakpoint in my code by pressing the hand icon in WinDbg,
the
targer machine starts to run extemely slow. Once I then use the bd
command
to disable the breakpoint, it starts running normally, once I use the be

command to enable it again, the problem immediately returns. So, it
looks
like having breakpoints active somehow causes this problem. This happens

with an old WinDbg (as you see in the log below) as well as with the
newest
one. It started happening in the recent months or so on at least two
independent machines. Both machines are regularly updated with Windows
Update, and I suspect that some update could have introduced this.

Microsoft (R) Windows Debugger Version 6.2.0007.4

Copyright (c) Microsoft Corporation. All rights reserved.

Using 1394 for debugging

Opened \.\DBG1394_INSTANCE01

Waiting to reconnect…

Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE

Kernel Debugger connection established.

Symbol search path is:
srvc:\websymbolshttp://msdl.microsoft.com/download/symbols

Executable search path is:

Windows XP Kernel Version 2600 MP (1 procs) Free x86 compatible

Built by: 2600.xpsp_sp2_rtm.040803-2158

Kernel base = 0x804d7000 PsLoadedModuleList = 0x805644a0

System Uptime: not avai

—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

I had this annoying problem a while ago.
I figured then the slow down effect happened
whenever I used a breakpoint within a paged code area ( #pragma
alloc_text(PAGE,…) ).
Try to #ifndef DBG those pragmas and see if the problem goes away.

It does sound as a debugger bug to me.

  • Vitaly

Subject: Re: Setting a breakpoint makes TARGET extremely slow
From: “Ivan Bublikov”
Date: Thu, 24 Feb 2005 15:31:31 -0600
X-Message-Number: 1

What can I do to fix this? Right now the only thing I can do to set a
breakpoint is to insert KdBreakPoint into the source code and rebuild.
Is
there a debugger command that I can use to force the OS to page-in the
whole
driver? BTW, I have Driver Verifier enabled for my driver. Does it
contribute to the “paged-out” problem. I used DV before but I don’t
recall
ever hitting this problem few months ago…

“Jason Shay” wrote in message
news:xxxxx@windbg…
If the address is paged out, the target will try and reinsert the
breakpoint on every page-in.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ivan Bublikov
Sent: Wednesday, February 23, 2005 2:52 PM
To: Kernel Debugging Interest List
Subject: [windbg] Setting a breakpoint makes TARGET extremely slow

Once I set a breakpoint in my code by pressing the hand icon in WinDbg,
the targer machine starts to run extemely slow. Once I then use the bd
command to disable the breakpoint, it starts running normally, once I
use the be

command to enable it again, the problem immediately returns. So, it
looks like having breakpoints active somehow causes this problem. This
happens

with an old WinDbg (as you see in the log below) as well as with the
newest one. It started happening in the recent months or so on at least
two independent machines. Both machines are regularly updated with
Windows Update, and I suspect that some update could have introduced
this.

Microsoft (R) Windows Debugger Version 6.2.0007.4

Copyright (c) Microsoft Corporation. All rights reserved.

Using 1394 for debugging

Opened \.\DBG1394_INSTANCE01

Waiting to reconnect…

Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE

Kernel Debugger connection established.

Symbol search path is:
srvc:\websymbolshttp://msdl.microsoft.com/download/symbols

Executable search path is:

Windows XP Kernel Version 2600 MP (1 procs) Free x86 compatible

Built by: 2600.xpsp_sp2_rtm.040803-2158

Kernel base = 0x804d7000 PsLoadedModuleList = 0x805644a0

System Uptime: not avai

—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com