ETW EtwRegister() provider list

[Thomas Bolioli]

Where does one find the provider list to get the correct provider ID for
tracing? It isn't obvious from the API docs and there are scant examples
online.

BTW: The whole point of this exercise is to detect various system
messages running in applications and trace back what app called that
message. Additionally, we would look for various events, like spikes in
disk activity, cpu util, etc and try to trace what app is causing it.
Does this sound like something ETW can accomplish???

EtwRegister(
__in LPCGUID ProviderId,
__in_opt ETWENABLECALLBACK EnableCallback,
__in_opt PVOID CallbackContext,
__out PREGHANDLE RegHandle
);

[Ivan Brugiolo [MSFT]]

-1- Provider list
c:\>logman.exe query providers

-2-
Etw tracing is the most comprehensive and fundamental tool for analyzing
complex performance issues across components and processes.

Normally, the workflow is:
-1- Create an tracing session with all the providers that you think are
relevant to your problem. Typically, you will have the kernel provider
with thread/process/module-load and context-switch, to trace basic CPU
activity
and how it binds to other logical activities. Other providers may be needed.
-2- run your scenario
-3- stop the tracing session
-4- analyze the tracing session

The API you mention below implies you want to register an Etw-Classic
provider, in order to add your own events to a tracing session.
That may not be needed, since there are already hundreds of providers in the
OS
for almost anything meaningful.

Here is an example of the whole process for, let's say,
DirectX applications presenting to screen in Win7.

REM start tracing sessions
C:\>logman.exe start "NT Kernel Logger"
-p {9e814aad-3204-11d2-9a82-006008a86939} 0x17 0xFF
-ets -o Kernel.etl
C:\>logman.exe start DwmTrace -pf guids.txt -ets -o Dwm_DX_Win32k.etl

REM run your code/scenario here

REM stop tracing sessions
C:\>logman.exe stop "NT Kernel Logger" -ets
C:\>logman.exe stop DwmTrace -ets
C:\>xperf.exe -merge kernel.etl Dwm_DX_Win32.etl merged.etl
REM transform the tracing session to a human readable file
C:\>tracerpt.exe merged.etl -o merged.xml

-- guids.txt --
{e7ef96be-969f-414f-97d7-3ddb7b558ccc} 0x1000 0x6
{8C9DD1AD-E6E5-4B07-B455-684A9D879900} 0xFFFFFFFF 0x6
{65cd4c8a-0848-4583-92a0-31c0fbaf00c0} 0xFFFF 0x5

[xperf.exe is part of the WPA toolkit that you can download]
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Thomas Bolioli" <tpbl...@terranovum.com> wrote in message
news:Oin7cysa...@TK2MSFTNGP06.phx.gbl...

[Pavel A.]

Have you seen Xperf?
http://blogs.msdn.com/pigscanfly/archive/2008/02/24/xperf-support-for-xp.aspx

--pa

"Thomas Bolioli" <tpbl...@terranovum.com> wrote in message
news:Oin7cysa...@TK2MSFTNGP06.phx.gbl...

[Thomas Bolioli]

Yes. But this is for long term monitoring of a very specific set of
conditions not often likely to occur. We need this to be an installable
application that someone with no expert knowledge installs. Not
directions for folks like us to use. So the thing that xperf is based
on, etw, is what I need. The problem is I am not sure how well this will
work for long term monitoring. xperf dumps a metric ton of data to sift
through. I want to only turn on specific things to keep the data flow
rate at a minimum. In parlance, I want to set a handful of squibs and
then even filter the data that they provide down even further.
Tom

[Thomas Bolioli]

Thanks, this is a great start. The provider list will help me to winnow
down what I need.

BTW: This is for long term monitoring of a very specific set of
conditions not often likely to occur. I am not debugging code we wrote,
so we are using etw in a way not directly assumed in the docs. We need

this to be an installable application that someone with no expert

knowledge installs. It is monitoring drivers and applications we did not
write. So xperf/logman out of the box is not going to work but I assume
EtwRegister() will correspond to #1 in your direction set.

One problem is I am not sure how well this will work for long term
monitoring. xperf.exe dumps a metric ton of data to sift through. I want

to only turn on specific things to keep the data flow rate at a minimum.
In parlance, I want to set a handful of squibs and then even filter the

data that they provide down even further to target specific conditions.
Typical use of xperf is to dump a ton of data for short periods of time.

