Hi!
every time i set a break point on nt!PsProcessType under Vista beta 2 I get
an access violation with little information. Am I doing something wrong?
–
Cheers,
nt!PsProcessType may be a data field, not a function. Breakpoints, at
least on x86, work by overwriting the instruction with the single-byte
“int 3” opcode, which causes the “debug breakpoint” CPU exception. When
this happens, the debugger looks up the address, patches the byte with
the original value, and re-runs the instruction (which you select
continue).
So if you attempt to do this to a data field, well… you’re just
writing 0xCD to an otherwise healthy field, and in this case, it’s
probably a pointer. Your access violation is probably something like a
reference to 0xnnnnnnCD.
– arlie
From: xxxxx@lists.osr.com on behalf of Marco Peretti
Sent: Thu 6/8/2006 4:27 AM
To: Kernel Debugging Interest List
Subject: [windbg] access violation when setting a bp on nt!PsProcessType
Hi!
every time i set a break point on nt!PsProcessType under Vista beta 2 I
get
an access violation with little information. Am I doing something wrong?
–
Cheers,
Marco
You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi Arlie
PsProcessType is indeed a variable. I have spent way too many hours stepping
through assembly code that I can’t even think & see straight any longer …
time for a break.
thanks for the tip: much appreciated.
–
Cheers,
Marco
“Arlie Davis” wrote in message news:xxxxx@windbg…
nt!PsProcessType may be a data field, not a function. Breakpoints, at
least on x86, work by overwriting the instruction with the single-byte
“int 3” opcode, which causes the “debug breakpoint” CPU exception. When
this happens, the debugger looks up the address, patches the byte with
the original value, and re-runs the instruction (which you select
continue).
So if you attempt to do this to a data field, well… you’re just
writing 0xCD to an otherwise healthy field, and in this case, it’s
probably a pointer. Your access violation is probably something like a
reference to 0xnnnnnnCD.
– arlie
________________________________
From: xxxxx@lists.osr.com on behalf of Marco Peretti
Sent: Thu 6/8/2006 4:27 AM
To: Kernel Debugging Interest List
Subject: [windbg] access violation when setting a bp on nt!PsProcessType
Hi!
every time i set a break point on nt!PsProcessType under Vista beta 2 I
get
an access violation with little information. Am I doing something wrong?
–
Cheers,
Marco
–
—
You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
ARLIE:
Any idea of why breakpoints are implemented this on way on x86, instead
of using hardware? I ran in to some problems with this quite while back
involving software using the to detect the presence of a debugger.
Thanks,
MM
>> xxxxx@microsoft.com 2006-06-08 09:58 >>>
nt!PsProcessType may be a data field, not a function. Breakpoints, at
least on x86, work by overwriting the instruction with the single-byte
“int 3” opcode, which causes the “debug breakpoint” CPU exception.
When
this happens, the debugger looks up the address, patches the byte with
the original value, and re-runs the instruction (which you select
continue).
So if you attempt to do this to a data field, well… you’re just
writing 0xCD to an otherwise healthy field, and in this case, it’s
probably a pointer. Your access violation is probably something like
a
reference to 0xnnnnnnCD.
– arlie
From: xxxxx@lists.osr.com on behalf of Marco Peretti
Sent: Thu 6/8/2006 4:27 AM
To: Kernel Debugging Interest List
Subject: [windbg] access violation when setting a bp on
nt!PsProcessType
Hi!
every time i set a break point on nt!PsProcessType under Vista beta 2
I
get
an access violation with little information. Am I doing something
wrong?
–
Cheers,
Marco
You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to windbg as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
“Martin O’Brien” wrote in message
news:xxxxx@windbg…
> Any idea of why breakpoints are implemented this on way on x86, instead
> of using hardware? I ran in to some problems with this quite while back
> involving software using the to detect the presence of a debugger.
The problem with the x86 hardware support is it is quite limited with only 4
breakpoints. IIRC, at least one infamous chip revision this was one of the
“halt and catch fire” features (I kid you not, there have been chips in the
line that fried or worse).
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
Martin O’Brien wrote:
Any idea of why breakpoints are implemented this on way on x86, instead
of using hardware? I ran in to some problems with this quite while back
involving software using the to detect the presence of a debugger.
Several reasons. WinDBG was invented when NT ran on 80386s and 80486s,
which did not have hardware breakpoints. The INT 3 mechanism for doing
breakpoints goes clear back to the 8088; it is well-tested,
well-understood, and lightweight.
Further, even on modern chips, there are only 3 or 4 hardware
breakpoints registers available. It’s better to reserve those for the
times where they are really required, like watching for memory reads or
writes.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
DON:
Very interesting. Thanks.
MM
>> xxxxx@acm.org 2006-06-08 12:23 >>>
“Martin O’Brien” wrote in message
news:xxxxx@windbg…
> Any idea of why breakpoints are implemented this on way on x86,
instead
> of using hardware? I ran in to some problems with this quite while
back
> involving software using the to detect the presence of a debugger.
The problem with the x86 hardware support is it is quite limited with
only 4
breakpoints. IIRC, at least one infamous chip revision this was one of
the
“halt and catch fire” features (I kid you not, there have been chips in
the
line that fried or worse).
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
—
You are currently subscribed to windbg as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hello Tim,
* On Thu, Jun 08, 2006 at 09:29:31AM -0700 Tim Roberts wrote:
Several reasons. WinDBG was invented when NT ran on 80386s and 80486s,
which did not have hardware breakpoints.
This is not true. The TRx registers were íntroduced with the i386.
Regards,
Spiro Trikaliotis.
–
Spiro R. Trikaliotis xxxxx@trikaliotis.net
University of Magdeburg http://www.trikaliotis.net/
IVS.EUK, P.O.Box 4120 Phone: +49-391-67-12566
39016 Magdeburg, Germany Fax: +49-391-67-11161
Actually, replacing functional code with a “go to the debugger call” to
enter a debugger goes back even further than that. Unless you had a
control panel to enter address and data, that’s how you got to the
debugger to do step into debugging. I started doing this circa
mini-computers but it probably goes well back around the time they found a
dead cock-roach in the circuitry and coined the phrase “a bug in the
computer.”
The personal opinion of
Gary G. Little
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@probo.com
Sent: Thursday, June 08, 2006 11:30 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] access violation when setting a bp on
nt!PsProcessType
Martin O’Brien wrote:
Any idea of why breakpoints are implemented this on way on x86, instead
of using hardware? I ran in to some problems with this quite while back
involving software using the to detect the presence of a debugger.
Several reasons. WinDBG was invented when NT ran on 80386s and 80486s,
which did not have hardware breakpoints. The INT 3 mechanism for doing
breakpoints goes clear back to the 8088; it is well-tested,
well-understood, and lightweight.
Further, even on modern chips, there are only 3 or 4 hardware
breakpoints registers available. It’s better to reserve those for the
times where they are really required, like watching for memory reads or
writes.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
You are currently subscribed to windbg as: xxxxx@seagate.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Spiro Trikaliotis wrote:
Hello Tim,
* On Thu, Jun 08, 2006 at 09:29:31AM -0700 Tim Roberts wrote:
>Several reasons. WinDBG was invented when NT ran on 80386s and 80486s,
>which did not have hardware breakpoints.
>
>This is not true. The TRx registers were íntroduced with the i386.
Doh, you’re quite right. It’s the DRx registers, but there were
certainly present in the 386. My mistake.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
The basic point remains true, though. If the CPU only has 4 breakpoint registers, and you want to support more than 4 breakpoints enabled at a time, then you have to use a different mechanism anyway, such as software breakpoints. And if you have to do that, well, why bother supporting the hardware breakpoints, too?
Also, although I have no evidence for this, I’m willing to bet that the CPU behaves differently when breakpoints are enabled. I’d wager that a lot of the processor front-end (branch predication, out-of-order execution, etc.) gets turned off or dumbed down when any hardware breakpoints are enabled.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, June 08, 2006 10:57 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] access violation when setting a bp on nt!PsProcessType
Spiro Trikaliotis wrote:
Hello Tim,
* On Thu, Jun 08, 2006 at 09:29:31AM -0700 Tim Roberts wrote:
>Several reasons. WinDBG was invented when NT ran on 80386s and
>80486s, which did not have hardware breakpoints.
>
>This is not true. The TRx registers were ?ntroduced with the i386.
Doh, you’re quite right. It’s the DRx registers, but there were certainly present in the 386. My mistake.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hello Tim,
* On Thu, Jun 08, 2006 at 10:56:45AM -0700 Tim Roberts wrote:
Spiro Trikaliotis wrote:
>This is not true. The TRx registers were íntroduced with the i386.
[…]
Doh, you’re quite right. It’s the DRx registers, but there were
certainly present in the 386. My mistake.
Well… Fixing one bug, introducing another one. It is like coding.
Regards,
Spiro.
–
Spiro R. Trikaliotis xxxxx@trikaliotis.net
University of Magdeburg http://www.trikaliotis.net/
IVS.EUK, P.O.Box 4120 Phone: +49-391-67-12566
39016 Magdeburg, Germany Fax: +49-391-67-11161
Gary, you forgot the four magic words: “Admiral Grace Murray Hopper”.
See: http://cs-www.cs.yale.edu/homes/tap/Files/hopper-wit.html
P.S. I am back home in Florida on vacation. Thunderstorms starting, but
the air is clean with NO smog.
wrote in message news:xxxxx@windbg…
> Actually, replacing functional code with a “go to the debugger call” to
> enter a debugger goes back even further than that. Unless you had a
> control panel to enter address and data, that’s how you got to the
> debugger to do step into debugging. I started doing this circa
> mini-computers but it probably goes well back around the time they found a
> dead cock-roach in the circuitry and coined the phrase “a bug in the
> computer.”
>
>
>
> The personal opinion of
> Gary G. Little
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@probo.com
> Sent: Thursday, June 08, 2006 11:30 AM
> To: Kernel Debugging Interest List
> Subject: Re: [windbg] access violation when setting a bp on
> nt!PsProcessType
>
> Martin O’Brien wrote:
>
>>Any idea of why breakpoints are implemented this on way on x86, instead
>>of using hardware? I ran in to some problems with this quite while back
>>involving software using the to detect the presence of a debugger.
>>
>>
>
> Several reasons. WinDBG was invented when NT ran on 80386s and 80486s,
> which did not have hardware breakpoints. The INT 3 mechanism for doing
> breakpoints goes clear back to the 8088; it is well-tested,
> well-understood, and lightweight.
>
> Further, even on modern chips, there are only 3 or 4 hardware
> breakpoints registers available. It’s better to reserve those for the
> times where they are really required, like watching for memory reads or
> writes.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> You are currently subscribed to windbg as: xxxxx@seagate.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Had an uneasy idea about this, trying to clear up my understanding. So
suppose I have a function in my module tp!method as follows:
Address Contents Symbol
0x80808080 0xabababab tp!methodOne
Now in WinDbg I do a bp tp!methodOne. It seems the contents of 0x80808080
will be 0xabababcd ? I dont quite see that happening when I
do a dd tp!methodOne. I m guessing this is hidden from the debugger?
thanks
banks
“Arlie Davis” wrote in message news:xxxxx@windbg…
nt!PsProcessType may be a data field, not a function. Breakpoints, at
least on x86, work by overwriting the instruction with the single-byte
“int 3” opcode, which causes the “debug breakpoint” CPU exception. When
this happens, the debugger looks up the address, patches the byte with
the original value, and re-runs the instruction (which you select
continue).
So if you attempt to do this to a data field, well… you’re just
writing 0xCD to an otherwise healthy field, and in this case, it’s
probably a pointer. Your access violation is probably something like a
reference to 0xnnnnnnCD.
– arlie
________________________________
From: xxxxx@lists.osr.com on behalf of Marco Peretti
Sent: Thu 6/8/2006 4:27 AM
To: Kernel Debugging Interest List
Subject: [windbg] access violation when setting a bp on nt!PsProcessType
Hi!
every time i set a break point on nt!PsProcessType under Vista beta 2 I
get
an access violation with little information. Am I doing something wrong?
–
Cheers,
Marco
–
—
You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
bank kus wrote:
Had an uneasy idea about this, trying to clear up my understanding. So
suppose I have a function in my module tp!method as follows:Address Contents Symbol
0x80808080 0xabababab tp!methodOneNow in WinDbg I do a bp tp!methodOne. It seems the contents of 0x80808080
will be 0xabababcd ? I dont quite see that happening when I
do a dd tp!methodOne. I m guessing this is hidden from the debugger?
Actually, it is 0xabababcc. (The opcode for INT3 is 0xCC, not 0xCD).
No, you won’t see it in the debugger. WinDBG konws where all your
breakpoints are set. When you say “go”, it shoves the 0xCC byte at all
of those locations. When you break back into the debugger, it restores
their original contents. After all, you want to be able to disassemble
the code that’s really there.
However, if you have code that loads from tp!methodOne into eax, and you
run that code while your breakpoint is set, you will see abababcc in eax.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Slightly but not entirely off-topic –
There is at least one other scenario we should exercise caution before setting breakpoints. If you are developing software that does hooking, patching etc. or if you are debugging a process space that loads invasive components (that patches byte codes), keeping breakpoint on a method that could potentially be patched could result in incorrect functionality. As the original byte code at the address where the breakpoint is placed is switched with CC, the code that compares byte code before patching will fail. As the debugger obfuscate the byte code change, the problem won’t be that obvious. When I encountered this issue the first time it drove me crazy (being sick that day I almost thought I popped the wrong pill
Well, my ranting aside, that brings us to a question – Is there a command in WinDbg that would unobfuscate breakpoints?
Kamala
-------------- Original message ----------------------
From: Tim Roberts
> bank kus wrote:
>
> >Had an uneasy idea about this, trying to clear up my understanding. So
> >suppose I have a function in my module tp!method as follows:
> >
> >Address Contents Symbol
> >0x80808080 0xabababab tp!methodOne
> >
> >Now in WinDbg I do a bp tp!methodOne. It seems the contents of 0x80808080
> >will be 0xabababcd ? I dont quite see that happening when I
> >do a dd tp!methodOne. I m guessing this is hidden from the debugger?
> >
> >
>
> Actually, it is 0xabababcc. (The opcode for INT3 is 0xCC, not 0xCD).
>
> No, you won’t see it in the debugger. WinDBG konws where all your
> breakpoints are set. When you say “go”, it shoves the 0xCC byte at all
> of those locations. When you break back into the debugger, it restores
> their original contents. After all, you want to be able to disassemble
> the code that’s really there.
>
> However, if you have code that loads from tp!methodOne into eax, and you
> run that code while your breakpoint is set, you will see abababcc in eax.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> You are currently subscribed to windbg as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
xxxxx@comcast.net wrote:
Slightly but not entirely off-topic –
There is at least one other scenario we should exercise caution before setting breakpoints. If you are developing software that does hooking, patching etc. or if you are debugging a process space that loads invasive components (that patches byte codes), keeping breakpoint on a method that could potentially be patched could result in incorrect functionality. As the original byte code at the address where the breakpoint is placed is switched with CC, the code that compares byte code before patching will fail. As the debugger obfuscate the byte code change, the problem won’t be that obvious. When I encountered this issue the first time it drove me crazy (being sick that day I almost thought I popped the wrong pill
Yes, I was burned by this once when I had to patch two bugs in the Win98
version of stream.sys. It really confused me until I realized what had
gone wrong.
Well, my ranting aside, that brings us to a question – Is there a command in WinDbg that would unobfuscate breakpoints?
I’m not sure what you would want it to do differently. WinDbg has always
supported the hardware breakpoints, using the “ba” command. To do the
equivalent of
bp NtCreateFile
with a hardware breakpoint, you’d do:
ba e1 NtCreateFile
The “e” says “break on execute” (read, write, and I/O port breaks are
also available), the “1” says the break region is 1 byte long.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
By “unobfuscate” do you mean show the code modifications in place? No,
there is no such command. You can use bl to see the exact breakpoint
addresses, so you know where code will be modified.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@comcast.net
Sent: Friday, June 09, 2006 11:48 AM
To: Kernel Debugging Interest List
Cc: Tim Roberts
Subject: Re: [windbg] access violation when setting a bp on
nt!PsProcessType
Slightly but not entirely off-topic -
There is at least one other scenario we should exercise caution before
setting breakpoints. If you are developing software that does hooking,
patching etc. or if you are debugging a process space that loads
invasive components (that patches byte codes), keeping breakpoint on a
method that could potentially be patched could result in incorrect
functionality. As the original byte code at the address where the
breakpoint is placed is switched with CC, the code that compares byte
code before patching will fail. As the debugger obfuscate the byte code
change, the problem won’t be that obvious. When I encountered this
issue the first time it drove me crazy (being sick that day I almost
thought I popped the wrong pill
Well, my ranting aside, that brings us to a question - Is there a
command in WinDbg that would unobfuscate breakpoints?
Kamala
-------------- Original message ----------------------
From: Tim Roberts
> bank kus wrote:
>
> >Had an uneasy idea about this, trying to clear up my understanding.
> >So suppose I have a function in my module tp!method as follows:
> >
> >Address Contents Symbol
> >0x80808080 0xabababab tp!methodOne
> >
> >Now in WinDbg I do a bp tp!methodOne. It seems the contents of
> >0x80808080 will be 0xabababcd ? I dont quite see that happening when
> >I do a dd tp!methodOne. I m guessing this is hidden from the
debugger?
> >
> >
>
> Actually, it is 0xabababcc. (The opcode for INT3 is 0xCC, not 0xCD).
>
> No, you won’t see it in the debugger. WinDBG konws where all your
> breakpoints are set. When you say “go”, it shoves the 0xCC byte at
> all of those locations. When you break back into the debugger, it
> restores their original contents. After all, you want to be able to
> disassemble the code that’s really there.
>
> However, if you have code that loads from tp!methodOne into eax, and
> you run that code while your breakpoint is set, you will see abababcc
in eax.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> You are currently subscribed to windbg as:
> xxxxx@comcast.net To unsubscribe send a blank email to
> xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
I was wondering if I could set a mode in WinDbg that would show code bytes as is. For example, dd
or u would show CC instead of the original code byte. From your response, I take it there isn't one.Yes, I ended up using bl to understand the issue. But, the first time I encountered it, the problem was not obvious enough for me to realize that bl would help.
Thanks,
Kamala
-------------- Original message ----------------------
From: "Drew Bliss"
> By "unobfuscate" do you mean show the code modifications in place? No,
> there is no such command. You can use bl to see the exact breakpoint
> addresses, so you know where code will be modified.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@comcast.net
> Sent: Friday, June 09, 2006 11:48 AM
> To: Kernel Debugging Interest List
> Cc: Tim Roberts
> Subject: Re: [windbg] access violation when setting a bp on
> nt!PsProcessType
>
>
> Slightly but not entirely off-topic -
>
> There is at least one other scenario we should exercise caution before
> setting breakpoints. If you are developing software that does hooking,
> patching etc. or if you are debugging a process space that loads
> invasive components (that patches byte codes), keeping breakpoint on a
> method that could potentially be patched could result in incorrect
> functionality. As the original byte code at the address where the
> breakpoint is placed is switched with CC, the code that compares byte
> code before patching will fail. As the debugger obfuscate the byte code
> change, the problem won't be that obvious. When I encountered this
> issue the first time it drove me crazy (being sick that day I almost
> thought I popped the wrong pill :-)
>
> Well, my ranting aside, that brings us to a question - Is there a
> command in WinDbg that would unobfuscate breakpoints?
>
> Kamala
>
>
> -------------- Original message ----------------------
> From: Tim Roberts
> > bank kus wrote:
> >
> > >Had an uneasy idea about this, trying to clear up my understanding.
> > >So suppose I have a function in my module tp!method as follows:
> > >
> > >Address Contents Symbol
> > >0x80808080 0xabababab tp!methodOne
> > >
> > >Now in WinDbg I do a bp tp!methodOne. It seems the contents of
> > >0x80808080 will be 0xabababcd ? I dont quite see that happening when
> > >I do a dd tp!methodOne. I m guessing this is hidden from the
> debugger?
> > >
> > >
> >
> > Actually, it is 0xabababcc. (The opcode for INT3 is 0xCC, not 0xCD).
> >
> > No, you won't see it in the debugger. WinDBG konws where all your
> > breakpoints are set. When you say "go", it shoves the 0xCC byte at
> > all of those locations. When you break back into the debugger, it
> > restores their original contents. After all, you want to be able to
> > disassemble the code that's really there.
> >
> > However, if you have code that loads from tp!methodOne into eax, and
> > you run that code while your breakpoint is set, you will see abababcc
> in eax.
> >
> > --
> > Tim Roberts, xxxxx@probo.com
> > Providenza & Boekelheide, Inc.
> >
> >
> > ---
> > You are currently subscribed to windbg as:
> > xxxxx@comcast.net To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
>
>
>
> ---
> You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> ---
> You are currently subscribed to windbg as: unknown lmsubst tag argument: ''
> To unsubscribe send a blank email to xxxxx@lists.osr.com
windbg pulls out the modifications entirely on the way to a prompt so
windbg is really showing you code bytes as-is. There is no way to leave
the code modifications from breakpoints in.
-----Original Message-----
From: xxxxx@comcast.net
[mailto:xxxxx@comcast.net]
Sent: Friday, June 09, 2006 2:04 PM
To: Kernel Debugging Interest List; Kernel Debugging Interest List
Cc: Drew Bliss; Tim Roberts
Subject: RE: [windbg] access violation when setting a bp on
nt!PsProcessType
I was wondering if I could set a mode in WinDbg that would show code
bytes as is. For example, dd
instead of the original code byte. From your response, I take it there
isn't one.
Yes, I ended up using bl to understand the issue. But, the first time I
encountered it, the problem was not obvious enough for me to realize
that bl would help.
Thanks,
Kamala
-------------- Original message ----------------------
From: "Drew Bliss"
> By "unobfuscate" do you mean show the code modifications in place?
> No, there is no such command. You can use bl to see the exact
> breakpoint addresses, so you know where code will be modified.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@comcast.net
> Sent: Friday, June 09, 2006 11:48 AM
> To: Kernel Debugging Interest List
> Cc: Tim Roberts
> Subject: Re: [windbg] access violation when setting a bp on
> nt!PsProcessType
>
>
> Slightly but not entirely off-topic -
>
> There is at least one other scenario we should exercise caution before
> setting breakpoints. If you are developing software that does
> hooking, patching etc. or if you are debugging a process space that
> loads invasive components (that patches byte codes), keeping
> breakpoint on a method that could potentially be patched could result
> in incorrect functionality. As the original byte code at the address
> where the breakpoint is placed is switched with CC, the code that
> compares byte code before patching will fail. As the debugger
> obfuscate the byte code change, the problem won't be that obvious.
> When I encountered this issue the first time it drove me crazy (being
> sick that day I almost thought I popped the wrong pill :-)
>
> Well, my ranting aside, that brings us to a question - Is there a
> command in WinDbg that would unobfuscate breakpoints?
>
> Kamala
>
>
> -------------- Original message ----------------------
> From: Tim Roberts
> > bank kus wrote:
> >
> > >Had an uneasy idea about this, trying to clear up my understanding.
> > >So suppose I have a function in my module tp!method as follows:
> > >
> > >Address Contents Symbol
> > >0x80808080 0xabababab tp!methodOne
> > >
> > >Now in WinDbg I do a bp tp!methodOne. It seems the contents of
> > >0x80808080 will be 0xabababcd ? I dont quite see that happening
> > >when I do a dd tp!methodOne. I m guessing this is hidden from the
> debugger?
> > >
> > >
> >
> > Actually, it is 0xabababcc. (The opcode for INT3 is 0xCC, not
0xCD).
> >
> > No, you won't see it in the debugger. WinDBG konws where all your
> > breakpoints are set. When you say "go", it shoves the 0xCC byte at
> > all of those locations. When you break back into the debugger, it
> > restores their original contents. After all, you want to be able to
> > disassemble the code that's really there.
> >
> > However, if you have code that loads from tp!methodOne into eax, and
> > you run that code while your breakpoint is set, you will see
> > abababcc
> in eax.
> >
> > --
> > Tim Roberts, xxxxx@probo.com
> > Providenza & Boekelheide, Inc.
> >
> >
> > ---
> > You are currently subscribed to windbg as:
> > xxxxx@comcast.net To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
>
>
>
> ---
> You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> ---
> You are currently subscribed to windbg as: unknown lmsubst tag
argument: ''
> To unsubscribe send a blank email to xxxxx@lists.osr.com