Minor source coloring defect

WINDBG
1

I am enjoying the source code coloring in WinDbg 6.6.3.5.

At the orphan URL http://www.markun.com/ColoringDefect.bmp is what
looks like a minor defect in the coloring; the following line shows
up green for comment but it’s not a comment:

if(False(pTrackReserved->tReserved)

MS devs who agree it’s a problem and want to fix this can contact me
if more info is needed.

Best regards,
David

2

It appears that windbg didn’t find a newline for the previous line. Can
you send us a hex dump of the exact file data between //Unfinished track
and || False(pTrackReserved)?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Markun
Sent: Saturday, February 18, 2006 8:41 PM
To: Kernel Debugging Interest List
Subject: [windbg] Minor source coloring defect

I am enjoying the source code coloring in WinDbg 6.6.3.5.

At the orphan URL http://www.markun.com/ColoringDefect.bmp is what looks
like a minor defect in the coloring; the following line shows up green
for comment but it’s not a comment:

if(False(pTrackReserved->tReserved)

MS devs who agree it’s a problem and want to fix this can contact me if
more info is needed.

Best regards,
David

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

3

Hi All,
I have sent to Drew the requested dump, but it shows normal 0d
0a sequences all the way through.

In reproducing the problem, I found more information which I mention
here, in case it helps other developers to notice that they are
seeing similar things, to help shed light on the problem.

To see the coloring defects, one has to actually step the code. The
code is correctly colored before stepping it, then coloring defects
show up after stepping (F10) through it line by line. The coloring
defects shown in the .bmp file linked below are consistently reproduced:
o Non-comment line shows up green, as I originally reported:
if(False(pTrackReserved->tReserved)
o In comment line
// that with unfinished track on any disc we understand.
note that the “sc” in “disc” are blue, while rest is correctly green
o In text literal
Assert(!“Not expected: unfinished track, but
reserved track already written”);
note that “t r” in “but reserved” is blue, not red like the rest.

Best regards,
David

At 10:44 AM 2/20/2006 -0800, Drew Bliss wrote:
>It appears that windbg didn’t find a newline for the previous line. Can
>you send us a hex dump of the exact file data between //Unfinished track
>and || False(pTrackReserved)?
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of David Markun
>Sent: Saturday, February 18, 2006 8:41 PM
>To: Kernel Debugging Interest List
>Subject: [windbg] Minor source coloring defect
>
>I am enjoying the source code coloring in WinDbg 6.6.3.5.
>
>At the orphan URL http://www.markun.com/ColoringDefect.bmp is what looks
>like a minor defect in the coloring; the following line shows up green
>for comment but it’s not a comment:
>
> >if(False(pTrackReserved->tReserved)
>
>MS devs who agree it’s a problem and want to fix this can contact me if
>more info is needed.
>
>Best regards,
>David

4

I’ll take a look. I’ll be out of the office for all of March so
there’ll probably be a delay before I can get a resolution.

Are there any non-printing characters other than \t, \r and \n in the
file?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Markun
Sent: Saturday, February 25, 2006 8:09 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Minor source coloring defect

Hi All,
I have sent to Drew the requested dump, but it shows normal 0d 0a
sequences all the way through.

In reproducing the problem, I found more information which I mention
here, in case it helps other developers to notice that they are seeing
similar things, to help shed light on the problem.

To see the coloring defects, one has to actually step the code. The
code is correctly colored before stepping it, then coloring defects show
up after stepping (F10) through it line by line. The coloring defects
shown in the .bmp file linked below are consistently reproduced:
o Non-comment line shows up green, as I originally reported:
if(False(pTrackReserved->tReserved)
o In comment line
// that with unfinished track on any disc we
understand.
note that the “sc” in “disc” are blue, while rest is correctly
green
o In text literal
Assert(!“Not expected: unfinished track, but reserved
track already written”);
note that “t r” in “but reserved” is blue, not red like the
rest.

Best regards,
David

At 10:44 AM 2/20/2006 -0800, Drew Bliss wrote:
>It appears that windbg didn’t find a newline for the previous line.
>Can you send us a hex dump of the exact file data between //Unfinished
>track and || False(pTrackReserved)?
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of David Markun
>Sent: Saturday, February 18, 2006 8:41 PM
>To: Kernel Debugging Interest List
>Subject: [windbg] Minor source coloring defect
>
>I am enjoying the source code coloring in WinDbg 6.6.3.5.
>
>At the orphan URL http://www.markun.com/ColoringDefect.bmp is what
>looks like a minor defect in the coloring; the following line shows up
>green for comment but it’s not a comment:
>
> >if(False(pTrackReserved->tReserved)
>
>MS devs who agree it’s a problem and want to fix this can contact me if

>more info is needed.
>
>Best regards,
>David

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