Unnecessary obfuscation, "Hey I can't see my spew because of your spew!!!"

NTDEV
1

This could be considered best for the WinDbg group, but I think it applies
to all.

Chief amongst the reasons for NOT releasing your driver with debug
printouts, let’s call it spew for the sake of brevity, is really one of
courtesy. Just the time wasted in calling the print statement has been
known to seriously affect systems. Sure, not having a debugger connected
greatly improves processing time, but the host system may well be in a
development environment and I HAVE to have a debugger connected because
I’m working on my own code. In this case I want to see MY spew not YOUR
spew. Case in point: I’m working on a service that uses spew to tell me
where it is in OnStart, OnStop, it’s constructor and a few other
interesting areas. I can’t see MY spew because Broadcom’s TPM driver is
puking all over the place and covering it up. How rude.

If you really need debug printouts enabled in your released driver, tell
me, work with me. I’ll more than likely be most willing to tell you what I
find or forward you some dumps from the command buffer. Actually, the best
thing is to send me a checked build driver with spew enabled when I ask
for it.

Gary G. Little

2

> Chief amongst the reasons for NOT releasing your driver with debug

printouts, let’s call it spew for the sake of brevity, is
really one of
courtesy. Just the time wasted in calling the print statement has been
known to seriously affect systems. Sure, not having a
debugger connected
greatly improves processing time, but the host system may well be in a
development environment and I HAVE to have a debugger
connected because
I’m working on my own code. In this case I want to see MY
spew not YOUR
spew. Case in point: I’m working on a service that uses spew
to tell me
where it is in OnStart, OnStop, it’s constructor and a few other
interesting areas. I can’t see MY spew because Broadcom’s TPM
driver is
puking all over the place and covering it up. How rude.

Yeah, I agree; it’s tiresome. You could just save the output and grep all the crap away
assuming they have some kind of identifying tag.

However there might actually be a reason for it.
Consider …

Developer> We need a few more weeks because there’s a nasty race in our code
> and every time we try to pin it down with debugging prints, the
> problem goes away.

Pointy Haired Boss> Oh, you’re telling me that you have a problem but, whenever
> you try to debug it, it goes away? And you need more time.

Dev> Yeah, exactly.

PHB> So ship it with the debugs in place: I need that code now!

Couldn’t happen in real life, now could it?

Alternatively, why don’t we petition those clever folks at OSR to make a utility
that disables debugging output from a specified driver. I’m sure it could be done
using the H**k word :slight_smile:

Don

3

Its a good point; I know we enjoyed spew from skype from time to time would
you believe :slight_smile:

wrote in message news:xxxxx@ntdev…
> This could be considered best for the WinDbg group, but I think it applies
> to all.
>
> Chief amongst the reasons for NOT releasing your driver with debug
> printouts, let’s call it spew for the sake of brevity, is really one of
> courtesy. Just the time wasted in calling the print statement has been
> known to seriously affect systems. Sure, not having a debugger connected
> greatly improves processing time, but the host system may well be in a
> development environment and I HAVE to have a debugger connected because
> I’m working on my own code. In this case I want to see MY spew not YOUR
> spew. Case in point: I’m working on a service that uses spew to tell me
> where it is in OnStart, OnStop, it’s constructor and a few other
> interesting areas. I can’t see MY spew because Broadcom’s TPM driver is
> puking all over the place and covering it up. How rude.
>
> If you really need debug printouts enabled in your released driver, tell
> me, work with me. I’ll more than likely be most willing to tell you what I
> find or forward you some dumps from the command buffer. Actually, the best
> thing is to send me a checked build driver with spew enabled when I ask
> for it.
>
> Gary G. Little
>

4

They don’t, and of course *I* don’t, since I expected mine to be the only
spew. :slight_smile: There are echoes of “famous last words” there.

To me, copious spew is simply inexcusable, especially for a TPM, Trusted
Program Module. That of all devices in a system I would expect total
silence whether or not I have a debugger attached.

Put a brag message at start up and one at shutdown, fine, but putting out
miles and miles of miles and miles of spew simply because it’s expedient
to get it out the door tells me it’s a product I neither want on my
system nor one I can recommend. Spew affects timing, and if the driver
works with spew and not without spew then the driver needs to be fixed …
period. Releasing it into beta with spew is acceptable, but never as an
end product.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Ward
Sent: Wednesday, May 10, 2006 3:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Unnecessary obfuscation, “Hey I can’t see my spew
because of your spew!!!”

