Re: New line in WPP trace

NTDEV
1

the deletion of ‘\n’ is not justifiable. the reason given was
“grep” then i laughed my ass off - not a windows program.
(sure use cygwin if you don’t like windows utilities.)

what else is deleted and is this documented? or is it guess
and use non-windows software to debug?

next justification please.

brucee

On 2/15/07, Mark Roddy wrote:
> As far as I am concerned, all I wanted from WPP was a generic implementation
> of a virtual console for capturing runtime trace information in a flexible
> efficient manner, ideally a solution that one had a reasonable hope would be
> retrievable from a crash dump. The solution provided is too complicated and
> too incompatible with DebugPrint to be widely adopted. Some of us have been
> pointing this out for years now, and not getting very far. Many of us will
> instead continue to use our own custom solutions.
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com [mailto:bounce-278202-
> > xxxxx@lists.osr.com] On Behalf Of Don Burn
> > Sent: Wednesday, February 14, 2007 3:57 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] New line in WPP trace
> >
> >
> > “Martin O’Brien” wrote in message
> > news:xxxxx@ntdev…
> > > Just one humble programmer’s opinion: that WPP features alternative
> > > frameworks to replace essentially universal constructs like ‘\n’ does
> > > not make me wish to learn to use it, whatever else it may offer. It
> > > kind of just says “work.”
> > >
> > > mm
> > >
> >
> > Martin,
> >
> > You sound like a Lin-suck’s guy I know that refures to use
> > Windows
> > because it uses backslash instead of slash! WPP is well worth trying,
> > and
> > there are justifiable reasons for removing newlines, for instance being
> > able to grep for all patterns specific type.
> >
> > I wish we could get you and others to sit down with Jose and
> > have a
> > true feedback session. Unfortunately, Microsoft seems to have
> > eliminated
> > those from WinHEC, since they got rid of BOF’s. This was the best
> > reason
> > to go to the conference, and their elimination will probably mean I
> > skip
> > this one after 10 years of attendance.
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > http://www.windrvr.com
> > Remove StopSpam from the email to reply
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

2

i thought it was absurd that ‘\n’ was stripped, by the pre-processor i guess.
if the claims that “just throw it in octal” are true then i will laugh
more, as this
means that the pre-processor parses the formatting strings and is
required to nuke
them, probably took a few weeks and 100 man hours of meetings to
make this decision. good to see it was fruitless, whatever the intention was.

if you believe the “grep - we don’t use windows software” then you can also
get around this by using something distinctive like “” and use sed to
get back those evil newlines. they must be bad. can someone explain why
and i’ll shut up.

personally all debug output i ever use i expect that what i output
is what i get.
maybe that’s why it takes an order of magnitude more to deal with a windows
driver than on anything i’ve ever worked with - even a cray xmp doesn’t screw
with what i want to trace, and it manages to not screw with things
very swiftly…

brucee

anyhow. a “%c” with an argument of ‘\n’ will subvert this obviously very
important feature. no-one has explained why it is important, so i will dwell
on a minor point that has no point.

what’s the big deal about newlines. well microsoft spent a lot of money to
not get it right, whatever they were trying to do.

