Version 1.8 of PerfView is now on the Download Center

 This is to let you know that the PerfView Download Site has been updated to version 1.8 today.   The pervious version (1.7) id about 10 months old, so this one has 10 months of updates.   Some of the highlights in that time are show below.  

The most important aspects of this version are that it supports various changes for Win 10 (if you use an older version of PerfView on Win10 (or Win10 profiles), you may encounter various deficiencies.    In addition to the win10 updates here are some of the other highlights. 

• Support for opening VS2015 .DiagSession files
• Suppport for new Self-describing ETW format.
• Ability to look display the size of a IL DLL or EXE as a Heap in the viewer to understand why it is as big as it is
• Support for resolving types and GC dumps for .NET Native executables.
• Support for new symbol server format
• Fixed issues displaying numbers HTML in non-english locals.
• Support for showing the size of disk for a Directory in the stack viewer. 
• Added IIS checkbox to make collecting traces with detailed IIS information easy. 
• Overweight Analysis for determining why two traces differ quickly.  
• Support for EventSource V4.6 causality Tracking
• Ability to capture every .NET Call being made (see .Net Calls in collection dialog)

You can see the 'Help->Release notes' for more details on some of these.  

I will be bloggoing about some of the new features shortly, so stay tuned. 

Vance

Comments

• Anonymous
  September 03, 2015
  Thanks a lot for the update! The localization issues are now gone :)

• Anonymous
  September 13, 2015
  Thanks for the update! I cannot see any Microsoft-Windows-DotNETRuntimeRundown/Method/DCStopVerbose Events in Raw Event Viewer.  Other events show up just fine. Event Stats Report indicates that these events are being generated (See below).   Microsoft-Windows-DotNETRuntimeRundown/Method/DCStopVerbose 50,076 325 0 Microsoft-Windows-DotNETRuntimeRundown/Method/DCStartVerbose 35,409 316 0 Microsoft-Windows-DotNETRuntimeRundown/Loader/ModuleDCStop 797 630 0 Microsoft-Windows-DotNETRuntimeRundown/Loader/AssemblyDCStop 795 227 0 The Event Type Entry even appears in the EventTypes list in Raw Event viewer. I have tried this a couple of times and see consistent behavior. Does anyone else have the same problem?

• Anonymous
  September 13, 2015
  This is actually a feature.     PerfView has the notion of a 'bookkeeping' event that is not a 'real' event (it does not indicate that something happened at a particular time), but is basically 'additional information' needed to interpret other events.  These are 'rundown' (DC or Data Collection Stop).   These include method rundown, as well as stand alone stack events, and a few others.   The key is that the information in these events are displayed some 'better' way (e.g. PerfView has the illusion of attaching the stack events to event associated with the stack).   Generally they simply get in the way once their information has been attached to other events and use up a lot of space.    Thus by default PerfView excludes them.   However you can get at them by using the /KeepAllEvents option when you start PerfView.   Note that these events are discarded when a ETL file is first converted into an internal ETLX file, so you should od the File -> Clear Temp Files, or touch the ETL file so that PerfView will be forced to re-read the original ETL file and process.    Mostly this is only useful for people like myself who actually need to debug PerfView logic.  

• Anonymous
  October 23, 2015
  The comment has been removed