Chief amongst the reasons for NOT releasing your driver with debug
printouts, let’s call it spew for the sake of brevity, is
really one of
courtesy. Just the time wasted in calling the print statement has been
known to seriously affect systems. Sure, not having a
debugger connected
greatly improves processing time, but the host system may well be in a
development environment and I HAVE to have a debugger
connected because
I’m working on my own code. In this case I want to see MY
spew not YOUR
spew. Case in point: I’m working on a service that uses spew
to tell me
where it is in OnStart, OnStop, it’s constructor and a few other
interesting areas. I can’t see MY spew because Broadcom’s TPM
driver is
puking all over the place and covering it up. How rude.

Yeah, I agree; it’s tiresome. You could just save the output and grep all
the crap away
assuming they have some kind of identifying tag.

However there might actually be a reason for it.
Consider …

Developer> We need a few more weeks because there’s a nasty race in our
code
> and every time we try to pin it down with debugging prints, the
> problem goes away.

Pointy Haired Boss> Oh, you’re telling me that you have a problem but,
whenever
> you try to debug it, it goes away? And you need more
time.

Dev> Yeah, exactly.

PHB> So ship it with the debugs in place: I need that code now!

Couldn’t happen in real life, now could it?

Alternatively, why don’t we petition those clever folks at OSR to make a
utility
that disables debugging output from a specified driver. I’m sure it could
be done
using the H**k word :slight_smile:

Don

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

5

The two drivers I have seen with released spew, SMBios and Broadcom’s TPM,
also fault (BSOD) when run with Driver Verifier. So maybe Don’s post has
bearing, in that the spew is really covering up problems that have not
been fixed.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J. Clarke
Sent: Wednesday, May 10, 2006 4:10 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Unnecessary obfuscation, “Hey I can’t see my spew
because of your spew!!!”

Its a good point; I know we enjoyed spew from skype from time to time
would
you believe :slight_smile:

wrote in message news:xxxxx@ntdev…
> This could be considered best for the WinDbg group, but I think it
applies
> to all.
>
> Chief amongst the reasons for NOT releasing your driver with debug
> printouts, let’s call it spew for the sake of brevity, is really one of
> courtesy. Just the time wasted in calling the print statement has been
> known to seriously affect systems. Sure, not having a debugger connected
> greatly improves processing time, but the host system may well be in a
> development environment and I HAVE to have a debugger connected because
> I’m working on my own code. In this case I want to see MY spew not YOUR
> spew. Case in point: I’m working on a service that uses spew to tell me
> where it is in OnStart, OnStop, it’s constructor and a few other
> interesting areas. I can’t see MY spew because Broadcom’s TPM driver is
> puking all over the place and covering it up. How rude.
>
> If you really need debug printouts enabled in your released driver, tell
> me, work with me. I’ll more than likely be most willing to tell you what
I
> find or forward you some dumps from the command buffer. Actually, the
best
> thing is to send me a checked build driver with spew enabled when I ask
> for it.
>
> Gary G. Little
>

—
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

6

Since we will never get the best of all worlds, I have an idea that might
help. Turn on logging in windbg. Then you could have a Python script to
eliminate all spew except for your own. It would be best if your spew began
with some ID for Python to key on. This ID could be on each line or as a
block delimiter such as:

MYDRVR:
xxx
yyy
MYDRVR:End