On 2/16/07, Michal Vodicka wrote:
> Lock? Hey, I have an idea. DebugView hooks DbgPrint so maybe lock can be avoided. I turned off passthrough option so kernel print code won’t be called. And guess what. Now there are 2000 cycles for print without parameters and 4000 for 3 parameters. With minimal fluctuation now.
>
> I guess previous 100% fluctuation was just because of the lock. No need to measure, just compute. In the worst case one CPU will wait for all other CPUs. So it’d take N * normal time. I tested it at dual CPU machine and the results meat this expenctation.
>
> Conslusion: DebugView with passthrough turned off improves things so they’re comparable with WPP. Not a big surprise for me; I examined WPP code which has to deal with GUIDs and isn’t short.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
> > ----------
> > From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Friday, February 16, 2007 1:20 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] New line in WPP trace
> >
> > Now try your measurements with multiple threads all pounding DbgPrint at
> > the same time so that there is contention on the DbgPrint lock :wink:
> >
> > d
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> > Sent: Thursday, February 15, 2007 4:02 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] New line in WPP trace
> >
> > I made a quick test and measured DbgPrint captured by DebugView. Call
> > with no formatting parameters took less than 9500 cycles and call with 3
> > parameters took less than 15000 cycles. Not a big difference against WPP
> > if you compute real time spent at modern CPU.
> >
> > Above are best cases measured by dreaded KeQueryPerformanceCounter();
> > the worst cases were up to 100% more.
> >
> > Best regards,
> >
> > Michal Vodicka
> > UPEK, Inc.
> > [xxxxx@upek.com, http://www.upek.com]
> >
> >
> > > ----------
> > > From:
> > xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
> >] on behalf of Alex Bendetov[SMTP:xxxxx@hotmail.com]
> > > Reply To: Windows System Software Devs Interest List
> > > Sent: Thursday, February 15, 2007 10:56 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] New line in WPP trace
> > >
> > > DebugPrint from KernelMode even when consumed locally (via DebugView)
> > can still be quite expensive. (QueryDebugFilterState, sprintf, raise
> > IRQL, do callback, callback does some more work, etc…). TraceMessage
> > is quite simpler and is non-blocking and non-spinning. I don’t have
> > numbers for DebugPrint, but TraceMessage was under 2k cycles when I
> > measured it.
> > > Alex
> > >
> > > > Subject: RE: [ntdev] New line in WPP trace
> > > > Date: Thu, 15 Feb 2007 21:41:06 +0100
> > > > From: xxxxx@upek.com
> > > > To: xxxxx@lists.osr.com
> > > >
> > > > > ----------
> > > > > From:
> > xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
> >] on behalf of Yossi Leybovich[SMTP:xxxxx@mellanox.co.il]
> > > > > Reply To: Windows System Software Devs Interest List
> > > > > Sent: Thursday, February 15, 2007 8:34 AM
> > > > > To: Windows System Software Devs Interest List
> > > > > Subject: RE: [ntdev] New line in WPP trace
> > > > >
> > > > > We wrote whole bunch of networking drivers that ran in 10Gbs and
> > in
> > > > > order to debug races and scenarios that happen when there is
> > > > > traffic load I found it very helpful to use WPP (and I think it’s
> > the
> > > > > only way I can see output without loosing performance).
> > > > >
> > > > That’s the only reason why I still didn’t rejected the idea of using
> > WPP completely. But is there a real difference? When traces are turned
> > on, is there a difference between traditional approach when traces are>
> > printed via DbgPrint() and captured by DebugView and WPP captured some
> > other way? In both cases there is an overhead which probably differs.
> > Does anybody have some numbers?
> > > >
> > > > Did you see any differences between both approaches when debugging
> > races? This is the only area where my traces sometimes cause that
> > problem can’t be reproduced (but in other cases problem can be
> > reproduced only with traces :slight_smile:
> > > >
> > > > > I don’t think that event log is the right tool for tracing or
> > debugging
> > > > > specially not when you debug networking events in 10Gbs.
> > > > >
> > > > Sure, event log has quite different purpose.
> > > >
> > > > > Maybe there should be a way to ran preprocessor before the WPP
> > > > > preprocessor so one can use WPP from within macros.
> > > > >
> > > > This is one of things which discourages me. Everything would be much
> > easier if one can use standard preprocessor macros and just call a
> > function which’d make trace. I also use special macros for function
> > enter and leave. In addition to ==> and <== they indent/outdent output
> > and compute time elapsed in the function/block. The whole idea with
> > special preprocessor for traces is IMO flawed and shows too much power
> > is harmful, sometimes.
> > > >
> > > > Best regards,
> > > >
> > > > Michal Vodicka
> > > > UPEK, Inc.
> > > > [xxxxx@upek.com, http://www.upek.com]
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> > >
> > >
> > >
> > > _____
> > >
> > > Live Search: New search found Try it!
> > http:
> > > —
> > > Questions? First check the Kernel Driver FAQ at >
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> > >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
></http:>

3

Comments inline:
“Bruce Ellis” wrote in message news:xxxxx@ntdev…
>i thought it was absurd that ‘\n’ was stripped, by the pre-processor i
>guess.
> if the claims that “just throw it in octal” are true then i will laugh
> more, as this
> means that the pre-processor parses the formatting strings and is
> required to nuke
> them, probably took a few weeks and 100 man hours of meetings to
> make this decision. good to see it was fruitless, whatever the intention
> was.

You obviously do not understand WPP tracing, since the formatting strings
are not in the executable, so you are not wasting the time of parsing this
like printf. This is one of the strongest features of WPP tracing, it just
copies the binary values (so yes needs to know their size and parse as part
of the pre-process).

Having been a compiler and runtime guy for many years, I know how much
people in the compiler world cursed printf since it produces crappy
performance. There were arguments over the years of trying to tweak it or
replace it because interpreting format strings totally at runtime is a poor
idea.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

4

I think there is a detail being misunderstood here.

It is ALL newline characters (of any form) that are being stripped (0x0A
characters) which is a trivial operation to do. The work around does not
involve putting the newline back, rather it relies on the fact that to
the record oriented trace a carriage return (0x0D character) has the
same effect.

I may have confused you by listing the newline character which is
ignored by WPP but is required when the same code is compiled to use
normal printf statements as some people do - I frequently mix and match
during testing. In that case the Carriage Return is redundant but
harmless.

Use of %c and a ‘\n’ value does work but is more overhead, basically all
of the format string stuff above is handled by the post processing and
costs nothing in execution time, but an argument like this has to be
processed at execution time. Remember the goal is to do the minimum up
front and do all the expensive formatting later. This might seem a
trivial amount but it all adds up.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bruce Ellis
Sent: Thursday, February 15, 2007 11:29 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] New line in WPP trace

i thought it was absurd that ‘\n’ was stripped, by the pre-processor i
guess.
if the claims that “just throw it in octal” are true then i will laugh
more, as this
means that the pre-processor parses the formatting strings and is
required to nuke
them, probably took a few weeks and 100 man hours of meetings to
make this decision. good to see it was fruitless, whatever the
intention was.

if you believe the “grep - we don’t use windows software” then you can
also
get around this by using something distinctive like “” and use sed
to
get back those evil newlines. they must be bad. can someone explain
why
and i’ll shut up.

personally all debug output i ever use i expect that what i output
is what i get.
maybe that’s why it takes an order of magnitude more to deal with a
windows
driver than on anything i’ve ever worked with - even a cray xmp doesn’t
screw
with what i want to trace, and it manages to not screw with things
very swiftly…

brucee

anyhow. a “%c” with an argument of ‘\n’ will subvert this obviously
very
important feature. no-one has explained why it is important, so i will
dwell
on a minor point that has no point.

what’s the big deal about newlines. well microsoft spent a lot of money
to
not get it right, whatever they were trying to do.

On 2/16/07, Michal Vodicka wrote:
> Lock? Hey, I have an idea. DebugView hooks DbgPrint so maybe lock can
be avoided. I turned off passthrough option so kernel print code won’t
be called. And guess what. Now there are 2000 cycles for print without
parameters and 4000 for 3 parameters. With minimal fluctuation now.
>
> I guess previous 100% fluctuation was just because of the lock. No
need to measure, just compute. In the worst case one CPU will wait for
all other CPUs. So it’d take N * normal time. I tested it at dual CPU
machine and the results meat this expenctation.
>
> Conslusion: DebugView with passthrough turned off improves things so
they’re comparable with WPP. Not a big surprise for me; I examined WPP
code which has to deal with GUIDs and isn’t short.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
> > ----------
> > From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Friday, February 16, 2007 1:20 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] New line in WPP trace
> >
> > Now try your measurements with multiple threads all pounding
DbgPrint at
> > the same time so that there is contention on the DbgPrint lock :wink:
> >
> > d
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal
Vodicka
> > Sent: Thursday, February 15, 2007 4:02 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] New line in WPP trace
> >
> > I made a quick test and measured DbgPrint captured by DebugView.
Call
> > with no formatting parameters took less than 9500 cycles and call
with 3
> > parameters took less than 15000 cycles. Not a big difference against
WPP
> > if you compute real time spent at modern CPU.
> >
> > Above are best cases measured by dreaded
KeQueryPerformanceCounter();
> > the worst cases were up to 100% more.
> >
> > Best regards,
> >
> > Michal Vodicka
> > UPEK, Inc.
> > [xxxxx@upek.com, http://www.upek.com]
> >
> >
> > > ----------
> > > From:
> >
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
> >] on behalf of Alex Bendetov[SMTP:xxxxx@hotmail.com]
> > > Reply To: Windows System Software Devs Interest List
> > > Sent: Thursday, February 15, 2007 10:56 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] New line in WPP trace
> > >
> > > DebugPrint from KernelMode even when consumed locally (via
DebugView)
> > can still be quite expensive. (QueryDebugFilterState, sprintf, raise
> > IRQL, do callback, callback does some more work, etc…).
TraceMessage
> > is quite simpler and is non-blocking and non-spinning. I don’t have
> > numbers for DebugPrint, but TraceMessage was under 2k cycles when I
> > measured it.
> > > Alex
> > >
> > > > Subject: RE: [ntdev] New line in WPP trace
> > > > Date: Thu, 15 Feb 2007 21:41:06 +0100
> > > > From: xxxxx@upek.com
> > > > To: xxxxx@lists.osr.com
> > > >
> > > > > ----------
> > > > > From:
> >
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
> >] on behalf of Yossi Leybovich[SMTP:xxxxx@mellanox.co.il]
> > > > > Reply To: Windows System Software Devs Interest List
> > > > > Sent: Thursday, February 15, 2007 8:34 AM
> > > > > To: Windows System Software Devs Interest List
> > > > > Subject: RE: [ntdev] New line in WPP trace
> > > > >
> > > > > We wrote whole bunch of networking drivers that ran in 10Gbs
and
> > in
> > > > > order to debug races and scenarios that happen when there is
> > > > > traffic load I found it very helpful to use WPP (and I think
it’s
> > the
> > > > > only way I can see output without loosing performance).
> > > > >
> > > > That’s the only reason why I still didn’t rejected the idea of
using
> > WPP completely. But is there a real difference? When traces are
turned
> > on, is there a difference between traditional approach when traces
are>
> > printed via DbgPrint() and captured by DebugView and WPP captured
some
> > other way? In both cases there is an overhead which probably
differs.
> > Does anybody have some numbers?
> > > >
> > > > Did you see any differences between both approaches when
debugging
> > races? This is the only area where my traces sometimes cause that
> > problem can’t be reproduced (but in other cases problem can be
> > reproduced only with traces :slight_smile:
> > > >
> > > > > I don’t think that event log is the right tool for tracing or
> > debugging
> > > > > specially not when you debug networking events in 10Gbs.
> > > > >
> > > > Sure, event log has quite different purpose.
> > > >
> > > > > Maybe there should be a way to ran preprocessor before the WPP
> > > > > preprocessor so one can use WPP from within macros.
> > > > >
> > > > This is one of things which discourages me. Everything would be
much
> > easier if one can use standard preprocessor macros and just call a
> > function which’d make trace. I also use special macros for function
> > enter and leave. In addition to ==> and <== they indent/outdent
output
> > and compute time elapsed in the function/block. The whole idea with
> > special preprocessor for traces is IMO flawed and shows too much
power
> > is harmful, sometimes.
> > > >
> > > > Best regards,
> > > >
> > > > Michal Vodicka
> > > > UPEK, Inc.
> > > > [xxxxx@upek.com, http://www.upek.com]
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> > >
> > >
> > >
> > > _____
> > >
> > > Live Search: New search found Try it!
> > http:
> > > —
> > > Questions? First check the Kernel Driver FAQ at >
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> > >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> >
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:>

5

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Don Burn[SMTP:xxxxx@acm.org]
Reply To: Windows System Software Devs Interest List
Sent: Friday, February 16, 2007 2:17 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] New line in WPP trace

Having been a compiler and runtime guy for many years, I know how much
people in the compiler world cursed printf since it produces crappy
performance. There were arguments over the years of trying to tweak it or
replace it because interpreting format strings totally at runtime is a poor
idea.

Don,

have you noticed the numbers I measured? DbgPrint performance is comparable to WPP when DebugView is used. So maybe this poor idea is comparable with another poor idea :wink:

I just want to say we talk about times in microseconds at modern CPUs in both cases and that poor DbgPrint performance against WPP is a myth.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

6

I saw the numbers, calling it a myth is way too strong, saying your mileage
may vary is ok. I have seen terrible performance hits using DbgView (to
the point that timing bugs go away), so I guess I can’t accept the myth
claim, any more than you can accept the degradation claim.

Personally, the performance was not the reason I endorse WPP tracing so
much. The reasons I like to use it are:

  1. The logs are not readable without the proper data to decode things.
    Personally, I am just as happy to not show the log to every customer. I
    have one firm I work with that any message a customer may see must go
    through legal, try sitting down with a lawyer about logging.

  2. The drivers are smaller with WPP tracing than with DbgPrints.
    Sorry, I know “computers have tons of memory” but that doesn’t help on a
    big project with a small memory in a computer.

  3. The flexibility of the extended formatting. Yes, when I am deep
    in it, I can remember a fair number of NTSTATUS codes by their hex values,
    but it is awfully nice to not have to. Also, since I use enum’s a lot, I
    love the ability to display the value name not the number.

I don’t expect everyone to agree with me on this, but I find WPP tracing
has so many nice features, that it more than offsets the few wonky things
present.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of Don Burn[SMTP:xxxxx@acm.org]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, February 16, 2007 2:17 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] New line in WPP trace
>
> Having been a compiler and runtime guy for many years, I know how much
> people in the compiler world cursed printf since it produces crappy
> performance. There were arguments over the years of trying to tweak it
> or
> replace it because interpreting format strings totally at runtime is a
> poor
> idea.
>
Don,