• Anonymous
  October 23, 2015
  As you noticed, PerfView does create temporary files (in %Temp%PerfView and they can be big).   PerfView keeps these around because it can avoid a lot of work in common cases if users open the same files.    By default it will throw out files older that 5 days.    You can clear the temp file explicitly by using File -> Clear Temp FIles, and you can delete the %temp%PerfView directory at any time and PerfView will not care (it truly is a cache things that remember other persisted data (e.g. setting) are stored elsewhere.  

• Anonymous
  October 23, 2015
  Thanks Vance. So it looks like files are only created in %Temp%PerfView for analysis but not collection, correct?

• Anonymous
  October 23, 2015
  That is correct.   The %temp% directory is only for CACHED files (I can throw them away without loss because they can be recreated).   Thus these files are an implementation detail.   Collected data however not cache, and thus go where you ask them to be put (they are part of the semantic model)

• Anonymous
  November 09, 2015
  The comment has been removed

• Anonymous
  November 09, 2015
  It certainly seems like a bug.    First:  What operating system did you COLLECT the data on?    Most likely it is an older version of windows.   Please try running the V1.6 and V1.7 version of PerfView (available at http://1drv.ms/1NHA1HB in the OldPerfviewVersion directory),   There is a good chance that one of these will work, which will give you at least a work-around.  

• Anonymous
  November 10, 2015
  The comment has been removed

• Anonymous
  November 10, 2015
  There has been another report that fits your description (merging not working on Win2008).   I believe that using the V1.6 version of PerfView will work for you.   There is a limitation with the OS Heap provider as you have learned.   It is a limitation in the OS.   BufferSize does not affect file size (only how much member to capture bursts of events).   Thus the only way to avoid very large sizes when using OS heap is to limit the time.    

• Anonymous
  November 19, 2015
  To limit the OS heap ETL size, my script now starts PerfView without the -OSHeapProcess option. But once my script sees that private bytes have increased beyond a threshold, it start PerfView again with the -OSHeapProcess option and allows collection to continue for 20 seconds after which my script stops collection. The problem is that now the resulting trace starts at the second "PerfView start" and I believe all data from the first "Perfview start" up to the second "PerfView start" is lost. Is there a way to add OS heap collection for a PID to an existing PerfView collection session? Thanks

• Anonymous
  November 19, 2015
  The comment has been removed

• Anonymous
  November 19, 2015
  I attempted to modify the script to use the /merge:false method but it would have required a lot of changes. Instead, I used xperf.exe to start a new heap session called "PerfViewSessionHeap" which starts this new heap session and leaves the original "PerfViewSession" untouched. "PerfView stop" then stops both PerfView* sessions (and the NT Kernel Logger session) and then merges all three .etl files just as before. The nice thing is the original "PerfView start" with the "-zip" option continues to do the right thing which is to zip up all three .etl files. Is it safe to assume the "PerfView stop" stops all etw sessions whose logger name is prefixed with "PerfViewSession"? And that it will merge/zip all the .etl files that have the same basename? Thanks

• Anonymous
  November 20, 2015
  PerfView stop does not stop any session that begins with 'PerfView' but DOES stop any session that it MAY have started (thus because under some circumstances it starts a session called PerfViewSessionHeap it attempt to stop that session on stop).     It also merges any files that match the patterns  mentioned above (which is a bit more selective than anything with the same basename).   But your basic strategy is sound.  If you start a session with XPERF or other tool and name things correctly like what you suggest it should work. While I am glad it enables your scenario, this technique is relying on internal details of PerfView that are not guaranteed from version to version.   It is fine for a one-off collection, but if you wire it into something more permanent, it is your responsibility to unbreak it if future version change those details.  

• Anonymous
  November 20, 2015
  OK and thanks for your responses and thanks for developing PerfView!

• Anonymous
  December 06, 2015
  > It certainly seems like a bug. We also are experiencing this bug. Unfortunately the traces from our customers are not very useful because of it. Any chance it will be fixed in the next PerfView releases? You can find our PerfViewLogFile.txt for problematic traces here: www.dropbox.com/.../PerfViewLogFile.txt Thank you.

• Anonymous
  December 06, 2015
  It is not completely clear what issue you are running into.  I am assuming you are describing the bug where merging does not happen properly on older OS systems.   If so, did the work-around of using PerfView 1.6 work?   Fixing this is issue is on the list for Version 1.9 of PerfView, but there is no plan to rush this release since there is a work around.  

• Anonymous
  December 07, 2015
  You should also try the version of PerfView.exe in the PerfView.zip on my one drive http://1drv.ms/1NHA1HB.   This has a fix that seems to resolve the issue.   It would be useful to determine if it fixes your case as well.

• Anonymous
  December 07, 2015
  Yes, I'm describing the bug about merging. Thank you very much for the version of PerfView with probably fixed bug. Unfortunately I cannot check it right now because the problem was reproduced on the system of our customer and we already closed their case and I cannot ask them to try perfview again. But I hope if someone (maybe me again) will run into to it again they will find this discussion and report results. Thank you again.

• Anonymous
  December 08, 2015
  The comment has been removed

• Anonymous
  December 08, 2015
  The best way to do this is the following Collect with PerfView normally (will create a ETL.ZIP file). You CAN use the /WPR option, but if you do you should /ZIP option as well (the default when /WPR is present is to not zip).  Generally you can read files created with default PerfView parameters with WPA without issue, but if you use /WPR then you will get a slightly different set of events, and it may affect some more advanced views of WPA.   You can copy the file anywhere.   When you want to view with WPA, simply type PerfView unzip /wpr FILENAME Which will unzip the data in the way WPA wants..

• Anonymous
  January 20, 2016
  Hi Vance, PerfView crashes if I search something like "folderEfile" in Events window: StackTrace: System.ArgumentException: parsing "folderEfile" - Unrecognized escape sequence E.   at System.Text.RegularExpressions.RegexParser.ScanCharEscape()   at System.Text.RegularExpressions.RegexParser.ScanBasicBackslash()   at System.Text.RegularExpressions.RegexParser.ScanBackslash()   at System.Text.RegularExpressions.RegexParser.ScanRegex()   at System.Text.RegularExpressions.RegexParser.Parse(String re, RegexOptions op)   at System.Text.RegularExpressions.Regex..ctor(String pattern, RegexOptions options, TimeSpan matchTimeout, Boolean useCache)   at System.Text.RegularExpressions.Regex..ctor(String pattern, RegexOptions options)   at PerfView.EventWindow.Find(String pat)   at PerfView.EventWindow.DoFindNext(Object sender, RoutedEventArgs e)   at PerfView.EventWindow.DoFindEnter(Object sender, RoutedEventArgs e)   at Controls.HistoryComboBox.FireEnter(Object sender, RoutedEventArgs e)

• Anonymous
  January 20, 2016
  Thanks for the bug report.   I have fixed this and it will be in the next release.

• Anonymous
  January 23, 2016
  Hi Vance, Just getting into ETW and using PerfView.  Very impressed, thanks for all your hard work! I'd like to make it easy for my customers to use PerfView by distributing it with my application and providing some canned scripts.  I can't seem to find the PerfView license, although apparently I might have accepted it when I first ran PerfView :-)  I can't make it appear again!  Is there a link to it somewhere online or in the app, that I've missed? Thanks, Ben

• Anonymous
  January 23, 2016
  If you use the menu item File -> Clear User Config, ten it will remove all state that PerfView remembers from run to run (including whether you have accepted the EULA.   Thus the next time you run it will display the EULA confirmation.  

• Anonymous
  January 24, 2016
  Awesome, thanks Vance!