What logging aproach do you use, what do is your experience with WPP?

Now I am using old-school dbgprint aproach for driver detailed logging and system event log for loging errors. Now I am thinking about WPP. It is really helpfull in one thing - I can use detailed logging without debug build in any env and debug build makes problems like some extra BSODs. From the other side WPP looks complicated and not very convinient. What is you WPP expirience pros/cons, what logging approach do you use in kernel drivers?

  1. You can use DebugPrint’s in release build, with your own enable/disable flags. Debug build is not required for this (though, IIRC some HCT tests for some driver classes may require that release build has no DebugPrint calls, this is not a technical limitation, and may be not applicable to your drivers)

  2. Please search ntdev for the recent WPP discussion, see Peters’ recent blog posts.

– pa

Hi,
I use both at the moment but I am tending to move to WPP exclusively.
I believe that the argument “WPP looks complicated and not very convenient”
can be true at first but it has its perks and one that I am really fond of
is the bits definition.
If your driver has some components and sub-components and you want to see
messages only from some of them you can do that easily with WPP.
You could do a similar configuration with your driver using DbgPrints but
WPP is more convenient.

I like that WPP has these nice %!FORMATS! that you can use in your traces (
https://msdn.microsoft.com/en-us/library/ff556136(v=vs.85).aspx )

You can use enumerations objects in your WPP trace. You can define a new
type like
// CUSTOM_TYPE(MYNEWTYPE, ItemEnum(MY_TYPE_ENUM));
and you can use it in your traces like: TraceFunc(…, %!MYNEWTYPE!,
theVariable…);
You can define complex types, read more here (
https://msdn.microsoft.com/en-us/library/windows/hardware/ff556148(v=vs.85).aspx
)

One last thing that I personally like about WPP is that the performance
during tracing does not seem to be very much changed which in my opinion is
what you want.

Hope this helps,
Gabriel

On Tue, Mar 22, 2016 at 1:53 PM, wrote:

> 1. You can use DebugPrint’s in release build, with your own enable/disable
> flags. Debug build is not required for this (though, IIRC some HCT tests
> for some driver classes may require that release build has no DebugPrint
> calls, this is not a technical limitation, and may be not applicable to
> your drivers)
>
> 2. Please search ntdev for the recent WPP discussion, see Peters’ recent
> blog posts.
>
> – pa
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>


Bercea. G.</http:>

Pavel,
How to make DebugPrint’s works in release ? For debug I am using [19.02.2016 15:40:58] Pavel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ Debug Print Filter key. And this doesn’t works in release builds…

xxxxx@gmail.com wrote:

How to make DebugPrint’s works in release ? For debug I am using [19.02.2016 15:40:58] Pavel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ Debug Print Filter key. And this doesn’t works in release builds…

KdPrint is a macro that evaluates to nothing in a debug build. If you
are using KdPrint, then there are no debug print calls in your code at
all in a release build.

In a debug build, KdPrint evaluates to a call to the DbgPrint API, and
that is always available. So, if there are strings you always want to
see, just call DbgPrint directly, omitting one set of parentheses.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.