have you noticed the numbers I measured? DbgPrint performance is comparable
to WPP when DebugView is used. So maybe this poor idea is comparable with
another poor idea :wink:

I just want to say we talk about times in microseconds at modern CPUs in
both cases and that poor DbgPrint performance against WPP is a myth.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

7

Sorry forgot one other biggie:

  1. DbgView is not “standard software” there are a ton of customers
    that require a test period and corporate signoff at the VP level to install
    ANY NEW SOFTWARE on a computer. The stuff to get a WPP tracing log is
    standard on Windows, DbgView is not,

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Don Burn” wrote in message news:xxxxx@ntdev…
>I saw the numbers, calling it a myth is way too strong, saying your
>mileage may vary is ok. I have seen terrible performance hits using
>DbgView (to the point that timing bugs go away), so I guess I can’t accept
>the myth claim, any more than you can accept the degradation claim.
>
> Personally, the performance was not the reason I endorse WPP tracing so
> much. The reasons I like to use it are:
>
> 1. The logs are not readable without the proper data to decode
> things. Personally, I am just as happy to not show the log to every
> customer. I have one firm I work with that any message a customer may
> see must go through legal, try sitting down with a lawyer about logging.
>
> 2. The drivers are smaller with WPP tracing than with DbgPrints.
> Sorry, I know “computers have tons of memory” but that doesn’t help on a
> big project with a small memory in a computer.
>
> 3. The flexibility of the extended formatting. Yes, when I am deep
> in it, I can remember a fair number of NTSTATUS codes by their hex
> values, but it is awfully nice to not have to. Also, since I use enum’s
> a lot, I love the ability to display the value name not the number.
>
> I don’t expect everyone to agree with me on this, but I find WPP tracing
> has so many nice features, that it more than offsets the few wonky things
> present.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
>
> “Michal Vodicka” wrote in message
> news:xxxxx@ntdev…
>> ----------
>> From:
>> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
>> on behalf of Don Burn[SMTP:xxxxx@acm.org]
>> Reply To: Windows System Software Devs Interest List
>> Sent: Friday, February 16, 2007 2:17 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] New line in WPP trace
>>
>> Having been a compiler and runtime guy for many years, I know how much
>> people in the compiler world cursed printf since it produces crappy
>> performance. There were arguments over the years of trying to tweak it
>> or
>> replace it because interpreting format strings totally at runtime is a
>> poor
>> idea.
>>
> Don,
>
> have you noticed the numbers I measured? DbgPrint performance is
> comparable to WPP when DebugView is used. So maybe this poor idea is
> comparable with another poor idea :wink:
>
> I just want to say we talk about times in microseconds at modern CPUs in
> both cases and that poor DbgPrint performance against WPP is a myth.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
>
>
>

