ETW EtwRegister() provider list
in [Win32 Kernel]
|
From: Ivan Brugiolo [MSFT] on 23 Nov 2009 11:53 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" <tpblists(a)terranovum.com> wrote in message news:OVjOkf1aKHA.5544(a)TK2MSFTNGP02.phx.gbl... > 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 >>> ); >>
From: Thomas Bolioli on 1 Dec 2009 10:56
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. Ivan Brugiolo [MSFT] wrote: > 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 > > |