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 (27)

  1. Sebastian Solnica says:

    Thanks a lot for the update! The localization issues are now gone 🙂

  2. Raghu says:

    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?

  3. 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.  

  4. Marc Sherman says:

    I noticed the temp files in %temp%perfview use up a lot of space. I'm running PerfView from the command line with the "-zip" option. Is it safe to delete the files in %temp%perfview after "PerfView -stop" completes and the .zip file has been written out?

    thanks

  5. 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.  

  6. Marc Sherman says:

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

  7. 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)

  8. Marc Sherman says:

    Hi Vance, I originally posted this in the "CLR Internals and Architecture" forum but they suggested posting here as well:

    I'm running PerfView 1.8 from the command line. The log file specified with  -LogFile shows:

    [DONE 14:04:22 SUCCESS: PerfView start -AcceptEULA -BufferSizeMB:64 -CircularMB:512 -DataFile:Data_3984_5_11_2015_14_4_21 -LogFile=Log_3984_5_11_2015_14_4_21 -KernelEvents:Process+Thread+ImageLoad+VirtualAlloc+VAMap -OSHeapProcess:3984 -zip]

    The -zip option instructs PerfView to merge the data.

    Later the log file shows that merging completed successfully:

    Merging took 152.7 sec

    Moving C:PerfviewMonmem-monData_3984_5_11_2015_14_4_21.etl.new to C:PerfviewMonmem-monData_3984_5_11_2015_14_4_21.etl

    Deleting temp file

    Merge took 152.880 sec.

    Merge output file C:PerfviewMonmem-monData_3984_5_11_2015_14_4_21.etl

    [Zipping ETL file C:PerfviewMonmem-monData_3984_5_11_2015_14_4_21.etl]

    [Writing 7 PDBS to Zip file]

    ZIP generation took 44.844 sec

    ZIP output file C:PerfviewMonmem-monData_3984_5_11_2015_14_4_21.etl.zip

    Stop Completed at 11/5/2015 2:09:05 PM

    [DONE 14:09:05 SUCCESS: PerfView stop -DataFile:Data_3984_5_11_2015_14_4_21 -LogFile=Log_3984_5_11_2015_14_4_21]

    I then copy the .zip file for analysis on a different machine. In PerfView  I select "Net Virtual Alloc Stacks" and then select my process and then PerfView displays this message box:

    —————————

    Data not merged before leaving the machine!

    —————————

    Warning!   This file was not merged and was moved from the collection

    machine.  This means the data is incomplete and symbolic name resolution

    will NOT work.  The recommended fix is use the perfview (not windows OS)

    zip command.  Right click on the file in the main view and select ZIP.

    See merging and zipping in the users guide for more information.

    —————————

    OK  

    —————————

    But as you can see from the above info from the log file the merging succeeded.

    Any ideas?

    thanks,

    Marc Sherman

  9. 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.  

  10. Marc Sherman says:

    PerfView's TraceInfo reports the OS as Windows Server 2008 R2 Standard so I'll try an earlier version of PerfView.

    BTW, the customer reported that the heap ETL file grew to 18GB before they stopped the trace. My script specifies -BufferSizeMB:64 -CircularMB:512 parameters. I see from the PerfView log that the OS Heap provider does not use circular buffering. But shouldn't the "-BufferSizeMB:64" command line parameter keep the heap ETL file under 64MB?

    thanks,

    Marc Sherman

  11. 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.    

  12. Marc Sherman says:

    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

  13. PerfView is not designed to allow the changing of collection part way through.     However you can achieve the effect by merging ETL files (which makes one that has the events in all the source files).    The cleanest way of doing this is to collect with the /merge:false and a /DataFile=XXX for each of the traces.   Then you just need to merge all these files.   PerfView will merge files with XXX.kernel*.etl or XXX.clr*.etl or XXX.user*.etl.  Thus you can simply rename the second set of files to XXX.kernel1.etl XXX.clr1.etl etc.   Then you can either just look at the file in PerfView or merge them, but you will get a trace that contains all the events.  

  14. Marc Sherman says:

    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

  15. 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.  

  16. Marc Sherman says:

    OK and thanks for your responses and thanks for developing PerfView!

  17. Vladimir says:

    > 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: http://www.dropbox.com/…/PerfViewLogFile.txt

    Thank you.

  18. 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.  

  19. 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.

  20. Vladimir says:

    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.

  21. Marc Sherman says:

    Are the -Zip and the -Wpr command line options mutually exclusive? I would like to perform analysis on a machine other than the one on which collection occurred. PerfView's help file states that the -Zip option enables this scenario. But I would like to use both PerfView and WPA to analyze the data collected by PerfView. The help file states that the -Wpr option tells PerfView not to zip the file.

    ps. PerfView v1.6 successfully worked for me on Windows 2008R2.

    Thanks

  22. 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..

  23. Vladimir says:

    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)

  24. Thanks for the bug report.   I have fixed this and it will be in the next release.

  25. Ben Taylor says:

    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

  26. 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.  

  27. Ben Taylor says:

    Awesome, thanks Vance!  

Skip to main content