Thanks ken for reply.
But i face the same problem of slowdown even after using bp /t ETHREAD
Is their some work around for this. I am using serial cable for debugging.
Does it make any difference if i start using 1394 for debugging
---------- Forwarded message ----------
From: Skywing
Date: Jun 18, 2007 11:49 PM
Subject: Re:[windbg] conditional break point
To: Kernel Debugging Interest List
If you want to restrict a breakpoint to a particular thread, it would be
simpler to just use bp /t ETHREAD […].
I suspect you might be running into trouble because conditional breakpoints
take time to evaluate and as such, using them on “hot” code paths is often
not the best experience due to the slowdown involved.
–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Rohit” wrote in message news:xxxxx@windbg…
I have put a conditional breakpoint
bp nt!CcCanIWrite “j poi(@fs:[124])=0x856963f8 ‘!thread’;‘gc’”
for stopping the debugger when CcCanIWrite is executed by a particular
thread. But after i set this breakpoint the system goes into hang state.
Experts please tell me what i am doing wrong. the version of windbg i am
using is 6.6.0007.5
—
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Regards
Rohit Gauba
“A positive thought is the seed of a positive result”
one more information. The machine i used for debugging has two processor and
os is win2k3.
---------- Forwarded message ----------
From: Rohit
Date: Jun 19, 2007 5:02 PM
Subject: Fwd: [windbg] conditional break point
To: xxxxx@lists.osr.com
Thanks ken for reply.
But i face the same problem of slowdown even after using bp /t ETHREAD
Is their some work around for this. I am using serial cable for debugging.
Does it make any difference if i start using 1394 for debugging
---------- Forwarded message ----------
From: Skywing
Date: Jun 18, 2007 11 <javascript:void>:49 PM
Subject: Re:[windbg] conditional break point
To: Kernel Debugging Interest List
If you want to restrict a breakpoint to a particular thread, it would be
simpler to just use bp /t ETHREAD […].
I suspect you might be running into trouble because conditional breakpoints
take time to evaluate and as such, using them on “hot” code paths is often
not the best experience due to the slowdown involved.
–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Rohit” wrote in message news:xxxxx@windbg…
I have put a conditional breakpoint
bp nt!CcCanIWrite “j poi(@fs:[124])=0x856963f8 ‘!thread’;‘gc’”
for stopping the debugger when CcCanIWrite is executed by a particular
thread. But after i set this breakpoint the system goes into hang state.
Experts please tell me what i am doing wrong. the version of windbg i am
using is 6.6.0007.5
—
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Regards
Rohit Gauba
“A positive thought is the seed of a positive result”
–
Regards
Rohit Gauba
“A positive thought is the seed of a positive result”</javascript:void>
Hello,
* On Tue, Jun 19, 2007 at 05:10:59PM +0530 Rohit wrote:
one more information. The machine i used for debugging has two
processor and os is win2k3.
I remember someone from the WinDBG team once wrote here (or in a
newsgroup) that a slowdown on machines with more than one processor
(virtual or not) is by design. This would be because the debugger has to
stop both processors every time it wants to break in.
Possibly, the same occurs if it wants to evaluate a conditional
breakpoint, as in your case?
Regards,
Spiro.
–
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
Conditional bpx are slow. I normally compile an extra function of sizeable body in the debug driver.
At runtime, for condtional bpx, I place a jmp to this function and place the conditional logic followed by int3 here. Your jump opcode could have displaced some opcodes from the original function, so copy them in the jumped location.
With reasonable practise you can do this quickly and this is fast.
“Rohit” wrote in message news:xxxxx@windbg…
Thanks ken for reply.
But i face the same problem of slowdown even after using bp /t ETHREAD
Is their some work around for this. I am using serial cable for debugging. Does it make any difference if i start using 1394 for debugging
---------- Forwarded message ----------
From: Skywing
Date: Jun 18, 2007 11:49 PM
Subject: Re:[windbg] conditional break point
To: Kernel Debugging Interest List
If you want to restrict a breakpoint to a particular thread, it would be simpler to just use bp /t ETHREAD […].
I suspect you might be running into trouble because conditional breakpoints take time to evaluate and as such, using them on “hot” code paths is often not the best experience due to the slowdown involved.
–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Rohit” wrote in message news:xxxxx@windbg…
I have put a conditional breakpoint
bp nt!CcCanIWrite “j poi(@fs:[124])=0x856963f8 ‘!thread’;‘gc’”
for stopping the debugger when CcCanIWrite is executed by a particular thread. But after i set this breakpoint the system goes into hang state.
Experts please tell me what i am doing wrong. the version of windbg i am using is 6.6.0007.5
—
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Regards
Rohit Gauba
“A positive thought is the seed of a positive result”
As an aside, I believe the conditional bpx syntax provided by Windbg is way too complicated. Compare with gdb
condition 2 ( thisStamp == 0xfff )
banks
“Rohit” wrote in message news:xxxxx@windbg…
I have put a conditional breakpoint
bp nt!CcCanIWrite “j poi(@fs:[124])=0x856963f8 ‘!thread’;‘gc’”
for stopping the debugger when CcCanIWrite is executed by a particular thread. But after i set this breakpoint the system goes into hang state.
Experts please tell me what i am doing wrong. the version of windbg i am using is 6.6.0007.5
bank kus wrote:
As an aside, I believe the conditional bpx syntax provided by Windbg
is way too complicated. Compare with gdb
condition 2 ( thisStamp == 0xfff )
Probably so, but like many Microsoft products, windbg is somewhat
crippled by the design goal of maintaining compatibility with the
ancients. The current syntax was part of wdeb386, which was developed
for Windows 386 approximately 20 years ago. At that time, the debugger
had to be able to function properly on a machine with less than a
megabyte of memory. A fully functional command expression interpreter
was just not to be.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.