ETW EtwRegister() provider list
in [Win32 Kernel]
|
From: Thomas Bolioli on 21 Nov 2009 12:03 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 );
From: Ivan Brugiolo [MSFT] on 21 Nov 2009 13:34 -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" <tpblists(a)terranovum.com> wrote in message news:Oin7cysaKHA.1596(a)TK2MSFTNGP06.phx.gbl... > 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 > );
From: Pavel A. on 21 Nov 2009 20:28 Have you seen Xperf? http://blogs.msdn.com/pigscanfly/archive/2008/02/24/xperf-support-for-xp.aspx --pa "Thomas Bolioli" <tpblists(a)terranovum.com> wrote in message news:Oin7cysaKHA.1596(a)TK2MSFTNGP06.phx.gbl... > 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 > );
From: Thomas Bolioli on 22 Nov 2009 04:21 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 Pavel A. wrote: > Have you seen Xperf? > http://blogs.msdn.com/pigscanfly/archive/2008/02/24/xperf-support-for-xp.aspx > > > --pa > > > "Thomas Bolioli" <tpblists(a)terranovum.com> wrote in message > news:Oin7cysaKHA.1596(a)TK2MSFTNGP06.phx.gbl... >> 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 >> ); >
From: Thomas Bolioli on 22 Nov 2009 04:40
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] wrote: > -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" <tpblists(a)terranovum.com> wrote in message > news:Oin7cysaKHA.1596(a)TK2MSFTNGP06.phx.gbl... >> 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 >> ); > |