WPP tracing from header files

Christian_Port · July 11, 2007, 8:48am

Hello

We have a C++ driver that needs to generate WPP traces from a header-file-only class implementation. I am getting nowhere…

RUN_WPP in the sources file traverses the list of sources=… entries to generate the appropriate .tmh files for each sources file. Header files are not usually part of the sources list, so I can’t see how the .tmh files are supposed to be generated. Please correct me if I am wrong.

What strikes me is that RUN_WPP has a ‘-ext:’ switch, which at least in theory allows .h files to be passed to tracewpp.exe for processing (internally done by RUN_WPP). This kind of contradicts having no header files in sources… I have tried it by the way, but I could not see any change of behaviour at all when specifying this switch or not.

Any help would be much appreciated.

Christian

OSR_Community_User · July 11, 2007, 9:46am

Hello, Christian -

I had the same problem, being a fan of header libraries. Eventually I gave up and worked around it by placing my own “trace” function declarations in a header that were implemented in a regular .c file. These trace functions can then of course be called from header files. The downside to this approach is that you need a separate trace function wrapper at least for each different parameter list (AFAIK, there is no vDoTraceMessage equivalent).

Best regards,
-Stephen Cleary

OSR_Community_User · July 11, 2007, 1:43pm

You can take a look at msdn

http://msdn2.microsoft.com/en-us/library/ms797198.aspx

How do I generate trace messages from a header file?
To generate trace messages from source files with file name extensions
other than .c, .c++, .cpp, and .cxx, add the -ext parameter to the
RUN_WPP macro that invokes the Windows software trace preprocessor.

For example, to generate traces from .c and .h files, use the following
statement:

RUN_WPP=$(SOURCES) -km -ext:.c.h

The -ext parameter specifies the file types that WPP recognizes as
source files. WPP ignores files with a different file name extension. By
default, WPP recognizes only .c, .c++, .cpp, and .cxx files.

In versions of Windows prior to Windows Vista because the values of this
parameter are case-sensitive, you must list all cases. For example:

RUN_WPP=$(SOURCES) -km -ext:.c.C.h.H

Also, if the header file has the same name as another source file, add
the -preserveext parameter to the RUN_WPP macro. For example:

RUN_WPP=$(SOURCES) -km -ext:.c.C.h.H -preserveext:.c.h

The -preserveext parameter preserves the specified file name extensions
when creating the names of trace message header (.tmh) files. This
parameter prevents WPP from creating multiple TMH files with the same
name. By default, WPP uses only the .tmh file name extension, such as
tracedrv.tmh. With the -preserveext parameter, the files are instead
named tracedrv.c.tmh and tracedrv.h.tmh.

For a complete list of the optional parameters for RUN_WPP, see WPP
Preprocessor

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@brainboxes.com
Sent: Wednesday, July 11, 2007 5:50 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WPP tracing from header files

Hello

We have a C++ driver that needs to generate WPP traces from a
header-file-only class implementation. I am getting nowhere…

RUN_WPP in the sources file traverses the list of sources=… entries to
generate the appropriate .tmh files for each sources file. Header files
are not usually part of the sources list, so I can’t see how the .tmh
files are supposed to be generated. Please correct me if I am wrong.

What strikes me is that RUN_WPP has a ‘-ext:’ switch, which at least in
theory allows .h files to be passed to tracewpp.exe for processing
(internally done by RUN_WPP). This kind of contradicts having no header
files in sources… I have tried it by the way, but I could not see any
change of behaviour at all when specifying this switch or not.

Any help would be much appreciated.

Christian

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

OSR_Community_User · July 11, 2007, 1:45pm

A simple search on msdn could have found the answer.

http://msdn2.microsoft.com/en-us/library/ms797198.aspx

How do I generate trace messages from a header file?
To generate trace messages from source files with file name extensions
other than .c, .c++, .cpp, and .cxx, add the -ext parameter to the
RUN_WPP macro that invokes the Windows software trace preprocessor.

For example, to generate traces from .c and .h files, use the following
statement:

RUN_WPP=$(SOURCES) -km -ext:.c.h

The -ext parameter specifies the file types that WPP recognizes as
source files. WPP ignores files with a different file name extension. By
default, WPP recognizes only .c, .c++, .cpp, and .cxx files.

In versions of Windows prior to Windows Vista because the values of this
parameter are case-sensitive, you must list all cases. For example:

RUN_WPP=-ext:.c.C.h.H $(SOURCES) -km

