FW: Re: How could Microsoft have signed this driver?

NTDEV
1

There will be session on event tracing at this year’s WinHEC titled
“Diagnostic Tracing with Event Tracing for Windows and TraceView”. It
will talk about this very thing. Dynamically enable debug output with
minimal performance impact – pretty nifty.

In the meantime, take a look at the CDROM sample in the WinXP DDK, the
section marked “WPP Software Tracing” and the NT Insider article.
Compile a copy of the CDROM driver, create a .TMF from the .PDB, then
start poking around on a computer with Windows XP on it. You might be
surprised.

L

-----Original Message-----
From: xxxxx@tenpennies.com [mailto:xxxxx@tenpennies.com]
Sent: Wednesday, April 09, 2003 12:50 PM
To: NT Developers Interest List

FYI:

There was an article about event tracing in Windows in the Jan-Feb 2003
NT
Insider.

The article made reference to “WPP Software Tracing” in the DDK.

Shaun

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Wednesday, April 09, 2003 11:50 AM
To: NT Developers Interest List
Subject: [ntdev] Re: How could Microsoft have signed this driver?

Well that (no diagnostic output in released drivers) is a bit of a
religious
issue isn’t it? It sort of assumes that released drivers are bug free
and
will never have to be debugged or diagnosed. I guess your experience
with
released drivers differs from mine :slight_smile:

I much prefer configurable debug levels (as in DebugPrintEx, for
example)
that can be turned on/off up/down as needed in realtime with the system
up
and running. It also would be real nice if NT actually logged the debug
console in a circular buffer in core so that it could be retreived from
dump
files.

-----Original Message-----
From: Mathieu Routhier [mailto:xxxxx@guillemot.com]
Sent: Wednesday, April 09, 2003 1:56 PM
To: NT Developers Interest List
Subject: [ntdev] Re: How could Microsoft have signed this driver?

Was that ironic?

It’s not that hard to have a TRACE() macro which will call
DbgPrint() in checked builds and evaluate to nothing in free
builds. No need to clutter your code with #ifdefs to get the
job done.

To my sense, a driver should never output unless it is a
driver you are in the process of developing/debugging. This
is only my opinion, though.

Mat

-----Original Message-----
From: Christine Ames [mailto:xxxxx@PacificDigital.com]
Sent: Wednesday, April 09, 2003 1:47 PM
To: NT Developers Interest List
Subject: [ntdev] Re: How could Microsoft have signed this driver?

> -----Original Message-----
> From: Mathieu Routhier [mailto:xxxxx@guillemot.com]
> Sent: Wednesday, April 09, 2003 9:55 AM
>
> And even Windows Messenger! Which is there *by default* in XP.
>

> >
>
> Yes, well… I guess we’ve all seen someone’s inattention
> to detail flowing out the debug window at least once. Makes
> you think they’ve never heard of an “#ifdef”…as in:
>
> #ifdef MYDEBUG
> DebugPrint((1, “Dude, I make it HERE…\n”));
> #endif
>
> I realize this means you’ll need to wrap EACH AND EVERY
> SINGLE DEBUG OUT with the offending #ifdefs; AND you’ll have
> to #define MYDEBUG; AND you’ll need to UNDEFINE said
> definition and RECOMPILE on that fateful day when you
> actually release your code.
>
> That said, may I submit another Commandment?
>
> “If you wish to debug your code in the event of difficulties,
> you shall wrap each and every debug out with #ifdefs, yes,
> even though these #ifdefs triple the size of your code and
> produce aches in your typing fingers; for if you think,
> “nobody is ever going to see these but me”, your peers shall
> surely embarrass you for your arrogance.”
>
> Harmony,
>
> --Christine
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@guillemot.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

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

2