8

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Don Burn[SMTP:xxxxx@acm.org]
Reply To: Windows System Software Devs Interest List
Sent: Friday, February 16, 2007 8:57 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] New line in WPP trace

I saw the numbers, calling it a myth is way too strong, saying your mileage
may vary is ok. I have seen terrible performance hits using DbgView (to
the point that timing bugs go away), so I guess I can’t accept the myth
claim, any more than you can accept the degradation claim.

Older versions of DebugView had problem with small kernel buffer which could cause poor performance. And disabling pass through option causes 5 - 10 times difference. Unfortunately, it is turned on by default although without a kernel debugger running there is no reason for it.

Personally, the performance was not the reason I endorse WPP tracing so
much. The reasons I like to use it are:

  1. The logs are not readable without the proper data to decode things.
    Personally, I am just as happy to not show the log to every customer. I
    have one firm I work with that any message a customer may see must go
    through legal, try sitting down with a lawyer about logging.

Good reason in such a case. I don’t care so much about it and sometimes it even helps. Yesterday I received a log from a customer which is another software company using our driver and libraries. They found the root of their problem in my traces and saved my precious time which I could spend to write even more mails to this thread :wink:

  1. The flexibility of the extended formatting. Yes, when I am deep
    in it, I can remember a fair number of NTSTATUS codes by their hex values,
    but it is awfully nice to not have to. Also, since I use enum’s a lot, I
    love the ability to display the value name not the number.