Also, if the header file has the same name as another source file, add
the -preserveext parameter to the RUN_WPP macro. For example:

RUN_WPP=-ext:.c.C.h.H -preserveext:.c.h $(SOURCES) -km

The -preserveext parameter preserves the specified file name extensions
when creating the names of trace message header (.tmh) files. This
parameter prevents WPP from creating multiple TMH files with the same
name. By default, WPP uses only the .tmh file name extension, such as
tracedrv.tmh. With the -preserveext parameter, the files are instead
named tracedrv.c.tmh and tracedrv.h.tmh.

For a complete list of the optional parameters for RUN_WPP, see WPP
Preprocessor

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, July 11, 2007 6:48 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WPP tracing from header files

Hello, Christian -

I had the same problem, being a fan of header libraries. Eventually I
gave up and worked around it by placing my own “trace” function
declarations in a header that were implemented in a regular .c file.
These trace functions can then of course be called from header files.
The downside to this approach is that you need a separate trace function
wrapper at least for each different parameter list (AFAIK, there is no
vDoTraceMessage equivalent).

Best regards,
-Stephen Cleary

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

Christian_Port · July 12, 2007, 4:46am

Dear Jose Sua

Thank you for your reply, but a simple reading through my initial post would have shown you that I have long ago tried this. I wrote:

“What strikes me is that RUN_WPP has a ‘-ext:’ switch, which at least in theory
allows .h files to be passed to tracewpp.exe for processing (internally done by
RUN_WPP). This kind of contradicts having no header files in sources… I have
tried it by the way, but I could not see any change of behaviour at all when
specifying this switch or not.”

Have you actually tried it yourself at some point in the past? Have you got a cut-down sample sources file you could share with us as a sample? One that actually generates any .tmh files for header files?

Christian

Mark_Roddy · July 12, 2007, 7:24am

xxxxx@brainboxes.com wrote:

Hello

We have a C++ driver that needs to generate WPP traces from a header-file-only class implementation. I am getting nowhere…

RUN_WPP in the sources file traverses the list of sources=… entries to generate the appropriate .tmh files for each sources file. Header files are not usually part of the sources list, so I can’t see how the .tmh files are supposed to be generated. Please correct me if I am wrong.

What strikes me is that RUN_WPP has a ‘-ext:’ switch, which at least in theory allows .h files to be passed to tracewpp.exe for processing (internally done by RUN_WPP). This kind of contradicts having no header files in sources… I have tried it by the way, but I could not see any change of behaviour at all when specifying this switch or not.

Any help would be much appreciated.

The following is probably not much direct help, and is in fact simply my
opinion: ETW ends up being so complicated on both the implementation
side and the user side that after three years of wrestling with its
issues I am gradually coming to the conclusion that “abandon ship” is
the best approach. I’m reverting my run time tracing model to use my own
printf style ringbuffer mechanism (which I use for the debug driver
versions anyway) as it meets all of my requirements and is massively
simple to implement against and use.

I really wish Microsoft would take the same approach and just implement
a large kernel runtime debug print ringbuffer that all driver debug
print messages were copied into in addition to being displayed on the
console, and simple facilities to capture this buffer up in user mode
(for example to spool it off to disk or to view it in real time). KISS
is so operative here.

Peter_Viscarola_OSR · July 12, 2007, 10:01am

I am gradually coming to the conclusion that “abandon ship” is the best approach.

[/quote]

Unfortunately, we’ve come to the same conclusion as Mr. Roddy.

WPP Tracing is one of the few technologies that we here at OSR regret having advocated for. In the long run, it has proven itself to be neither stable nor easy to use, and – to our thinking – adds more complexity than it returns in value.

This is despite Mr. Sua’s work over the past few years, which has been the best thing to happen to WPP tracing since its inception.

So, to concur with Mr. Roddy: We abandoned ship on WPP tracing a while back. We’re sorry this promising technology didn’t turn out like we all hoped. We can’t pick winners ever time.

Peter
OSR

Don_Burn_1 · July 12, 2007, 11:02am

wrote in message news:xxxxx@ntdev…
>
> I am gradually coming to the conclusion that “abandon ship” is the best
> approach.
>
[/quote]