wrote in message news:xxxxx@ntdev…
> They don’t, and of course I don’t, since I expected mine to be the only
> spew. :slight_smile: There are echoes of “famous last words” there.
>
> To me, copious spew is simply inexcusable, especially for a TPM, Trusted
> Program Module. That of all devices in a system I would expect total
> silence whether or not I have a debugger attached.
>
> Put a brag message at start up and one at shutdown, fine, but putting out
> miles and miles of miles and miles of spew simply because it’s expedient
> to get it out the door tells me it’s a product I neither want on my
> system nor one I can recommend. Spew affects timing, and if the driver
> works with spew and not without spew then the driver needs to be fixed …
> period. Releasing it into beta with spew is acceptable, but never as an
> end product.
>
> Gary G. Little
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Ward
> Sent: Wednesday, May 10, 2006 3:53 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Unnecessary obfuscation, “Hey I can’t see my spew
> because of your spew!!!”
>
>
>> Chief amongst the reasons for NOT releasing your driver with debug
>> printouts, let’s call it spew for the sake of brevity, is
>> really one of
>> courtesy. Just the time wasted in calling the print statement has been
>> known to seriously affect systems. Sure, not having a
>> debugger connected
>> greatly improves processing time, but the host system may well be in a
>> development environment and I HAVE to have a debugger
>> connected because
>> I’m working on my own code. In this case I want to see MY
>> spew not YOUR
>> spew. Case in point: I’m working on a service that uses spew
>> to tell me
>> where it is in OnStart, OnStop, it’s constructor and a few other
>> interesting areas. I can’t see MY spew because Broadcom’s TPM
>> driver is
>> puking all over the place and covering it up. How rude.
>
> Yeah, I agree; it’s tiresome. You could just save the output and grep all
> the crap away
> assuming they have some kind of identifying tag.
>
> However there might actually be a reason for it.
> Consider …
>
> Developer> We need a few more weeks because there’s a nasty race in our
> code
> > and every time we try to pin it down with debugging prints, the
> > problem goes away.
>
> Pointy Haired Boss> Oh, you’re telling me that you have a problem but,
> whenever
> > you try to debug it, it goes away? And you need more
> time.
>
> Dev> Yeah, exactly.
>
> PHB> So ship it with the debugs in place: I need that code now!
>
> Couldn’t happen in real life, now could it?
>
> Alternatively, why don’t we petition those clever folks at OSR to make a
> utility
> that disables debugging output from a specified driver. I’m sure it could
> be done
> using the H**k word :slight_smile:
>
> Don
>
>
> —
> 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
>

7

> we enjoyed spew from skype from time to time
Stock Windows Media Center, as retail as only can be, not only
DbgPrint’s but has breakpoints (I guess properly enclosed in if’s,

  • there are no BSODs without a debugger, after all).

I had to disable some service to get through, but

WLSSRDetails Function Fail, Error: 31
SetRF = 0
SetRF = 0
SetRF = 0
SetRF = 0
SetRF = 0
WLSSRDetails Function Fail, Error: 31
SetRF = 0

etc.

is always there, unless you kill networking, like a wallpaper.

8

The DbgView program from sysinternals has a filter in it so you can
capture DbgPrints and filter what you want to see.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Wednesday, May 10, 2006 5:31 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Unnecessary obfuscation, “Hey I can’t see my spew
because of your spew!!!”

Since we will never get the best of all worlds, I have an idea that
might help. Turn on logging in windbg. Then you could have a Python
script to eliminate all spew except for your own. It would be best if
your spew began with some ID for Python to key on. This ID could be on
each line or as a block delimiter such as:

MYDRVR:
xxx
yyy
MYDRVR:End

wrote in message news:xxxxx@ntdev…
> They don’t, and of course I don’t, since I expected mine to be the
> only spew. :slight_smile: There are echoes of “famous last words” there.
>
> To me, copious spew is simply inexcusable, especially for a TPM,
> Trusted Program Module. That of all devices in a system I would expect

> total silence whether or not I have a debugger attached.
>
> Put a brag message at start up and one at shutdown, fine, but putting
> out miles and miles of miles and miles of spew simply because it’s
> expedient to get it out the door tells me it’s a product I neither
> want on my system nor one I can recommend. Spew affects timing, and if

> the driver works with spew and not without spew then the driver needs
to be fixed …
> period. Releasing it into beta with spew is acceptable, but never as
> an end product.
>
> Gary G. Little
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Ward
> Sent: Wednesday, May 10, 2006 3:53 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Unnecessary obfuscation, “Hey I can’t see my spew