Nice but you lose the ability to print the same string via DbgPrint().

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

9

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Don Burn[SMTP:xxxxx@acm.org]
Reply To: Windows System Software Devs Interest List
Sent: Friday, February 16, 2007 9:04 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] New line in WPP trace

Sorry forgot one other biggie:

  1. DbgView is not “standard software” there are a ton of customers
    that require a test period and corporate signoff at the VP level to install
    ANY NEW SOFTWARE on a computer. The stuff to get a WPP tracing log is
    standard on Windows, DbgView is not,

Our customers understand if there is a need to debug problem a their computer (rarely!) it is necessary to install a debug tool. I always send them a link which now points to Microsoft web which they usually trust (for unknown reasons :slight_smile:

I’m a bit confused. Other people here said they send customers a custom tool which configures WPP and captures logs. What do you send them – a batch which calls standard tools with correct parameters?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

10

Yes, I send them a batch script. As I say I have customers who cannot or
will not change the software (as an example try a medical instrument and
tell someone to install “an unknown piece of software”, gee EU requires 6
months or more of testing!!!

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of Don Burn[SMTP:xxxxx@acm.org]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, February 16, 2007 9:04 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] New line in WPP trace
>
> Sorry forgot one other biggie:
>
> 4. DbgView is not “standard software” there are a ton of customers
> that require a test period and corporate signoff at the VP level to
> install
> ANY NEW SOFTWARE on a computer. The stuff to get a WPP tracing log is
> standard on Windows, DbgView is not,
>
Our customers understand if there is a need to debug problem a their
computer (rarely!) it is necessary to install a debug tool. I always send
them a link which now points to Microsoft web which they usually trust (for
unknown reasons :slight_smile:

I’m a bit confused. Other people here said they send customers a custom
tool which configures WPP and captures logs. What do you send them – a
batch which calls standard tools with correct parameters?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

11

Well, time to finish. What you presented are good reasons although some may not be important for anybody. The whole idea behind WPP and ETW is good and I like it. The problem, as usual for MS, is implementation. It looks like horrible monster which discourages me and not only me. It violates KISS principle and that’s the reason for this discussion. I tried to find if there is some real advantage which’d convince me to start with it and have to say there is none. I can see advantages but none justifies the necessary effort to port macros I use for WPP. To compare, I started to evaluate coverage tool you recommended last week (thanks again). It took only few minutes to see first results and it was convincing enough so I spent next few hours configuring our builder scripts for it. It is simple, strict, shows exactly what is expected and nothing else. Very good.

So how should WPP look like? No special preprocessor. Just one or few DDIs which’d developer call from own macros or directly. Separating strings is tricky but possible and MS could add few more pragmas or keywords to compiler which’d help with this task. They need to use __annotation(), anyway, so why not generate necessary GUIDs on place similarly? Capturing is other problem. There should be a tool which’d display all available providers by name, allow to select them and set necessary flags and levels (by name!). It should find everything necessary automatically and download missing info from symbol server as WinDbg does. With no need to use GUIDs, to find PDBs or files with messages. If I’m able to, for example, install checked version of OS USB drivers and use ETW to display their traces mentioned way, that would be convincing.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Don Burn[SMTP:xxxxx@acm.org]
Reply To: Windows System Software Devs Interest List
Sent: Friday, February 16, 2007 9:04 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] New line in WPP trace

Sorry forgot one other biggie:

  1. DbgView is not “standard software” there are a ton of customers
    that require a test period and corporate signoff at the VP level to install
    ANY NEW SOFTWARE on a computer. The stuff to get a WPP tracing log is
    standard on Windows, DbgView is not,

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

12

Here are some perf numbers Alex recently made.

On my 2.4 GHz AMD64 Opteron computer with DebugView I got the following
numbers for WmiTraceMessage vs DbgPrint.

WmiTraceMessage 1075 DbgPrint 8866

If DbgPrints are flowing to the kernel debugger the difference is going
to be dramatic, but even without it I think it is a significant
difference.

The code I used for my measurements is bellow:

#define ITERATION_COUNT 10

VOID
PerfTest(
VOID
)
{
ULONG Count;
ULONG64 Delta1;
ULONG64 Delta2;
KIRQL OldIrql;
ULONG64 StartTime;

KeRaiseIrql(DISPATCH_LEVEL, &OldIrql);

//
// Measure DbgPrint overhead.
//

StartTime = ReadTimeStampCounter();

for (Count = 0; Count < ITERATION_COUNT; Count++) {

DbgPrintEx(DPFLTR_DEFAULT_ID,
DPFLTR_ERROR_LEVEL,
“%s:%d SimpleString %x %x %s\n”,
FUNCTION, LINE, 10, 15, “test”);

}

Delta1 = ReadTimeStampCounter() - StartTime;

//
// Measure TraceMessage overhead.
//

StartTime = ReadTimeStampCounter();

for (Count = 0; Count < ITERATION_COUNT; Count++) {
DoTraceMessage(KTMERROR, “SimpleString %x %x %s\n”,
10, 15, “test”);
}

Delta2 = ReadTimeStampCounter() - StartTime;

KeLowerIrql(OldIrql);

//
// Logging the perf values using WPP :slight_smile:
//

DoTraceMessage(KTMERROR, “TraceMessage %I64d DbgPrint %I64d”,
(Delta2 / ITERATION_COUNT),
(Delta1 / ITERATION_COUNT));

}

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, February 16, 2007 11:42 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] New line in WPP trace

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Don Burn[SMTP:xxxxx@acm.org]
Reply To: Windows System Software Devs Interest List
Sent: Friday, February 16, 2007 2:17 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] New line in WPP trace