I agree with you Mark. My drivers all use configurable debug levels for
debug print statements as well as information that we might write to the
Event Log. It’s really very easy to do and once you have to code very easy
to continue using. With the appropriate macros, the code doesn’t even look
too cluttered (not #ifdefs in the code).

It doesn’t bother me too much when I see other drivers dumping a little bit
of information to the debug buffer (like on startup or shutdown) but this
driver is printing so much that the machine is almost unusable when the
debugger is connected. Plus, any messages that we might want to output
during debug get scrolled so fast you might actually miss them.

  • Steve -

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Wednesday, April 09, 2003 2:50 PM
To: NT Developers Interest List
Subject: [ntdev] Re: How could Microsoft have signed this driver?

Well that (no diagnostic output in released drivers) is a bit
of a religious
issue isn’t it? It sort of assumes that released drivers are
bug free and
will never have to be debugged or diagnosed. I guess your
experience with
released drivers differs from mine :slight_smile:

I much prefer configurable debug levels (as in DebugPrintEx,
for example)
that can be turned on/off up/down as needed in realtime with
the system up
and running. It also would be real nice if NT actually logged
the debug
console in a circular buffer in core so that it could be
retreived from dump
files.

> -----Original Message-----
> From: Mathieu Routhier [mailto:xxxxx@guillemot.com]
> Sent: Wednesday, April 09, 2003 1:56 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: How could Microsoft have signed this driver?
>
>
>
> Was that ironic?
>
> It’s not that hard to have a TRACE() macro which will call
> DbgPrint() in checked builds and evaluate to nothing in free
> builds. No need to clutter your code with #ifdefs to get the
> job done.
>
> To my sense, a driver should never output unless it is a
> driver you are in the process of developing/debugging. This
> is only my opinion, though.
>
> Mat
>
> -----Original Message-----
> From: Christine Ames [mailto:xxxxx@PacificDigital.com]
> Sent: Wednesday, April 09, 2003 1:47 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: How could Microsoft have signed this driver?
>
> > -----Original Message-----
> > From: Mathieu Routhier [mailto:xxxxx@guillemot.com]
> > Sent: Wednesday, April 09, 2003 9:55 AM
> >
> > And even Windows Messenger! Which is there *by default* in XP.
> >
>
> > >
> >
> > Yes, well… I guess we’ve all seen someone’s inattention
> > to detail flowing out the debug window at least once. Makes
> > you think they’ve never heard of an “#ifdef”…as in:
> >
> > #ifdef MYDEBUG
> > DebugPrint((1, “Dude, I make it HERE…\n”));
> > #endif
> >
> > I realize this means you’ll need to wrap EACH AND EVERY
> > SINGLE DEBUG OUT with the offending #ifdefs; AND you’ll have
> > to #define MYDEBUG; AND you’ll need to UNDEFINE said
> > definition and RECOMPILE on that fateful day when you
> > actually release your code.
> >
> > That said, may I submit another Commandment?
> >
> > “If you wish to debug your code in the event of difficulties,
> > you shall wrap each and every debug out with #ifdefs, yes,
> > even though these #ifdefs triple the size of your code and
> > produce aches in your typing fingers; for if you think,
> > “nobody is ever going to see these but me”, your peers shall
> > surely embarrass you for your arrogance.”
> >
> > Harmony,
> >
> > --Christine
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@guillemot.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@stratus.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@cognex.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

3

Same thing with the new filemon code. Cant use it with the debugger
attached, so I had to go back to old versions.

Thanks,
Rob

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Whitman, Steve
Sent: Wednesday, April 09, 2003 6:55 PM
To: NT Developers Interest List
Subject: [ntdev] Re: How could Microsoft have signed this driver?

I agree with you Mark. My drivers all use configurable debug levels for
debug print statements as well as information that we might write to the
Event Log. It’s really very easy to do and once you have to code very
easy
to continue using. With the appropriate macros, the code doesn’t even
look
too cluttered (not #ifdefs in the code).

It doesn’t bother me too much when I see other drivers dumping a little
bit
of information to the debug buffer (like on startup or shutdown) but
this
driver is printing so much that the machine is almost unusable when the
debugger is connected. Plus, any messages that we might want to output
during debug get scrolled so fast you might actually miss them.

  • Steve -

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Wednesday, April 09, 2003 2:50 PM
To: NT Developers Interest List
Subject: [ntdev] Re: How could Microsoft have signed this driver?

Well that (no diagnostic output in released drivers) is a bit
of a religious
issue isn’t it? It sort of assumes that released drivers are
bug free and
will never have to be debugged or diagnosed. I guess your
experience with
released drivers differs from mine :slight_smile:

I much prefer configurable debug levels (as in DebugPrintEx,
for example)
that can be turned on/off up/down as needed in realtime with
the system up
and running. It also would be real nice if NT actually logged
the debug
console in a circular buffer in core so that it could be
retreived from dump
files.

> -----Original Message-----
> From: Mathieu Routhier [mailto:xxxxx@guillemot.com]
> Sent: Wednesday, April 09, 2003 1:56 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: How could Microsoft have signed this driver?
>
>
>
> Was that ironic?
>
> It’s not that hard to have a TRACE() macro which will call
> DbgPrint() in checked builds and evaluate to nothing in free
> builds. No need to clutter your code with #ifdefs to get the
> job done.
>
> To my sense, a driver should never output unless it is a
> driver you are in the process of developing/debugging. This
> is only my opinion, though.
>
> Mat
>
> -----Original Message-----
> From: Christine Ames [mailto:xxxxx@PacificDigital.com]
> Sent: Wednesday, April 09, 2003 1:47 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: How could Microsoft have signed this driver?
>
> > -----Original Message-----
> > From: Mathieu Routhier [mailto:xxxxx@guillemot.com]
> > Sent: Wednesday, April 09, 2003 9:55 AM
> >
> > And even Windows Messenger! Which is there *by default* in XP.
> >
>
> > >
> >
> > Yes, well… I guess we’ve all seen someone’s inattention
> > to detail flowing out the debug window at least once. Makes
> > you think they’ve never heard of an “#ifdef”…as in:
> >
> > #ifdef MYDEBUG
> > DebugPrint((1, “Dude, I make it HERE…\n”));
> > #endif
> >
> > I realize this means you’ll need to wrap EACH AND EVERY
> > SINGLE DEBUG OUT with the offending #ifdefs; AND you’ll have
> > to #define MYDEBUG; AND you’ll need to UNDEFINE said
> > definition and RECOMPILE on that fateful day when you
> > actually release your code.
> >
> > That said, may I submit another Commandment?
> >
> > “If you wish to debug your code in the event of difficulties,
> > you shall wrap each and every debug out with #ifdefs, yes,
> > even though these #ifdefs triple the size of your code and
> > produce aches in your typing fingers; for if you think,
> > “nobody is ever going to see these but me”, your peers shall
> > surely embarrass you for your arrogance.”
> >
> > Harmony,
> >
> > --Christine
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@guillemot.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@stratus.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@cognex.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

4

Peter,

I haven’t really looked into Event Tracing but it does look very useful.
However, if you need to support NT 4.0 or Windows 98 you stuck with
DbgPrint.

BTW, the correct link to the NT Insider article is:
http://www.osr.com/ntinsider/2003/tracing.htm

Of course, my original question about MS signing this driver leaves one with
the feeling the driver signing is not worth the security certificates it’s
installed with if something as bad as this 3com driver is signed.

  • Steve -

-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Wednesday, April 09, 2003 4:49 PM
To: NT Developers Interest List
Subject: [ntdev] Re: How could Microsoft have signed this driver?

wrote in message news:xxxxx@ntdev…
> >
> > There was an article about event tracing in Windows in the
> Jan-Feb 2003 NT
> > Insider.
> >
> > The article made reference to “WPP Software Tracing” in the DDK.
> >
>
> Leaving your DbgPrints in your driver for all to see really IS
> embarassing…
>
> But, what you should do is get rid of all that antiquated
> DbgPrint crap, and
> use Event Tracing for Windows instead. THAT way, you can
> leave the trace
> statements in the free build of your driver (low overhead…
> just one test
> per statement), and enable them when you want to see the output.
>
> When you DO turn on tracing, the trace data is buffered. You
> can direct the
> output to a file, have it interpreted and output in
> real-time, or even sent
> to the debugger (where it will look a lot like the output of those old
> DbgPrint statements).
>
> And, best of all, you can have your customers collect the
> trace data which
> is binary formatted… but does NOT contain things like
> interpreted output.
> They email the data to you, and you format it for display.
>
> Plus (of course) when the system crashes, the trace messages can be
> retrieved from any as-yet unwritten buffers.
>
> In case you haven’t already seen The NT Insider article:
> http://www.osr.com/ntinsider/2003/without%20a%20trace.htm
>
> More to be published on this topic in The NT Insider in the
> May/June issue,
> too…
>
> Peter
> OSR
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@cognex.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

5

“Whitman, Steve” wrote in message news:xxxxx@ntdev…
>
> Peter,
>
> However, if you need to support NT 4.0 or Windows 98 you stuck with
>

Sigh! How true…

> BTW, the correct link to the NT Insider article is:
> http://www.osr.com/ntinsider/2003/tracing.htm
>

Thanks… Dan moved it after I posted it. Now BOTH links work :slight_smile:

p

6

“Whitman, Steve” wrote:

I have a Dell system with an integrated 3com enet adapter. When I connect
WinDbg to the system I can’t do anything because the following debug print
message repeats itself in the WinDbg command window:
Diag Driver: Received
IsEchoRequest
IsWakeUpRequest
This message appears to repeat as fast as it can be sent to WinDbg. I have
determined that the network card is the culprit because if I disable the
driver the messages immediate stop. Re-enable the driver and the messages
start right back up. Also, changing some of the card’s modes cause
additional messages to be displayed. The driver that I’m using was
installed via the Windows Update mechanism and is a signed driver!!

I recall another 3COM driver that they released with all the debug spew
turned on. I eventually started bringing a little thing called
DTAMUTE.VXD with me to Win 9x consulting gigs just so I could see my own
debug messages. I even wrote a letter to the CEO of 3COM suggesting that
he hire me to train his developers to avoid rookie mistakes like that.
Can’t imagine why I never got a reply…

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com

7

It passed all WHQL tests - and thus was signed. Maybe MS do not test
the drivers with WinDbg attached.

Max

----- Original Message -----
From: “Whitman, Steve”
To: “NT Developers Interest List”
Sent: Wednesday, April 09, 2003 7:36 PM
Subject: [ntdev] How could Microsoft have signed this driver?

> I have a Dell system with an integrated 3com enet adapter. When I
connect
> WinDbg to the system I can’t do anything because the following debug
print
> message repeats itself in the WinDbg command window:
> Diag Driver: Received
> IsEchoRequest
> IsWakeUpRequest
> This message appears to repeat as fast as it can be sent to WinDbg.
I have
> determined that the network card is the culprit because if I disable
the
> driver the messages immediate stop. Re-enable the driver and the
messages
> start right back up. Also, changing some of the card’s modes cause
> additional messages to be displayed. The driver that I’m using was
> installed via the Windows Update mechanism and is a signed driver!!
>
> How can Microsoft let something like this driver get signed?
>
> - Steve -
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to
xxxxx@lists.osr.com

8

May I suggest an update to the WHQL specs - a release-build driver may
not call the DbgPrint API in its default configuration.

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
S. Shatskih
Sent: Saturday, April 12, 2003 11:31 AM
To: NT Developers Interest List
Subject: [ntdev] Re: How could Microsoft have signed this driver?

It passed all WHQL tests - and thus was signed. Maybe MS do
not test the drivers with WinDbg attached.

Max

----- Original Message -----
From: “Whitman, Steve”
> To: “NT Developers Interest List”
> Sent: Wednesday, April 09, 2003 7:36 PM
> Subject: [ntdev] How could Microsoft have signed this driver?
>
>
> > I have a Dell system with an integrated 3com enet adapter. When I
> connect
> > WinDbg to the system I can’t do anything because the following debug
> print
> > message repeats itself in the WinDbg command window:
> > Diag Driver: Received
> > IsEchoRequest
> > IsWakeUpRequest
> > This message appears to repeat as fast as it can be sent to WinDbg.
> I have
> > determined that the network card is the culprit because if I disable
> the
> > driver the messages immediate stop. Re-enable the driver and the
> messages
> > start right back up. Also, changing some of the card’s modes cause
> > additional messages to be displayed. The driver that I’m using was
> > installed via the Windows Update mechanism and is a signed driver!!
> >
> > How can Microsoft let something like this driver get signed?
> >
> > - Steve -
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

9

I checked into this and NDISTEST does test for DbgPrint and will fail
drivers that import it; however, there was one release of that tool
where that wasn’t tested. It’s possible that this driver was logoed
with that particular release, and thus, wasn’t caught.

I worked with Steve offline and got version info from him. I worked
with the NDIS team here and verified that this is not the driver that
was shipped in-box with 2000, XP, XP SP1 or Server 2003. Steve reported
that he received this copy of the driver from 3-Com’s web site. I don’t
know if the driver from other sources (Dell’s site, Windows Update, etc)
has the same problem or not.

Steve, thank you for bring this to our attention.

Bryan S. Burgin
xxxxx@microsoft.com

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: Nicholas Ryan [mailto:xxxxx@nryan.com]
Sent: Saturday, April 12, 2003 12:36 PM
To: NT Developers Interest List
Subject: [ntdev] Re: How could Microsoft have signed this driver?

May I suggest an update to the WHQL specs - a release-build driver may
not call the DbgPrint API in its default configuration.

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
S. Shatskih
Sent: Saturday, April 12, 2003 11:31 AM
To: NT Developers Interest List
Subject: [ntdev] Re: How could Microsoft have signed this driver?

It passed all WHQL tests - and thus was signed. Maybe MS do
not test the drivers with WinDbg attached.

Max

----- Original Message -----
From: “Whitman, Steve”
> To: “NT Developers Interest List”
> Sent: Wednesday, April 09, 2003 7:36 PM
> Subject: [ntdev] How could Microsoft have signed this driver?
>
>
> > I have a Dell system with an integrated 3com enet adapter. When I
> connect
> > WinDbg to the system I can’t do anything because the following debug
> print
> > message repeats itself in the WinDbg command window:
> > Diag Driver: Received
> > IsEchoRequest
> > IsWakeUpRequest
> > This message appears to repeat as fast as it can be sent to WinDbg.
> I have
> > determined that the network card is the culprit because if I disable
> the
> > driver the messages immediate stop. Re-enable the driver and the
> messages
> > start right back up. Also, changing some of the card’s modes cause
> > additional messages to be displayed. The driver that I’m using was
> > installed via the Windows Update mechanism and is a signed driver!!
> >
> > How can Microsoft let something like this driver get signed?
> >
> > - Steve -
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

10

Brian,

Other versions of this driver (from Dell’s website and Windows Update) also
had the same problem. All versions were signed. I can probably get the
version information of the other drivers if it will help.

  • Steve -

-----Original Message-----
From: Bryan Burgin [mailto:xxxxx@microsoft.com]
Sent: Saturday, April 12, 2003 7:51 PM
To: NT Developers Interest List
Cc: xxxxx@cognex.com
Subject: RE: [ntdev] Re: How could Microsoft have signed this driver?

I checked into this and NDISTEST does test for DbgPrint and will fail
drivers that import it; however, there was one release of that tool
where that wasn’t tested. It’s possible that this driver was logoed
with that particular release, and thus, wasn’t caught.

I worked with Steve offline and got version info from him. I worked
with the NDIS team here and verified that this is not the driver that
was shipped in-box with 2000, XP, XP SP1 or Server 2003.
Steve reported
that he received this copy of the driver from 3-Com’s web
site. I don’t
know if the driver from other sources (Dell’s site, Windows
Update, etc)
has the same problem or not.

Steve, thank you for bring this to our attention.

Bryan S. Burgin
xxxxx@microsoft.com

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: Nicholas Ryan [mailto:xxxxx@nryan.com]
Sent: Saturday, April 12, 2003 12:36 PM
To: NT Developers Interest List
Subject: [ntdev] Re: How could Microsoft have signed this driver?

May I suggest an update to the WHQL specs - a release-build driver may
not call the DbgPrint API in its default configuration.

  • Nicholas Ryan

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
> S. Shatskih
> Sent: Saturday, April 12, 2003 11:31 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: How could Microsoft have signed this driver?
>
>
> It passed all WHQL tests - and thus was signed. Maybe MS do
> not test the drivers with WinDbg attached.
>
> Max
>
> ----- Original Message -----
> From: “Whitman, Steve”
> > To: “NT Developers Interest List”
> > Sent: Wednesday, April 09, 2003 7:36 PM
> > Subject: [ntdev] How could Microsoft have signed this driver?
> >
> >
> > > I have a Dell system with an integrated 3com enet adapter. When I
> > connect
> > > WinDbg to the system I can’t do anything because the
> following debug
> > print
> > > message repeats itself in the WinDbg command window:
> > > Diag Driver: Received
> > > IsEchoRequest
> > > IsWakeUpRequest
> > > This message appears to repeat as fast as it can be sent
> to WinDbg.
> > I have
> > > determined that the network card is the culprit because
> if I disable
> > the
> > > driver the messages immediate stop. Re-enable the driver and the
> > messages
> > > start right back up. Also, changing some of the card’s
> modes cause
> > > additional messages to be displayed. The driver that I’m
> using was
> > > installed via the Windows Update mechanism and is a
> signed driver!!
> > >
> > > How can Microsoft let something like this driver get signed?
> > >
> > > - Steve -
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as:
> xxxxx@storagecraft.com To
> > > unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@nryan.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

11

Well once again, I suggest NOT making such a mandatory limitation on
runtime debugging. The ability to field-enable runtime tracing greatly
enhances driver servicability.

The issue is not ‘does the driver link to debugprint’, the issue
is ‘does the driver needlessly spew into the debug console’. Those are
actually different issues.

===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032

-----Original Message-----
From: “Bryan Burgin”
To: “NT Developers Interest List”
Cc:
Date: Sat, 12 Apr 2003 16:50:47 -0700
Subject: [ntdev] Re: How could Microsoft have signed this driver?

> I checked into this and NDISTEST does test for DbgPrint and will fail
> drivers that import it; however, there was one release of that tool
> where that wasn’t tested. It’s possible that this driver was logoed
> with that particular release, and thus, wasn’t caught.
>
> I worked with Steve offline and got version info from him. I worked
> with the NDIS team here and verified that this is not the driver that
> was shipped in-box with 2000, XP, XP SP1 or Server 2003. Steve
> reported
> that he received this copy of the driver from 3-Com’s web site. I
> don’t
> know if the driver from other sources (Dell’s site, Windows Update,
> etc)
> has the same problem or not.
>
> Steve, thank you for bring this to our attention.
>
> Bryan S. Burgin
> xxxxx@microsoft.com
>
> This posting is provided “AS IS” with no warranties, and confers no
> rights.
>
> -----Original Message-----
> From: Nicholas Ryan [mailto:xxxxx@nryan.com]
> Sent: Saturday, April 12, 2003 12:36 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: How could Microsoft have signed this driver?
>
> May I suggest an update to the WHQL specs - a release-build driver may
> not call the DbgPrint API in its default configuration.
>
> - Nicholas Ryan
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
> > S. Shatskih
> > Sent: Saturday, April 12, 2003 11:31 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: How could Microsoft have signed this driver?
> >
> >
> > It passed all WHQL tests - and thus was signed. Maybe MS do
> > not test the drivers with WinDbg attached.
> >
> > Max
> >
> > ----- Original Message -----
> > From: “Whitman, Steve”
> > To: “NT Developers Interest List”
> > Sent: Wednesday, April 09, 2003 7:36 PM
> > Subject: [ntdev] How could Microsoft have signed this driver?
> >
> >
> > > I have a Dell system with an integrated 3com enet adapter. When I
> > connect
> > > WinDbg to the system I can’t do anything because the following
> debug
> > print
> > > message repeats itself in the WinDbg command window:
> > > Diag Driver: Received
> > > IsEchoRequest
> > > IsWakeUpRequest
> > > This message appears to repeat as fast as it can be sent to WinDbg.
> > I have
> > > determined that the network card is the culprit because if I
> disable
> > the
> > > driver the messages immediate stop. Re-enable the driver and the
> > messages
> > > start right back up. Also, changing some of the card’s modes cause
> > > additional messages to be displayed. The driver that I’m using was
> > > installed via the Windows Update mechanism and is a signed driver!!
> > >
> > > How can Microsoft let something like this driver get signed?
> > >
> > > - Steve -
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > > unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@nryan.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

12

With the new Event Tracing that is available in Windows 2000 and Windows XP,
MS may be making that statement that that is the mechanism that signed
drivers must use if they wish to be able to do in the field tracing.

Of course that doesn’t help with Windows 9x or NT but those drivers aren’t
signed.

  • Steve -

-----Original Message-----
From: Mark Roddy [mailto:xxxxx@hollistech.com]
Sent: Monday, April 14, 2003 10:06 AM
To: NT Developers Interest List
Subject: [ntdev] Re: How could Microsoft have signed this driver?

Well once again, I suggest NOT making such a mandatory limitation on
runtime debugging. The ability to field-enable runtime
tracing greatly
enhances driver servicability.

The issue is not ‘does the driver link to debugprint’, the issue
is ‘does the driver needlessly spew into the debug console’.
Those are
actually different issues.

===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032

-----Original Message-----
From: “Bryan Burgin”
> To: “NT Developers Interest List”
> Cc:
> Date: Sat, 12 Apr 2003 16:50:47 -0700
> Subject: [ntdev] Re: How could Microsoft have signed this driver?
>
> > I checked into this and NDISTEST does test for DbgPrint and
> will fail
> > drivers that import it; however, there was one release of that tool
> > where that wasn’t tested. It’s possible that this driver was logoed
> > with that particular release, and thus, wasn’t caught.
> >
> > I worked with Steve offline and got version info from him. I worked
> > with the NDIS team here and verified that this is not the
> driver that
> > was shipped in-box with 2000, XP, XP SP1 or Server 2003. Steve
> > reported
> > that he received this copy of the driver from 3-Com’s web site. I
> > don’t
> > know if the driver from other sources (Dell’s site, Windows Update,
> > etc)
> > has the same problem or not.
> >
> > Steve, thank you for bring this to our attention.
> >
> > Bryan S. Burgin
> > xxxxx@microsoft.com
> >
> > This posting is provided “AS IS” with no warranties, and confers no
> > rights.
> >
> > -----Original Message-----
> > From: Nicholas Ryan [mailto:xxxxx@nryan.com]
> > Sent: Saturday, April 12, 2003 12:36 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: How could Microsoft have signed this driver?
> >
> > May I suggest an update to the WHQL specs - a release-build
> driver may
> > not call the DbgPrint API in its default configuration.
> >
> > - Nicholas Ryan
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
> > > S. Shatskih
> > > Sent: Saturday, April 12, 2003 11:31 AM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Re: How could Microsoft have signed this driver?
> > >
> > >
> > > It passed all WHQL tests - and thus was signed. Maybe MS do
> > > not test the drivers with WinDbg attached.
> > >
> > > Max
> > >
> > > ----- Original Message -----
> > > From: “Whitman, Steve”
> > > To: “NT Developers Interest List”
> > > Sent: Wednesday, April 09, 2003 7:36 PM
> > > Subject: [ntdev] How could Microsoft have signed this driver?
> > >
> > >
> > > > I have a Dell system with an integrated 3com enet
> adapter. When I
> > > connect
> > > > WinDbg to the system I can’t do anything because the following
> > debug
> > > print
> > > > message repeats itself in the WinDbg command window:
> > > > Diag Driver: Received
> > > > IsEchoRequest
> > > > IsWakeUpRequest
> > > > This message appears to repeat as fast as it can be
> sent to WinDbg.
> > > I have
> > > > determined that the network card is the culprit because if I
> > disable
> > > the
> > > > driver the messages immediate stop. Re-enable the
> driver and the
> > > messages
> > > > start right back up. Also, changing some of the card’s
> modes cause
> > > > additional messages to be displayed. The driver that
> I’m using was
> > > > installed via the Windows Update mechanism and is a
> signed driver!!
> > > >
> > > > How can Microsoft let something like this driver get signed?
> > > >
> > > > - Steve -
> > > >
> > > >
> > > > —
> > > > You are currently subscribed to ntdev as:
> xxxxx@storagecraft.com To
> > > > unsubscribe send a blank email to
> > > xxxxx@lists.osr.com
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@nryan.com
> > > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@microsoft.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@hollistech.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@cognex.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

13

Actually, while it is easy to enforce ‘no linking to debugprint’ in an ndis
driver, it would be difficult to enforce the same restriction on a kernel
mode driver.

-----Original Message-----
From: Whitman, Steve [mailto:xxxxx@cognex.com]
Sent: Monday, April 14, 2003 10:18 AM
To: NT Developers Interest List
Subject: [ntdev] Re: How could Microsoft have signed this driver?

With the new Event Tracing that is available in Windows 2000
and Windows XP, MS may be making that statement that that is
the mechanism that signed drivers must use if they wish to be
able to do in the field tracing.

Of course that doesn’t help with Windows 9x or NT but those
drivers aren’t signed.

  • Steve -

> -----Original Message-----
> From: Mark Roddy [mailto:xxxxx@hollistech.com]
> Sent: Monday, April 14, 2003 10:06 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: How could Microsoft have signed this driver?
>
>
> Well once again, I suggest NOT making such a mandatory limitation on
> runtime debugging. The ability to field-enable runtime
> tracing greatly
> enhances driver servicability.
>
> The issue is not ‘does the driver link to debugprint’, the issue
> is ‘does the driver needlessly spew into the debug console’.
> Those are
> actually different issues.
>
>
> ===========================
> Mark Roddy
> Consultant, Microsoft DDK MVP
> Hollis Technology Solutions
> xxxxx@hollistech.com
> www.hollistech.com
> 603-321-1032
>
>
> -----Original Message-----
> From: “Bryan Burgin”
> > To: “NT Developers Interest List”
> > Cc:
> > Date: Sat, 12 Apr 2003 16:50:47 -0700
> > Subject: [ntdev] Re: How could Microsoft have signed this driver?
> >
> > > I checked into this and NDISTEST does test for DbgPrint and
> > will fail
> > > drivers that import it; however, there was one release of
> that tool
> > > where that wasn’t tested. It’s possible that this driver
> was logoed
> > > with that particular release, and thus, wasn’t caught.
> > >
> > > I worked with Steve offline and got version info from
> him. I worked
> > > with the NDIS team here and verified that this is not the
> > driver that
> > > was shipped in-box with 2000, XP, XP SP1 or Server 2003. Steve
> > > reported that he received this copy of the driver from
> 3-Com’s web
> > > site. I don’t
> > > know if the driver from other sources (Dell’s site,
> Windows Update,
> > > etc)
> > > has the same problem or not.
> > >
> > > Steve, thank you for bring this to our attention.
> > >
> > > Bryan S. Burgin
> > > xxxxx@microsoft.com
> > >
> > > This posting is provided “AS IS” with no warranties, and
> confers no
> > > rights.
> > >
> > > -----Original Message-----
> > > From: Nicholas Ryan [mailto:xxxxx@nryan.com]
> > > Sent: Saturday, April 12, 2003 12:36 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Re: How could Microsoft have signed this driver?
> > >
> > > May I suggest an update to the WHQL specs - a release-build
> > driver may
> > > not call the DbgPrint API in its default configuration.
> > >
> > > - Nicholas Ryan
> > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
> > > > S. Shatskih
> > > > Sent: Saturday, April 12, 2003 11:31 AM
> > > > To: NT Developers Interest List
> > > > Subject: [ntdev] Re: How could Microsoft have signed
> this driver?
> > > >
> > > >
> > > > It passed all WHQL tests - and thus was signed. Maybe MS do
> > > > not test the drivers with WinDbg attached.
> > > >
> > > > Max
> > > >
> > > > ----- Original Message -----
> > > > From: “Whitman, Steve”
> > > > To: “NT Developers Interest List”
> > > > Sent: Wednesday, April 09, 2003 7:36 PM
> > > > Subject: [ntdev] How could Microsoft have signed this driver?
> > > >
> > > >
> > > > > I have a Dell system with an integrated 3com enet
> > adapter. When I
> > > > connect
> > > > > WinDbg to the system I can’t do anything because the following
> > > debug
> > > > print
> > > > > message repeats itself in the WinDbg command window:
> > > > > Diag Driver: Received
> > > > > IsEchoRequest
> > > > > IsWakeUpRequest
> > > > > This message appears to repeat as fast as it can be
> > sent to WinDbg.
> > > > I have
> > > > > determined that the network card is the culprit because if I
> > > disable
> > > > the
> > > > > driver the messages immediate stop. Re-enable the
> > driver and the
> > > > messages
> > > > > start right back up. Also, changing some of the card’s
> > modes cause
> > > > > additional messages to be displayed. The driver that
> > I’m using was
> > > > > installed via the Windows Update mechanism and is a
> > signed driver!!
> > > > >
> > > > > How can Microsoft let something like this driver get signed?
> > > > >
> > > > > - Steve -
> > > > >
> > > > >
> > > > > —
> > > > > You are currently subscribed to ntdev as:
> > xxxxx@storagecraft.com To
> > > > > unsubscribe send a blank email to
> > > > xxxxx@lists.osr.com
> > > >
> > > >
> > > >
> > > > —
> > > > You are currently subscribed to ntdev as: xxxxx@nryan.com To
> > > > unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> > > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as:
> xxxxx@microsoft.com To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@hollistech.com To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@cognex.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

14

> ----------

From: xxxxx@cognex.com[SMTP:xxxxx@cognex.com]
Reply To: xxxxx@lists.osr.com
Sent: Monday, April 14, 2003 4:17 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: How could Microsoft have signed this driver?

With the new Event Tracing that is available in Windows 2000 and Windows
XP,
MS may be making that statement that that is the mechanism that signed
drivers must use if they wish to be able to do in the field tracing.

Uh oh. I guess you’re right; is there some official statement from MS?

I quickly examined new event tracing and found it too limited. Main
complaint is (if I haven’t missed something) it uses bitmask for per-group
trace enable which can only enable or disable given group. We use two level
approach; trace areas which define group and level per area. Area is some
logical unit as source file, class or functionality. One executable usually
contais several areas, every one with assigned level which allows developer
to set tracing as necessary for problem solution and avoid unnecessary
traces. Of course, this solution uses DbgPrint in kernel mode and I’m not
sure how to emulate it over new event tracing.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

15

This is possible by overriding the default Flags processing and in fact
someone posted an example of this back in February.

WPP has two options to control printing messages, flags and levels.
Bits are a DWORD
Levels are a BYTE

Say header file has the following added:
#define WPP_LEVEL_FLAGS_LOGGER(lvl,flags) WPP_LEVEL_LOGGER(flags)
#define WPP_LEVEL_FLAGS_ENABLED(lvl, flags) (WPP_LEVEL_ENABLED(flags) &&
WPP_CONTROL(WPP_BIT_ ## flags).Level >= lvl)

Then, add the following line to your SOURCES file:
RUN_WPP=$(SOURCES) -func:DoTraceLevelMessage(LEVEL,FLAGS,MSG,…)

This allows you to do the following:
DoTraceLevelMessage(3,PNP_DEBUG, “Hello, %s %d”, “World”, i);

The above trace will only occur if *BOTH* the PNP_DEBUG flag is set and
the level is >= 3. I think this is more of what you are looking for.
The other alternative is to have multiple GUIDs, but I suggest the above
(it’s cleaner).

-----Original Message-----
From: Michal Vodicka [mailto:xxxxx@veridicom.cz.nospam]
Sent: Monday, April 14, 2003 11:46 AM
To: NT Developers Interest List

From: xxxxx@cognex.com[SMTP:xxxxx@cognex.com]
Reply To: xxxxx@lists.osr.com
Sent: Monday, April 14, 2003 4:17 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: How could Microsoft have signed this driver?

With the new Event Tracing that is available in Windows 2000 and
Windows
XP,
MS may be making that statement that that is the mechanism that signed
drivers must use if they wish to be able to do in the field tracing.

Uh oh. I guess you’re right; is there some official statement from MS?

I quickly examined new event tracing and found it too limited. Main
complaint is (if I haven’t missed something) it uses bitmask for
per-group
trace enable which can only enable or disable given group. We use two
level
approach; trace areas which define group and level per area. Area is
some
logical unit as source file, class or functionality. One executable
usually
contais several areas, every one with assigned level which allows
developer
to set tracing as necessary for problem solution and avoid unnecessary
traces. Of course, this solution uses DbgPrint in kernel mode and I’m
not
sure how to emulate it over new event tracing.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

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

16

Thanks, that’s interesting, I missed this message in February. Looking into
WPP templates I’m not sure if I understand correctly: it seems there is one
control block per driver (GUID?) with associated flags and level. What I
need is one level per flag i.e. flag enables or disables tracing for the
area at all (or determines area) and associated level tells which events
from this area should be traced. One global level isn’t enough and more
GUIDs seems as an overkill. Maybe it is possible; WPP seems really powerfull
and deserves some docs and advanced examples.

I’ll definitely examine it; just porting our trace library to the fifth
platform, every one with different low level support so no problem with the
next one. Hopefully it is easier than event logging; the amount of work
necessary to have the simplest message logged is really discouraging there
(and the reason many drivers don’t use it at all, I guess).

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, April 15, 2003 12:06 AM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: How could Microsoft have signed this driver?

This is possible by overriding the default Flags processing and in fact
someone posted an example of this back in February.

WPP has two options to control printing messages, flags and levels.
Bits are a DWORD
Levels are a BYTE

Say header file has the following added:
#define WPP_LEVEL_FLAGS_LOGGER(lvl,flags) WPP_LEVEL_LOGGER(flags)
#define WPP_LEVEL_FLAGS_ENABLED(lvl, flags) (WPP_LEVEL_ENABLED(flags) &&
WPP_CONTROL(WPP_BIT_ ## flags).Level >= lvl)

Then, add the following line to your SOURCES file:
RUN_WPP=$(SOURCES) -func:DoTraceLevelMessage(LEVEL,FLAGS,MSG,…)

This allows you to do the following:
DoTraceLevelMessage(3,PNP_DEBUG, “Hello, %s %d”, “World”, i);

The above trace will only occur if *BOTH* the PNP_DEBUG flag is set and
the level is >= 3. I think this is more of what you are looking for.
The other alternative is to have multiple GUIDs, but I suggest the above
(it’s cleaner).

-----Original Message-----
From: Michal Vodicka [mailto:xxxxx@veridicom.cz.nospam]
Sent: Monday, April 14, 2003 11:46 AM
To: NT Developers Interest List

> ----------
> From: xxxxx@cognex.com[SMTP:xxxxx@cognex.com]
> Reply To: xxxxx@lists.osr.com
> Sent: Monday, April 14, 2003 4:17 PM
> To: xxxxx@lists.osr.com
> Subject: [ntdev] Re: How could Microsoft have signed this driver?
>
> With the new Event Tracing that is available in Windows 2000 and
Windows
> XP,
> MS may be making that statement that that is the mechanism that signed
> drivers must use if they wish to be able to do in the field tracing.
>
Uh oh. I guess you’re right; is there some official statement from MS?

I quickly examined new event tracing and found it too limited. Main
complaint is (if I haven’t missed something) it uses bitmask for
per-group
trace enable which can only enable or disable given group. We use two
level
approach; trace areas which define group and level per area. Area is
some
logical unit as source file, class or functionality. One executable
usually
contais several areas, every one with assigned level which allows
developer
to set tracing as necessary for problem solution and avoid unnecessary
traces. Of course, this solution uses DbgPrint in kernel mode and I’m
not
sure how to emulate it over new event tracing.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

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

You are currently subscribed to ntdev as: michal.vodicka@st.com
To unsubscribe send a blank email to xxxxx@lists.osr.com