> because of your spew!!!”
>
>
>> Chief amongst the reasons for NOT releasing your driver with debug
>> printouts, let’s call it spew for the sake of brevity, is really one
>> of courtesy. Just the time wasted in calling the print statement has
>> been known to seriously affect systems. Sure, not having a debugger
>> connected greatly improves processing time, but the host system may
>> well be in a development environment and I HAVE to have a debugger
>> connected because I’m working on my own code. In this case I want to
>> see MY spew not YOUR spew. Case in point: I’m working on a service
>> that uses spew to tell me where it is in OnStart, OnStop, it’s
>> constructor and a few other interesting areas. I can’t see MY spew
>> because Broadcom’s TPM driver is puking all over the place and
>> covering it up. How rude.
>
> Yeah, I agree; it’s tiresome. You could just save the output and grep
> all the crap away assuming they have some kind of identifying tag.
>
> However there might actually be a reason for it.
> Consider …
>
> Developer> We need a few more weeks because there’s a nasty race in
> Developer> our
> code
> > and every time we try to pin it down with debugging prints,
the
> > problem goes away.
>
> Pointy Haired Boss> Oh, you’re telling me that you have a problem but,

> whenever
> > you try to debug it, it goes away? And you need
> more time.
>
> Dev> Yeah, exactly.
>
> PHB> So ship it with the debugs in place: I need that code now!
>
> Couldn’t happen in real life, now could it?
>
> Alternatively, why don’t we petition those clever folks at OSR to make

> a utility that disables debugging output from a specified driver. I’m
> sure it could be done using the H**k word :slight_smile:
>
> Don
>
>
> —
> 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

9

You can also just use .ofilter in WinDBG

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“David J. Craig” wrote in message
news:xxxxx@ntdev…
> Since we will never get the best of all worlds, I have an idea that might
> help. Turn on logging in windbg. Then you could have a Python script to
> eliminate all spew except for your own. It would be best if your spew
> began with some ID for Python to key on. This ID could be on each line or
> as a block delimiter such as:
>
> MYDRVR:
> xxx
> yyy
> MYDRVR:End
>
> wrote in message news:xxxxx@ntdev…
>> They don’t, and of course I don’t, since I expected mine to be the only
>> spew. :slight_smile: There are echoes of “famous last words” there.
>>
>> To me, copious spew is simply inexcusable, especially for a TPM, Trusted
>> Program Module. That of all devices in a system I would expect total
>> silence whether or not I have a debugger attached.
>>
>> Put a brag message at start up and one at shutdown, fine, but putting out
>> miles and miles of miles and miles of spew simply because it’s expedient
>> to get it out the door tells me it’s a product I neither want on my
>> system nor one I can recommend. Spew affects timing, and if the driver
>> works with spew and not without spew then the driver needs to be fixed
>> …
>> period. Releasing it into beta with spew is acceptable, but never as an
>> end product.
>>
>> Gary G. Little
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Ward
>> Sent: Wednesday, May 10, 2006 3:53 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE: [ntdev] Unnecessary obfuscation, “Hey I can’t see my spew
>> because of your spew!!!”
>>
>>
>>> Chief amongst the reasons for NOT releasing your driver with debug
>>> printouts, let’s call it spew for the sake of brevity, is
>>> really one of
>>> courtesy. Just the time wasted in calling the print statement has been
>>> known to seriously affect systems. Sure, not having a
>>> debugger connected
>>> greatly improves processing time, but the host system may well be in a
>>> development environment and I HAVE to have a debugger
>>> connected because
>>> I’m working on my own code. In this case I want to see MY
>>> spew not YOUR
>>> spew. Case in point: I’m working on a service that uses spew
>>> to tell me
>>> where it is in OnStart, OnStop, it’s constructor and a few other
>>> interesting areas. I can’t see MY spew because Broadcom’s TPM
>>> driver is
>>> puking all over the place and covering it up. How rude.
>>
>> Yeah, I agree; it’s tiresome. You could just save the output and grep all
>> the crap away
>> assuming they have some kind of identifying tag.
>>
>> However there might actually be a reason for it.
>> Consider …
>>
>> Developer> We need a few more weeks because there’s a nasty race in our
>> code
>> > and every time we try to pin it down with debugging prints, the
>> > problem goes away.
>>
>> Pointy Haired Boss> Oh, you’re telling me that you have a problem but,
>> whenever
>> > you try to debug it, it goes away? And you need more
>> time.
>>
>> Dev> Yeah, exactly.
>>
>> PHB> So ship it with the debugs in place: I need that code now!
>>
>> Couldn’t happen in real life, now could it?
>>
>> Alternatively, why don’t we petition those clever folks at OSR to make a
>> utility
>> that disables debugging output from a specified driver. I’m sure it could
>> be done
>> using the H**k word :slight_smile:
>>
>> Don
>>
>>
>> —
>> 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
>>
>
>
>