>
> Unfortunately, we’ve come to the same conclusion as Mr. Roddy.
>
> WPP Tracing is one of the few technologies that we here at OSR regret
> having advocated for. In the long run, it has proven itself to be
> neither stable nor easy to use, and – to our thinking – adds more
> complexity than it returns in value.
>
> This is despite Mr. Sua’s work over the past few years, which has been
> the best thing to happen to WPP tracing since its inception.
>
> So, to concur with Mr. Roddy: We abandoned ship on WPP tracing a while
> back. We’re sorry this promising technology didn’t turn out like we all
> hoped. We can’t pick winners ever time.
>

I’m still using it, I’m wondering if you and Mr Roddy can be more explicit
on the problems that drove you to abandoning WPP? I know parts of it are
wonky, but I really am curious since I still push it to my customers and do
not want to walk into a problem if I can avoid it. Also, if you explain
the problems, maybe Microsoft can provide a solution or someone can suggest
a workaround.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

OSR_Community_User · July 12, 2007, 11:07am

You need to tell WPP which header files to generate TMH files for.

Like

RUN_WPP=-ext:.c.cpp.h -preserveext:.h $(SOURCES) headerfile1.h
haderffile2.h

The line will generate headerfile1.h.tmh and headerfile2.h.tmh

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@brainboxes.com
Sent: Thursday, July 12, 2007 1:47 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WPP tracing from header files

Dear Jose Sua

Thank you for your reply, but a simple reading through my initial post
would have shown you that I have long ago tried this. I wrote:

“What strikes me is that RUN_WPP has a ‘-ext:’ switch, which at least in
theory
allows .h files to be passed to tracewpp.exe for processing (internally
done by
RUN_WPP). This kind of contradicts having no header files in sources…
I have
tried it by the way, but I could not see any change of behaviour at all
when
specifying this switch or not.”

Have you actually tried it yourself at some point in the past? Have you
got a cut-down sample sources file you could share with us as a sample?
One that actually generates any .tmh files for header files?

Christian

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

OSR_Community_User · July 12, 2007, 1:06pm

Well for example this latest ETW thread. Supporting libraries is a
nightmare, getting trace information out of a system dump is a
nightmare, doing anything other than very simple things takes you into a
morass of scattered documentation, obscure implementation details, odd
syntax stuff. Looking at traces is always fun too.

All I want is a kernel debug print trace that I can rely on fetching out
of a crash dump. It is a very simple concept.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Thursday, July 12, 2007 11:02 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WPP tracing from header files

wrote in message news:xxxxx@ntdev…
>
> I am gradually coming to the conclusion that “abandon ship” is the
best
> approach.
>
[/quote]

>
> Unfortunately, we’ve come to the same conclusion as Mr. Roddy.
>
> WPP Tracing is one of the few technologies that we here at OSR regret
> having advocated for. In the long run, it has proven itself to be
> neither stable nor easy to use, and – to our thinking – adds more
> complexity than it returns in value.
>
> This is despite Mr. Sua’s work over the past few years, which has been

> the best thing to happen to WPP tracing since its inception.
>
> So, to concur with Mr. Roddy: We abandoned ship on WPP tracing a while

> back. We’re sorry this promising technology didn’t turn out like we
all
> hoped. We can’t pick winners ever time.
>

I’m still using it, I’m wondering if you and Mr Roddy can be more
explicit
on the problems that drove you to abandoning WPP? I know parts of it
are
wonky, but I really am curious since I still push it to my customers and
do
not want to walk into a problem if I can avoid it. Also, if you explain

the problems, maybe Microsoft can provide a solution or someone can
suggest
a workaround.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

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

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

OSR_Community_User · July 12, 2007, 1:26pm

Would it help if there were more samples in the WDK/SDK?

-lib sample
-distinct format strings
-own notification callback
-distinct scenarios

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Thursday, July 12, 2007 10:06 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WPP tracing from header files

Well for example this latest ETW thread. Supporting libraries is a
nightmare, getting trace information out of a system dump is a
nightmare, doing anything other than very simple things takes you into a
morass of scattered documentation, obscure implementation details, odd
syntax stuff. Looking at traces is always fun too.

All I want is a kernel debug print trace that I can rely on fetching out
of a crash dump. It is a very simple concept.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Thursday, July 12, 2007 11:02 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WPP tracing from header files

wrote in message news:xxxxx@ntdev…
>
> I am gradually coming to the conclusion that “abandon ship” is the
best
> approach.
>
[/quote]

>
> Unfortunately, we’ve come to the same conclusion as Mr. Roddy.
>
> WPP Tracing is one of the few technologies that we here at OSR regret
> having advocated for. In the long run, it has proven itself to be
> neither stable nor easy to use, and – to our thinking – adds more
> complexity than it returns in value.
>
> This is despite Mr. Sua’s work over the past few years, which has been