Having been a compiler and runtime guy for many years, I know how much

people in the compiler world cursed printf since it produces crappy
performance. There were arguments over the years of trying to tweak
it or
replace it because interpreting format strings totally at runtime is a
poor
idea.

Don,

have you noticed the numbers I measured? DbgPrint performance is
comparable to WPP when DebugView is used. So maybe this poor idea is
comparable with another poor idea :wink:

I just want to say we talk about times in microseconds at modern CPUs in
both cases and that poor DbgPrint performance against WPP is a myth.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

13

I measure DbgPrintEx() part of below code at 1.8 GHz Opteron running 32-bit XP SP2. With DebugView 4.64 numbers are less than half of below i.e. about 4200 cycles. With passthough mode off, of course.

If I take about 1000 for WPP (number reported here was 2000), the difference is not signifficant. I’d agree when passing to kernel debugger the difference is enormous but it is OS flaw, isn’t it?

In addition, the test is unfair. DbgPrintEx() takes 5 argument and DoTraceMessage() only 3. I understand the author wanted to achieve the same output but both FUNCTION and LINE can be resolved in compile time and clever programmer would make it. The result is about 3700 cycles then.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Jose Sua[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, February 16, 2007 10:51 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] New line in WPP trace

Here are some perf numbers Alex recently made.

On my 2.4 GHz AMD64 Opteron computer with DebugView I got the following
numbers for WmiTraceMessage vs DbgPrint.

WmiTraceMessage 1075 DbgPrint 8866

If DbgPrints are flowing to the kernel debugger the difference is going
to be dramatic, but even without it I think it is a significant
difference.

The code I used for my measurements is bellow:

#define ITERATION_COUNT 10

VOID
PerfTest(
VOID
)
{
ULONG Count;
ULONG64 Delta1;
ULONG64 Delta2;
KIRQL OldIrql;
ULONG64 StartTime;

KeRaiseIrql(DISPATCH_LEVEL, &OldIrql);

//
// Measure DbgPrint overhead.
//

StartTime = ReadTimeStampCounter();

for (Count = 0; Count < ITERATION_COUNT; Count++) {

DbgPrintEx(DPFLTR_DEFAULT_ID,
DPFLTR_ERROR_LEVEL,
“%s:%d SimpleString %x %x %s\n”,
FUNCTION, LINE, 10, 15, “test”);

}

Delta1 = ReadTimeStampCounter() - StartTime;

//
// Measure TraceMessage overhead.
//

StartTime = ReadTimeStampCounter();

for (Count = 0; Count < ITERATION_COUNT; Count++) {
DoTraceMessage(KTMERROR, “SimpleString %x %x %s\n”,
10, 15, “test”);
}

Delta2 = ReadTimeStampCounter() - StartTime;

KeLowerIrql(OldIrql);

//
// Logging the perf values using WPP :slight_smile:
//

DoTraceMessage(KTMERROR, “TraceMessage %I64d DbgPrint %I64d”,
(Delta2 / ITERATION_COUNT),
(Delta1 / ITERATION_COUNT));

}

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, February 16, 2007 11:42 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] New line in WPP trace

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Don Burn[SMTP:xxxxx@acm.org]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, February 16, 2007 2:17 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] New line in WPP trace
>
> Having been a compiler and runtime guy for many years, I know how much