[Ivan Brugiolo [MSFT]]

While xperf.exe is not in-box, the usage (in the sample provided below)
is limited to merging ETL files, that you can chose not to do, if you parse
the files independently.
logman.exe is included ever since Win2003, if memory serves well.

In general, for your problem, I would set-up an AutoLogger tracing session,
with the minimal set of providers and with keyword-based filtering
and verbosity level filtering.

The AutoLogger session is likely to be set-up with a fixed size
file and in circular mode, so that you don't run out of disk space
while you are monitoring.

You can set-up a real-time event-consumer, but, your mileage may vary.
It might be too verbose, and, the logic that you have to build in the
consumer
may be more complex than having a convenient *.ETL file
that can be e-mailed to you for off-line processing.

Once you have ant ETL file, you can write a OpenTrace/ProcessTrace
application
that gets a callback on each and every ETW event that has been collected.

Most of the features mentioned here assume you have a Vista+ machine.
Here is an example of an autologger session.
There are other autologger sessions in a Vista+ machine already there by
default.

---------------- works in Win7/WS08-R2
REM
REM Create an Auto-Logger session 2 Megs, Circular, with two providers at
the appropriate level
REM
tracelog.exe -addautologger DwmDiag -sessionguid
#7a341136-3e6c-4f30-948d-b83b1e703bf5 -guid tracelog_guid.txt -f
%windir%\temp\DwmDiag.etl -cir 2
reg add
"HKLM\System\CurrentControlSet\Control\WMI\AutoLogger\DwmDiag\{8C9DD1AD-E6E5-4B07-B455-684A9D879900}"
/v EnableLevel /t REG_DWORD /d 0x6 /f
reg add
"HKLM\System\CurrentControlSet\Control\WMI\AutoLogger\DwmDiag\{8C9DD1AD-E6E5-4B07-B455-684A9D879900}"
/v MatchAnyKeyword /t REG_QWORD /d 0xFFFFFFFF /f
reg add
"HKLM\System\CurrentControlSet\Control\WMI\AutoLogger\DwmDiag\{E7EF96BE-969F-414F-97D7-3DDB7B558CCC}"
/v EnableLevel /t REG_DWORD /d 0x6 /f
reg add
"HKLM\System\CurrentControlSet\Control\WMI\AutoLogger\DwmDiag\{E7EF96BE-969F-414F-97D7-3DDB7B558CCC}"
/v MatchAnyKeyword /t REG_QWORD /d 0x1000 /f
REM
REM create a session that will have the same name, untill the machine is
rebooted
REM
tracelog.exe -start DwmDiag -f %windir%\temp\DwmDiag.etl -cir 2
tracelog.exe -enableex DwmDiag -guid
#8C9DD1AD-E6E5-4B07-B455-684A9D879900 -matchanykw 0xFFFFFFFF -level 0x6
tracelog.exe -enableex DwmDiag -guid
#E7EF96BE-969F-414F-97D7-3DDB7B558CCC -matchanykw 0x1000 -level 0x6
REM
REM make sure everything is OK
REM
tracelog.exe -q DwmDiag -lp

//--------------BEGIN: tracelog_guid.txt
8C9DD1AD-E6E5-4B07-B455-684A9D879900
E7EF96BE-969F-414F-97D7-3DDB7B558CCC
//--------------END: tracelog_guid.txt

--

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Thomas Bolioli" <tpbl...@terranovum.com> wrote in message

news:OVjOkf1a...@TK2MSFTNGP02.phx.gbl...

[Thomas Bolioli]

So you are suggesting I call external apps (logman.exe) to do the actual
logging and not use the Etw*() functions here
http://msdn.microsoft.com/en-us/library/aa468730.aspx to set the active
providers (squibs)?

Then I either parse the log files on my own or If I wanted to use xperf
I would just need to have it installed with the app.

Maybe I am not understanding this well, it looks like the Etw*() set of
functions allows an application to set/activate the squib and then you
register the call back to extract the data from said squib. As an aside,
I am having issues following how to set the callback and what info comes
into it. Anyhow, you can filter the data in that call back to ensure you
ignore extraneous info and then when a particular event occurs you can
trace that back to the source and log that info, correct?

We can not have the data emailed to us. We need the end consumer to get
actionable info from our app. So the etl file in the mail option is not
there.