10

Hanlon’s Razor: Don’t attribute to malice what can be adequately explained by incompetence. (stupidity, ignorance)

I completely agree software spewing to debug output is annoying but I’d presume it is by mistake, not intention. Have you tried to inform guilty companies?

(I remember long years before some Matrox driver regularly crashed on checked build. I sent a bug report to them and got a reply: we don’t support NT checked build. We never bought any Matrox graphic card again.)

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 xxxxx@seagate.com[SMTP:xxxxx@seagate.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, May 10, 2006 11:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Unnecessary obfuscation, “Hey I can’t see my spew because of your spew!!!”

The two drivers I have seen with released spew, SMBios and Broadcom’s TPM,
also fault (BSOD) when run with Driver Verifier. So maybe Don’s post has
bearing, in that the spew is really covering up problems that have not
been fixed.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J. Clarke
Sent: Wednesday, May 10, 2006 4:10 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Unnecessary obfuscation, “Hey I can’t see my spew
because of your spew!!!”

Its a good point; I know we enjoyed spew from skype from time to time
would
you believe :slight_smile:

wrote in message news:xxxxx@ntdev…
> > This could be considered best for the WinDbg group, but I think it
> applies
> > to all.
> >
> > Chief amongst the reasons for NOT releasing your driver with debug
> > printouts, let’s call it spew for the sake of brevity, is really one of
> > courtesy. Just the time wasted in calling the print statement has been
> > known to seriously affect systems. Sure, not having a debugger connected
> > greatly improves processing time, but the host system may well be in a
> > development environment and I HAVE to have a debugger connected because
> > I’m working on my own code. In this case I want to see MY spew not YOUR
> > spew. Case in point: I’m working on a service that uses spew to tell me
> > where it is in OnStart, OnStop, it’s constructor and a few other
> > interesting areas. I can’t see MY spew because Broadcom’s TPM driver is
> > puking all over the place and covering it up. How rude.
> >
> > If you really need debug printouts enabled in your released driver, tell
> > me, work with me. I’ll more than likely be most willing to tell you what
> I
> > find or forward you some dumps from the command buffer. Actually, the
> best
> > thing is to send me a checked build driver with spew enabled when I ask
> > for it.
> >
> > Gary G. Little
> >
>
>
>
> —
> 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
>

11

Is this an In-the-Box or an OEM distributed one?

If it’s MSFT inbox, I’d recommend filing a bug to MSFT. If it’s OEM,
file a bug to the distributing OEM.

I don’t know our TPM team’s release practices but generally BRCM
distributes driver through OEMs such as Dell, IBM, HP…, or through
Windows CD inclusion.

When vendors submit driver for Windows inclusion, they are required to
submit checked and free builds. There is a chance that check build
driver mistakenly gets checked into Windows build I’m not kidding…
this almost happened to my Vista GBE driver a while back. Fortunately,
their networking team found that out at the very last moment or I would
be the one to blame.

Calvin Guan
NetXtreme NTX Miniport
Broadcom Corporation
Connecting Everything(r)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-250851-
xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, May 10, 2006 3:58 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Unnecessary obfuscation, “Hey I can’t see my spew
because of your spew!!!”

Hanlon’s Razor: Don’t attribute to malice what can be adequately
explained
by incompetence. (stupidity, ignorance)

I completely agree software spewing to debug output is annoying but
I’d
presume it is by mistake, not intention. Have you tried to inform
guilty
companies?

(I remember long years before some Matrox driver regularly crashed on
checked build. I sent a bug report to them and got a reply: we don’t
support NT checked build. We never bought any Matrox graphic card
again.)

Best regards,

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

> ----------
> From: xxxxx@lists.osr.com[SMTP:bounce-250845-
xxxxx@lists.osr.com] on behalf of
xxxxx@seagate.com[SMTP:xxxxx@seagate.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Wednesday, May 10, 2006 11:26 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Unnecessary obfuscation, “Hey I can’t see my
spew
because of your spew!!!”
>
> The two drivers I have seen with released spew, SMBios and
Broadcom’s
TPM,
> also fault (BSOD) when run with Driver Verifier. So maybe Don’s post
has
> bearing, in that the spew is really covering up problems that have
not
> been fixed.
>
> Gary G. Little
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J.
Clarke
> Sent: Wednesday, May 10, 2006 4:10 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Unnecessary obfuscation, “Hey I can’t see my
spew
> because of your spew!!!”
>
> Its a good point; I know we enjoyed spew from skype from time to
time
> would
> you believe :slight_smile:
>
> wrote in message news:xxxxx@ntdev…
> > > This could be considered best for the WinDbg group, but I think it
> > applies
> > > to all.
> > >
> > > Chief amongst the reasons for NOT releasing your driver with debug
> > > printouts, let’s call it spew for the sake of brevity, is really
one
> of
> > > courtesy. Just the time wasted in calling the print statement has
been
> > > known to seriously affect systems. Sure, not having a debugger
> connected
> > > greatly improves processing time, but the host system may well be
in a
> > > development environment and I HAVE to have a debugger connected
> because
> > > I’m working on my own code. In this case I want to see MY spew not
> YOUR
> > > spew. Case in point: I’m working on a service that uses spew to
tell
> me
> > > where it is in OnStart, OnStop, it’s constructor and a few other
> > > interesting areas. I can’t see MY spew because Broadcom’s TPM
driver
> is
> > > puking all over the place and covering it up. How rude.
> > >
> > > If you really need debug printouts enabled in your released
driver,
> tell
> > > me, work with me. I’ll more than likely be most willing to tell
you
> what
> > I
> > > find or forward you some dumps from the command buffer. Actually,
the
> > best
> > > thing is to send me a checked build driver with spew enabled when
I
> ask
> > > for it.
> > >
> > > Gary G. Little
> > >
> >
> >
> >
> > —
> > 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

12

> The two drivers I have seen with released spew, SMBios and Broadcom’s TPM,

also fault (BSOD) when run with Driver Verifier. So maybe Don’s post has
bearing, in that the spew is really covering up problems that have not
been fixed.

Is it possible for Microsoft to give a way of probibiting any debug prints to
the KD from the specified modules, both user and kernel mode?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

13

> PHB> So ship it with the debugs in place: I need that code now!

Sounds almost exactly like the reason I just spent a bunch of effort to make
my driver easily configurable (recompile) between WPP tracing and
DbgPrint’s.

The automatic builds done for the testing group (and eventually release)
will get WPP. Then the spew can go to a file, and I can see it when testing
folks find issues. When interactively developing, WPP I find is pretty
painful, so would just prefer to see spew on windbg. I still haven’t figured
out an easy way to switch between dbgprint+wpp and just wpp tracing. Since
wpp source munging happens before the C preprocessor, I can’t just #define
one DebugPrint into DebugPrintLocal+DebugPrintWPP.

Using WPP for my development is especially painful, because traceview (even
the one in the WDK) cause MANY messages under the full checked OS (which I
run all the time).

Does anybody know how to configure side-by-side user mode DLL’s like
comctl32.dll, so I can cause traceview to use the non-checked version, but
still run a full checked kernel? WXP/W2K3 are supposed to allow doing this,
if you know the right magic.

Peter also suggested I file a bug against traceview in the wdk, but I could
not anyplace on the MS website to do so, or any email address in the WDF for
reports bugs in the WDK tools (there was an address to report doc bugs). A
search of the WDK help file for “report bug” found nothing, nothing in the
release notes either.

  • Jan
14

Winamp’s good for this, every know and again it debugprints the last
thousand or so songs it played

Its a good point; I know we enjoyed spew from skype from time to time would
you believe :slight_smile:

15

I’ve haven’t found a compelling reason to use wpp for development. Like
you I just build my drivers so that the checked version uses debugprint
and the production version uses wpp. This limits wpp usage (no
non-printf compatible format specifiers) but that tradeoff has never
been a problem. I see no reason to change this.

Both wpp and debugprint suffer from not having a retrievable kernel
ringbuffer that captures run time trace information for post mortem
analysis. I hear rumors that this is fixed for wpp in vista, but I have
not verified it.

Runtime configurable debug prints are fine in production drivers, as
long as the driver ships in terse mode.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Thursday, May 11, 2006 4:16 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Unnecessary obfuscation, “Hey I can’t see my spew
because of your spew!!!”

PHB> So ship it with the debugs in place: I need that code now!

Sounds almost exactly like the reason I just spent a bunch of effort to
make
my driver easily configurable (recompile) between WPP tracing and
DbgPrint’s.

The automatic builds done for the testing group (and eventually release)
will get WPP. Then the spew can go to a file, and I can see it when
testing
folks find issues. When interactively developing, WPP I find is pretty
painful, so would just prefer to see spew on windbg. I still haven’t
figured
out an easy way to switch between dbgprint+wpp and just wpp tracing.
Since
wpp source munging happens before the C preprocessor, I can’t just
#define
one DebugPrint into DebugPrintLocal+DebugPrintWPP.

Using WPP for my development is especially painful, because traceview
(even
the one in the WDK) cause MANY messages under the full checked OS (which
I
run all the time).

Does anybody know how to configure side-by-side user mode DLL’s like
comctl32.dll, so I can cause traceview to use the non-checked version,
but
still run a full checked kernel? WXP/W2K3 are supposed to allow doing
this,
if you know the right magic.

Peter also suggested I file a bug against traceview in the wdk, but I
could
not anyplace on the MS website to do so, or any email address in the WDF
for
reports bugs in the WDK tools (there was an address to report doc bugs).
A
search of the WDK help file for “report bug” found nothing, nothing in
the
release notes either.

  • Jan

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

As I believe I’ve mentioned before, the way I understand it, working support for ring-buffers for WPP output is available at least from XP forward. You use the WPP-specific debugger extension.

I’m not sure you’re saying that this doesn’t work, or if you’re just not aware of the debugger extension that supports this. In any case, it’s been (quite literally) a couple of years since I tried it… but I THOUGHT I’d tried this and it worked.

Also, IIRC, there IS some support for retrieving stored DbgPrints from crash dumps as well.

Peter
OSR

17

Hearing several people in this discussion talking about configuring between
WPP and DebugPrint, if you are not aware of it there is the macro

#define WPP_DEBUG(m)

If you define this before your TMH files to something that forces a debug
print of m you get all you WPP trace outputs to the debugger. For instance
in a current project of mine, I use something line the following:

#define WPP_DEBUG(m) ((WppMessages !=0) ? DbgPrint m : 0)

Which provides debug output if the global WppMessages is non-zero.

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

P.S. My favorite spew was a file system redirector that showed all
operations including the user login with password in the debugger!

“Jan Bottorff” wrote in message news:xxxxx@ntdev…
>> PHB> So ship it with the debugs in place: I need that code now!
>
> Sounds almost exactly like the reason I just spent a bunch of effort to
> make
> my driver easily configurable (recompile) between WPP tracing and
> DbgPrint’s.
>
> The automatic builds done for the testing group (and eventually release)
> will get WPP. Then the spew can go to a file, and I can see it when
> testing
> folks find issues. When interactively developing, WPP I find is pretty
> painful, so would just prefer to see spew on windbg. I still haven’t
> figured
> out an easy way to switch between dbgprint+wpp and just wpp tracing. Since
> wpp source munging happens before the C preprocessor, I can’t just #define
> one DebugPrint into DebugPrintLocal+DebugPrintWPP.

18

As far as I can tell it does not work in XP SP2 or W2K3 SP1, wpp
specific extensions as supplied with the latest released windbg.
However, as with all things wpp there probably is some ritual behavior
involving blood sacrifice of large mammals that can coax the WPP/ETW
deity into beneficial behavior. I’ve tried sacrificing a goat. Any
suggestions?

The “support for retrieving stored DbgPrints from crash dumps” is
useless. To be useful a runtime trace ringbuffer needs to capture on the
order of thousands of discrete entries.

I didn’t mention boot trace support. Yet another wpp mystery.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, May 11, 2006 9:42 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Unnecessary obfuscation, “Hey I can’t see my spew
because of your spew!!!”

As I believe I’ve mentioned before, the way I understand it, working
support for ring-buffers for WPP output is available at least from XP
forward. You use the WPP-specific debugger extension.

I’m not sure you’re saying that this doesn’t work, or if you’re just not
aware of the debugger extension that supports this. In any case, it’s
been (quite literally) a couple of years since I tried it… but I
THOUGHT I’d tried this and it worked.

Also, IIRC, there IS some support for retrieving stored DbgPrints from
crash dumps as well.

Peter
OSR

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

19

WPP requires so much nasty effort to do even the simplest things so I would
better code the ring buffer for a log (and IOCTL to retrieve it) myself.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Roddy, Mark”
To: “Windows System Software Devs Interest List”
Sent: Thursday, May 11, 2006 5:28 PM
Subject: RE: [ntdev] Unnecessary obfuscation, “Hey I can’t see my spew because
of your spew!!!”

I’ve haven’t found a compelling reason to use wpp for development. Like
you I just build my drivers so that the checked version uses debugprint
and the production version uses wpp. This limits wpp usage (no
non-printf compatible format specifiers) but that tradeoff has never
been a problem. I see no reason to change this.

Both wpp and debugprint suffer from not having a retrievable kernel
ringbuffer that captures run time trace information for post mortem
analysis. I hear rumors that this is fixed for wpp in vista, but I have
not verified it.

Runtime configurable debug prints are fine in production drivers, as
long as the driver ships in terse mode.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Thursday, May 11, 2006 4:16 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Unnecessary obfuscation, “Hey I can’t see my spew
because of your spew!!!”

> PHB> So ship it with the debugs in place: I need that code now!

Sounds almost exactly like the reason I just spent a bunch of effort to
make
my driver easily configurable (recompile) between WPP tracing and
DbgPrint’s.

The automatic builds done for the testing group (and eventually release)
will get WPP. Then the spew can go to a file, and I can see it when
testing
folks find issues. When interactively developing, WPP I find is pretty
painful, so would just prefer to see spew on windbg. I still haven’t
figured
out an easy way to switch between dbgprint+wpp and just wpp tracing.
Since
wpp source munging happens before the C preprocessor, I can’t just
#define
one DebugPrint into DebugPrintLocal+DebugPrintWPP.

Using WPP for my development is especially painful, because traceview
(even
the one in the WDK) cause MANY messages under the full checked OS (which
I
run all the time).

Does anybody know how to configure side-by-side user mode DLL’s like
comctl32.dll, so I can cause traceview to use the non-checked version,
but
still run a full checked kernel? WXP/W2K3 are supposed to allow doing
this,
if you know the right magic.

Peter also suggested I file a bug against traceview in the wdk, but I
could
not anyplace on the MS website to do so, or any email address in the WDF
for
reports bugs in the WDK tools (there was an address to report doc bugs).
A
search of the WDK help file for “report bug” found nothing, nothing in
the
release notes either.

- Jan

—
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

20

What? You mean you found ETW difficult to deal with…I’m shocked!!

As an amusing side note: Just a few weeks ago I watched as a, rather
insanely talented, engineer went through trying to make his own tracing tool
to use instead of the existing TraceLog et al and/or TraceView tools. He
wanted just a simple command-line utility to trace just one driver’s output.
No PDB parsing, nothing fancy just straight up simple tracing to a console’s
stdout. It was quite humorous. I don’t think I have heard so many English
and Russian expletives pour out of one individual in such rapid succession.
Something to the effect of f#cking useless seemed to be the most common
thing I could make out. Interesting how as soon as anyone gets to the heart
of ETW, like the asynchronous callbacks with no user available context, that
the fun really starts.

It’s just good to know that I am not alone.

Bill McKenzie

“Roddy, Mark” wrote in message news:xxxxx@ntdev…
As far as I can tell it does not work in XP SP2 or W2K3 SP1, wpp
specific extensions as supplied with the latest released windbg.
However, as with all things wpp there probably is some ritual behavior
involving blood sacrifice of large mammals that can coax the WPP/ETW
deity into beneficial behavior. I’ve tried sacrificing a goat. Any
suggestions?

The “support for retrieving stored DbgPrints from crash dumps” is
useless. To be useful a runtime trace ringbuffer needs to capture on the
order of thousands of discrete entries.

I didn’t mention boot trace support. Yet another wpp mystery.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, May 11, 2006 9:42 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Unnecessary obfuscation, “Hey I can’t see my spew
because of your spew!!!”



As I believe I’ve mentioned before, the way I understand it, working
support for ring-buffers for WPP output is available at least from XP
forward. You use the WPP-specific debugger extension.

I’m not sure you’re saying that this doesn’t work, or if you’re just not
aware of the debugger extension that supports this. In any case, it’s
been (quite literally) a couple of years since I tried it… but I
THOUGHT I’d tried this and it worked.

Also, IIRC, there IS some support for retrieving stored DbgPrints from
crash dumps as well.

Peter
OSR

—
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