> people in the compiler world cursed printf since it produces crappy
> performance. There were arguments over the years of trying to tweak
it or
> replace it because interpreting format strings totally at runtime is a
poor
> idea.
>
Don,

have you noticed the numbers I measured? DbgPrint performance is
comparable to WPP when DebugView is used. So maybe this poor idea is>
comparable with another poor idea :wink:

I just want to say we talk about times in microseconds at modern CPUs in
both cases and that poor DbgPrint performance against WPP is a myth.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

14

For completeness, I tried it at the same hardware running XP64. 3700 cycles reduced to 3300.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Michal Vodicka[SMTP:xxxxx@upek.com]
Reply To: Windows System Software Devs Interest List
Sent: Saturday, February 17, 2007 12:46 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] New line in WPP trace

I measure DbgPrintEx() part of below code at 1.8 GHz Opteron running 32-bit XP SP2. With DebugView 4.64 numbers are less than half of below i.e. about 4200 cycles. With passthough mode off, of course.

If I take about 1000 for WPP (number reported here was 2000), the difference is not signifficant. I’d agree when passing to kernel debugger the difference is enormous but it is OS flaw, isn’t it?

In addition, the test is unfair. DbgPrintEx() takes 5 argument and DoTraceMessage() only 3. I understand the author wanted to achieve the same output but both FUNCTION and LINE can be resolved in compile time and clever programmer would make it. The result is about 3700 cycles then.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> ----------
> From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Jose Sua[SMTP:xxxxx@windows.microsoft.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, February 16, 2007 10:51 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] New line in WPP trace
>
> Here are some perf numbers Alex recently made.
>
>
> On my 2.4 GHz AMD64 Opteron computer with DebugView I got the following
> numbers for WmiTraceMessage vs DbgPrint.
>
> WmiTraceMessage 1075 DbgPrint 8866
>
> If DbgPrints are flowing to the kernel debugger the difference is going
> to be dramatic, but even without it I think it is a significant
> difference.
>
> The code I used for my measurements is bellow:
>
> #define ITERATION_COUNT 10
>
> VOID
> PerfTest(
> VOID
> )
> {
> ULONG Count;
> ULONG64 Delta1;
> ULONG64 Delta2;
> KIRQL OldIrql;
> ULONG64 StartTime;
>
> KeRaiseIrql(DISPATCH_LEVEL, &OldIrql);
>
> //
> // Measure DbgPrint overhead.
> //
>
> StartTime = ReadTimeStampCounter();
>
> for (Count = 0; Count < ITERATION_COUNT; Count++) {
>
> DbgPrintEx(DPFLTR_DEFAULT_ID,
> DPFLTR_ERROR_LEVEL,
> “%s:%d SimpleString %x %x %s\n”,
> FUNCTION, LINE, 10, 15, “test”);
>
> }
>
> Delta1 = ReadTimeStampCounter() - StartTime;
>
> //
> // Measure TraceMessage overhead.
> //
>
> StartTime = ReadTimeStampCounter();
>
> for (Count = 0; Count < ITERATION_COUNT; Count++) {
> DoTraceMessage(KTMERROR, “SimpleString %x %x %s\n”,
> 10, 15, “test”);
> }
>
> Delta2 = ReadTimeStampCounter() - StartTime;
>
> KeLowerIrql(OldIrql);
>
> //
> // Logging the perf values using WPP :slight_smile:
> //
>
> DoTraceMessage(KTMERROR, “TraceMessage %I64d DbgPrint %I64d”,
> (Delta2 / ITERATION_COUNT),
> (Delta1 / ITERATION_COUNT));
>
> }
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> Sent: Friday, February 16, 2007 11:42 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] New line in WPP trace
>
> > ----------
> > From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com>
> ] on behalf of Don Burn[SMTP:xxxxx@acm.org]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Friday, February 16, 2007 2:17 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] New line in WPP trace
> >
> > Having been a compiler and runtime guy for many years, I know how much
>
> > people in the compiler world cursed printf since it produces crappy
> > performance. There were arguments over the years of trying to tweak
> it or
> > replace it because interpreting format strings totally at runtime is a
> poor
> > idea.
> >
> Don,
>
> have you noticed the numbers I measured? DbgPrint performance is
> comparable to WPP when DebugView is used. So maybe this poor idea is>
> comparable with another poor idea :wink:
>
> I just want to say we talk about times in microseconds at modern CPUs in
> both cases and that poor DbgPrint performance against WPP is a myth.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