> the best thing to happen to WPP tracing since its inception.
>
> So, to concur with Mr. Roddy: We abandoned ship on WPP tracing a while

> back. We’re sorry this promising technology didn’t turn out like we
all
> hoped. We can’t pick winners ever time.
>

I’m still using it, I’m wondering if you and Mr Roddy can be more
explicit
on the problems that drove you to abandoning WPP? I know parts of it
are
wonky, but I really am curious since I still push it to my customers and
do
not want to walk into a problem if I can avoid it. Also, if you explain

the problems, maybe Microsoft can provide a solution or someone can
suggest
a workaround.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

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

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

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

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

Maxim_S_Shatskih · July 12, 2007, 1:50pm

> issues I am gradually coming to the conclusion that “abandon ship” is

the best approach.

WPP/ETW was always too complex for me. a) supporting WMI in the driver b)
preprocessing the sources c) the logged info is binary and not human-readable.

The usual Windows event log (which is conceptually similar a bit to WPP/ETW but
does not require preprocessing) and KdPrint are fine for all my scenarios.

P.S. Jose does the great job here on forum.

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

Michal_Vodicka-2 · July 12, 2007, 2:22pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Roddy, Mark[SMTP:xxxxx@stratus.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, July 12, 2007 7:05 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WPP tracing from header files

All I want is a kernel debug print trace that I can rely on fetching out
of a crash dump. It is a very simple concept.

Exactly. All you need is few smart macros a way how to control traces (registry settings…) and a good tool to capture traces. DebugView with its 20 highlight filters is great and it is able to get its buffer from crashdump. What advantages ETW offers? Smaller binary size. Who cares. Traces invisible to users. Again, who cares and it can be more disadvantage than advantage. Better performance. It is a myth as I already showed few months before when measured real times.

I’m sorry to Jose but I hope this technique will be abandoned. Previously, when I had a problem with OS drivers, I could install checked binaries, find some variables and change them to enable debug prints. With ETW I can’t get the same info because don’t have necessary format strings.

So what about a change? Leave the monster alone and develop new, lightweight version? DbgPrint() is with few macros around and a standard way how to control traces levels and areas would be quite sufficient. (not DbgPrintEx() isn’t). We did it years before, have company wide standartized tracing facility for all platforms we use and everybody is quite happy with it. New developers are able to use it within minutes and there is no need for anything special; pure C and C++ and registry or some equivallent on non-Windows platforms. I ported it to several platforms and the key principle is KISS. Port itself may be hard but the usage has to be simple and straightforward otherwise nobody will use it. That’s why (IMO) ETW wasn’t accepted; at least in my case. It always discouraged me and more I read about it here, more I’m glad.

Isn’t there already a precedent in user mode? MFC versus WTL. At least my coworkers said something like this; I don’t write apps with GUI

Best regards,

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

Don_Burn_1 · July 12, 2007, 2:52pm

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
>
> All I want is a kernel debug print trace that I can rely on fetching out
> of a crash dump. It is a very simple concept.
>
Exactly. All you need is few smart macros a way how to control traces
(registry settings…) and a good tool to capture traces. DebugView with
its 20 highlight filters is great and it is able to get its buffer from
crashdump. What advantages ETW offers? Smaller binary size. Who cares.
Traces invisible to users. Again, who cares and it can be more disadvantage
than advantage. Better performance. It is a myth as I already showed few
months before when measured real times.

I have to dispute the statement about Traces invisible to the user. THAT
IS ONE I CARE A LOT ABOUT!!! The number of times my customers have
demanded that I remove all tracing, then call me with “the driver does not
work something is going wrong fix it” is amazing. Maybe my customers are
just paranoid, but they do not want DebugPrint’s in their drivers, even if
they are turned off by default. The amount of time, I wasted (in some
cases unbillable) to get enough data to figure out what was going wrong was
terrible. This is why I still am a big supporter of WPP tracing.

I agree with Mark Roddy that about WPP in crash dumps, and for the most
part I don’t even try to get the WPP data, and that is a problem! I also
agree that preprocessor is flaky which is annoying, since it limits
serverly what one can do.

There have been problems with back rev support, I was not happy that with
the WKD things changed, and no way was provided to support the older model.
Personally I thought that stunk, and closing the bug reports I filed with
“NOT REPRODUCABLE” was a crock.

But, within a tiny subset of WPP tracing I find it a useful tool.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

Maxim_S_Shatskih · July 12, 2007, 3:11pm

>So what about a change? Leave the monster alone and develop new,

lightweight version? DbgPrint() is with few macros around and a standard way

Windows event log is also good for tracing, especially if detail level is
controlled by the registry value.

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

Don_Burn_1 · July 12, 2007, 3:20pm

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> >So what about a change? Leave the monster alone and develop new,
>>lightweight version? DbgPrint() is with few macros around and a standard
>>way
>
> Windows event log is also good for tracing, especially if detail level is
> controlled by the registry value.
>
Max,

I have suggested to people who worked for me who used the event log
for tracing that they probably should look for another occupation like
walking dogs! I told the person in question they had better have it all
ripped out within 24 hours if they wanted to be employed. If there is
something, that will piss off any system administrator I know and respect
it is putting tons of crap in the event log! That does not even consider
the fact the with the limited size of events, and the limited IRQL it can
work at it does not solve the problem.

Sorry but using the event log for tracing falls into the same category
as hooking all the system calls and replacing thing like spin locks with
your own code, something beyond stupid.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

Michal_Vodicka-2 · July 12, 2007, 3:23pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Don Burn[SMTP:xxxxx@acm.org]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, July 12, 2007 8:51 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WPP tracing from header files

I have to dispute the statement about Traces invisible to the user. THAT
IS ONE I CARE A LOT ABOUT!!!

OK, let’s change “who cares” to “Don cares” Anybody else?

The number of times my customers have
demanded that I remove all tracing, then call me with “the driver does not
work something is going wrong fix it” is amazing. Maybe my customers are
just paranoid, but they do not want DebugPrint’s in their drivers, even if
they are turned off by default.

I don’t advocate to have debug prints in released drivers even when turned off. Our customers usually report problem and we send them debug version of driver with traces and INF which sets trace settings in the registry as I need. Customer reproduces problem, send us traces or crashdump from where traces can be extracted (the best case).

The amount of time, I wasted (in some
cases unbillable) to get enough data to figure out what was going wrong was
terrible. This is why I still am a big supporter of WPP tracing.

Well, I guess we already had this discussion in the past. You have different kind of customers. WPP principle isn’t so bad (except of OS drivers problems which’d be solvable) but the implementation is the problem.

I agree with Mark Roddy that about WPP in crash dumps, and for the most
part I don’t even try to get the WPP data, and that is a problem!

This surprised me. I expected at least this part works. Extracting debug prints from a crashdump is quite standard approach, at least for me.

I also agree that preprocessor is flaky which is annoying, since it limits
serverly what one can do.

And there is no real need for it…

Best regards,

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

Maxim_S_Shatskih · July 12, 2007, 3:26pm

> I have suggested to people who worked for me who used the event log

for tracing that they probably should look for another occupation like
walking dogs! I told the person in question they had better have it all
ripped out within 24 hours if they wanted to be employed. If there is
something, that will piss off any system administrator I know and respect
it is putting tons of crap in the event log!

Any severe things like assertion failures are great candidates for event
log tracing. In the normal case, they will not appear at all :-), and thus will
not bother the admin.
Any “success” traces to the event log should be controlled by the registry
value, which should be “disable all” by default, and turned on only to repro
some issue on the customer site.

With these 2 rules, event log tracing is rather good idea.

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

Maxim_S_Shatskih · July 12, 2007, 3:30pm

>customers. WPP principle isn’t so bad (except of OS drivers problems which’d

be solvable) but the implementation is the problem.

Yes, the need in preprocessor is the worst part.

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

Michal_Vodicka-2 · July 12, 2007, 3:34pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, July 12, 2007 9:11 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WPP tracing from header files

>So what about a change? Leave the monster alone and develop new,
>lightweight version? DbgPrint() is with few macros around and a standard way

Windows event log is also good for tracing, especially if detail level is
controlled by the registry value.

No, I disagree. Event log has different purpose and this looks like a misuse. I don’t know about you but I sometimes have hundreds MB or even GB of traces until a problem is reproduced. Our customers like to run long stress tests and complain if it fails once per week

Also, I’d bet performance would be influenced much more with event log. Though, I haven’t measured and could be surprised.

But the idea itself isn’t so bad. It’d be nice if Windows supports standard way to capture and save DbgPrint output. Something like built-in DebugView which’d save text (!) output to a file when enabled by a registry values. And as with DebugView, the buffer would be extractable from crashdump.

Best regards,

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