If any of you have tried to run PerfView a Surface or other WinRT device, you will find that it does not work. Basically any program that is NOT a windows store application needs to be signed with a special key or it simply will fail to run on a ‘locked’ device (most devices are locked). At some point PerfView might be signed in this way, but at present it is not.
This blog is about working around this problem when you want to do a performance investigation on a Windows RT device (e.g. Surface). Currently your options are
- Do your investigation on an X86 machines: This is what I recommend most of the time. Generally speaking performance issues are not going to be THAT different on the two architectures (they will be the same issues, just more pronounced on ARM). This is also likely to be easier logistically, so I recommend this to start with.
- Use a command line tool that ships with the Windows Performance toolkit called WPR (windows Performance Recorder) to collect the data. The WPR.exe tool is signed to work on Windows RT, and can collect any ETW data that PerfView can collect. Moreover collectint data with WPR is pretty straightforward, as you will see.
Getting WPR for Windows RT
Any easy way to get WPR is to simply download the Windows App Certification Kit. The download is small and takes 10-20 seconds. After installation the WPR.exe tool will live in at the path
“c:\Program Files\Windows Kits\8.0\Windows Performance ToolKit\wpr.exe”
Note that if you wish to do further investigations on other WinRT devices you don’t actually need to download/reintall the Windows App Certification Kit. WPR.exe is XCOPY depoyable, so you could simply copy the directory to a USB drive / cloud drive, transfer to the target machine and run it from where you copied it
xcopy “c:\Program Files\Windows Kits\8.0\Windows Performance ToolKit” d:\WPR\
d:\WPR\Wpr.exe command line parameters discussed below…
Using WPR to collect ETW data
WPR is a command line tool for collecting ETW data. It was designed for ‘flight recorder’ style recording, where you keep a circular buffer going, and when interesting events happen, you take a snapshot. It has three basic commands
- Start – starts collecting (to a in memory circular memory log)
- Stop – dumps the in memory log to a file, does NOT stop collection
- Cancel – stops collection.
- WPR -start GeneralProfile
- <Do your scenario>
- WPR -stop OUTPUTFILE.ETL
- WPR -cancel
The first command starts the logging, and the 3rd command dumps what is in the memory log and stops logging. These commands need to be done from a administrator window, so
- type the Windows-R key combination and type ‘cmd’ to launch a CMD window
- open an elevated command window (right click on the task-bar icon right click on ‘Command Prompt’ and then select ‘Run as Administrator’)
- run the commands above
Please don’t forget the WPR -cancel command! If you forget this command everything will seem to work, however WPR has left collection running. This will slow your machine down by 10% or so but perhaps more importantly, it will use up 100s of meg of memory in its circular buffer, making apps die more frequently to free us space.
Using ETW data to Collect PerfView-Style Data
The instructions use the ‘GeneralProfile’ which does not collect any .NET specific events (it does include the Thread Time events). This is fine if your code has no JIT compiled code in it. For Windows Store application that have been on the machine a while (so that the OS has had a chance to precompile (NGEN) your application, this data is OK. However you have just installed or updated the application, or if you want to understand more about the .NET GC (that is you want the ‘GCStats’ view), or if you want the ‘with Tasks’ view which stitches together async operations, you need more events.
To get this, download the DotNetRuntimeProfile.wprp file at the end of this blog entry and then change the collection start command to
- WPR -start DotNetRntimeProfile.wprp
This will tell WPR to collect most of the events that PerfView collects by default (along with the /ThreadTIme events that WPR would have normally collected anyway) The rest of the procedure (WPR -stop OUTPUTFILE.etl and WPR -cancel) is the same as before.
Uploading your ETW data
The output of the WPR commands will be the ‘OUTPUTFILE.ETL’ but it will also be a set of PDB files for precompiled (NGENed) .NET assemblies. These NGEN pdbs are needed to properly decode .NET Framework code as well as some application code. WPR places these PDBS in a directory called OUTPUTFILE.NGENPDBS
Thus to upload the data to a USB drive you might do
- Xcopy OUTPUTFILE.ETL d:\
- Xcopy OUTPUTFILE.NGENPDBS d:\OUTPUTFILE.NGENPDBS\
You can also ZIP them so that they are a single file for easier upload . Simply open windows explorer, select the OUTPUTFILE.ETL and OUTPUTFILE.NGENPDB files, right click and select SendTo -> Compressed (Zip) folder. When it is done it will allow you to rename it, name it OUTPUTFILE.ETLl (it will put the ZIP suffix on automatically). The resulting .etl.zip file can be copied to another machine and opened with PerfView directly (PerfView will automatically unpack things into the proper places).
Once you the data (either as two pieces or as a ZIP file) to an X86 machine, you can use PerfView to open the OUTPUTFILE.ETL or OUTPUTFILE.ETL.ZIP file (it knows to find the PDBS in the OUTPUTFILE.NGENPDBS directory in either case). You are also welcome to use the WPA tool that comes with the Windows Performance toolkit to look at the ETW data (but for that you do have to unzip the .ETL.ZIP file). From this point it is just like you collected the data with PerfView.