15

absurd response. i still haven’t seen any justification for deleting ‘\n’.
and printf is damned efficient if written well. and if you even consider
your life in harm from traditional printf strings then i don’t know what
planet you are from. oh yeah, and i’ve used an efficient implementation
for 25 years. next question?

brucee

On 2/17/07, Don Burn wrote:
> Comments inline:
> “Bruce Ellis” wrote in message news:xxxxx@ntdev…
> >i thought it was absurd that ‘\n’ was stripped, by the pre-processor i
> >guess.
> > if the claims that “just throw it in octal” are true then i will laugh
> > more, as this
> > means that the pre-processor parses the formatting strings and is
> > required to nuke
> > them, probably took a few weeks and 100 man hours of meetings to
> > make this decision. good to see it was fruitless, whatever the intention
> > was.
>
> You obviously do not understand WPP tracing, since the formatting strings
> are not in the executable, so you are not wasting the time of parsing this
> like printf. This is one of the strongest features of WPP tracing, it just
> copies the binary values (so yes needs to know their size and parse as part
> of the pre-process).
>
> Having been a compiler and runtime guy for many years, I know how much
> people in the compiler world cursed printf since it produces crappy
> performance. There were arguments over the years of trying to tweak it or
> replace it because interpreting format strings totally at runtime is a poor
> idea.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

16

no, it’s a *badly designed and foolishly implemented* issue.
if your printf is slow then fix it. don’t throw another layer of garbage
on top. i still have seen no justification for a preprocesser that
stomps on newlines (and misses octal escapes).

i guess we have to keep the drones busy.

brucee

On 2/18/07, Pavel A. wrote:
> Isn’t this purely a missing tool issue?
> Will you like ETW/WPP more if there were a pretty real-time viewer for ETW, like DbgView?
>
> --PA
>
> “Tim Roberts” wrote in message news:xxxxx@ntdev…
> > Yossi Leybovich wrote:
> >> I can collect my traces by traceview or by dbgview with few simple
> >> scripts and I don’t think it is nuisance.
> >>
> >
> > Look, this argument over DbgPrint vs WPP is silly. It comes down to
> > personal preference. Don believes in WPP and finds it very useful.
> > That’s his right. Maxim believes in DbgPrint and finds WPP
> > unnecessarily complicated. That’s his right.
> >
> > On my first KMDF project, I tried to embrace WPP, but I found myself
> > being more annoyed then delighted, and replaced them all with KdPrint.
> > I now regret that, and on the next project I’ll try harder for WPP.
> > That’s also MY right.
> >
> > You’ll never convince someone to change, any more than you can convince
> > someone to change text editors. If you don’t realize that gvim is the
> > greatest editor in the world, then there’s clearly something wrong with
> > you. :wink:
> >
> > –
> > Tim Roberts, xxxxx@probo.com
> > Providenza & Boekelheide, Inc.
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

17

Better yet, msft should implement a simple kernel virtual console ringbuffer
into which all kernel printfs get recorded, and provide a viewer and/or a
simple api for viewing the contents of the ringbuffer in user mode. The
debugger, if attached, would continue to show the console output in real
time. The buffer, being resident in kernel memory, could then be fetched
from a crash dump for a few more clues about what happened leading up to the
crash.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-278522-
xxxxx@lists.osr.com] On Behalf Of Bruce Ellis
Sent: Sunday, February 18, 2007 9:28 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] New line in WPP trace

no, it’s a *badly designed and foolishly implemented* issue.
if your printf is slow then fix it. don’t throw another layer of
garbage
on top. i still have seen no justification for a preprocesser that
stomps on newlines (and misses octal escapes).

i guess we have to keep the drones busy.

brucee

On 2/18/07, Pavel A. wrote:
> > Isn’t this purely a missing tool issue?
> > Will you like ETW/WPP more if there were a pretty real-time viewer
> for ETW, like DbgView?
> >
> > --PA
> >
> > “Tim Roberts” wrote in message news:xxxxx@ntdev…
> > > Yossi Leybovich wrote:
> > >> I can collect my traces by traceview or by dbgview with few simple
> > >> scripts and I don’t think it is nuisance.
> > >>
> > >
> > > Look, this argument over DbgPrint vs WPP is silly. It comes down
> to
> > > personal preference. Don believes in WPP and finds it very useful.
> > > That’s his right. Maxim believes in DbgPrint and finds WPP
> > > unnecessarily complicated. That’s his right.
> > >
> > > On my first KMDF project, I tried to embrace WPP, but I found
> myself
> > > being more annoyed then delighted, and replaced them all with
> KdPrint.
> > > I now regret that, and on the next project I’ll try harder for WPP.
> > > That’s also MY right.
> > >
> > > You’ll never convince someone to change, any more than you can
> convince
> > > someone to change text editors. If you don’t realize that gvim is
> the
> > > greatest editor in the world, then there’s clearly something wrong
> with
> > > you. :wink:
> > >
> > > –
> > > Tim Roberts, xxxxx@probo.com
> > > Providenza & Boekelheide, Inc.
> > >
> > >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> >
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer