PerfWatson Monitor

Free

The essential companion to PerfWatson! Provides a visual indication of PerfWatson activity showing Visual Studio responsiveness in real-time

(11) Review
Visual Studio
2010
Download (3,286)
6/18/2012
1.2
View
E-mail Twitter del.icio.us Digg Facebook
Add to favorites
Description
Reviews (11)
Q and A (5)
Sign in to write a review
Sort by:

by Binori | October 17 2012

by agos | April 25 2012

Hello!
Thank you for this extension!
I'm waiting version for VS11 :)

Paul Harrington June 18 2012
| Edit |
Delete

The VS 2012 version is now available here:
http://visualstudiogallery.msdn.microsoft.com/ad0897b3-7537-4c92-a38c-104b0e005206

by Pascal Hubert | December 27 2011

by Ehsan Mohammadi | October 09 2011

by naviwhack | July 28 2011

Very handy feedback about what VS is doing.

by Ondrej Spanel | July 12 2011

by Matt Frear2 | July 11 2011

Works great

by stevenh7776 | June 13 2011

by Nuno Miguel Gomes | May 20 2011

by Andre.Ziegler | May 17 2011

Version 1.2 works fine and shows me when VS2010 hangs.

by codan3 | May 17 2011

Sign in to start a discussion


  • Reading Log Files
    2 Posts | Last post October 12, 2012
    • Can the monitor read the log files created by PerfWatson?  If not, is there a way to read them?
    • No. The PerfWatson log-files are essentially a combination of a minidump (capturing the stack on the UI thread at the time of the delay) and a text file indicating the length of the delay. I think PerfWatson also captures the time of various events during startup, but I don't know if that feature is in the final version.
      - Paul
  • Visual Studio 2012
    2 Posts | Last post June 18, 2012
    • Any chance on getting this for 2012?  2012 has PerfWatson built in, just need the monitor, I love it!! :)
    • Yes, indeed! I've just uploaded a version for VS 2012 here: http://visualstudiogallery.msdn.microsoft.com/ad0897b3-7537-4c92-a38c-104b0e005206
      
      Thanks for the love :)
      - Paul
  • Crash report
    4 Posts | Last post December 26, 2011
    • I’m thinking this was on startup of Visual Studio (i.e. before I did anything else with VS).
      [Split over several posts due to forum limits]
      Exception Type: System.NullReferenceException
      Exception Message: Object reference not set to an instance of an object.
      Exception Stack Trace:    at System.IO.Packaging.Package.AddIfNoPrefixCollisionDetected(ValidatedPartUri partUri, PackagePart part)
         at System.IO.Packaging.Package.GetPartHelper(Uri partUri)
         at System.IO.Packaging.Package.GetPart(Uri partUri)
         at System.Windows.Application.GetResourceOrContentPart(Uri uri)
         at System.Windows.Application.LoadComponent(Object component, Uri resourceLocator)
         at Microsoft.VisualStudio.Labs.ResponseTimeDisplay.InitializeComponent()
         at Microsoft.VisualStudio.Labs.ResponseTimeDisplay..ctor()
         at Microsoft.VisualStudio.Labs.PerfWatsonMonitorPackage.InjectMonitorControlInGrid(Grid grid)
         at Microsoft.VisualStudio.Labs.PerfWatsonMonitorPackage.<>c__DisplayClass2.<TryInjectMonitorControl>b__1()
         at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
         at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
         at System.Windows.Threading.DispatcherOperation.InvokeImpl()
         at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state)
         at System.Threading.ExecutionContext.runTryCode(Object userData)
         at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
         at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
         at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
    • [Continued]
         at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
         at System.Windows.Threading.DispatcherOperation.Invoke()
         at System.Windows.Threading.Dispatcher.ProcessQueue()
         at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
         at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
         at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
         at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
         at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
         at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
         at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
         at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
         at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
         at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
         at Microsoft.Internal.VisualStudio.PlatformUI.WorkerThreadElementContainer.UIWorkerThreadStart(Object arg)
         at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
         at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
         at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
         at System.Threading.ThreadHelper.ThreadStart(Object obj)
      Exception Data:
      Key: System.Object, Value: [null]
      
      
      -------------------------
      
      Installed Extensions
      	DevExpress Tools
      	State	=	Enabled
      	Version	=	10.2.8
      
      	F# Assembly Info File
      	State	=	Enabled
      	Version	=	1.0.1
    • [Continued]
      	Duplicate Selection
      	State	=	Enabled
      	Version	=	1.1
      
      	VSCommands 2010
      	State	=	Enabled
      	Version	=	3.7.3.13
      
      	Solution Load Manager
      	State	=	Enabled
      	Version	=	0.2.2
      
      	Reference Assistant
      	State	=	Enabled
      	Version	=	1.1.11345.1020
      
      	VS10x Code Map v2
      	State	=	Enabled
      	Version	=	2.43
      
      	VS10x Method Block Highlighter
      	State	=	Enabled
      	Version	=	1.15
      
      	Image Insertion
      	State	=	Enabled
      	Version	=	1.5
      
      	JScript Brace Matching Extension
      	State	=	Enabled
      	Version	=	1.1
      
      	JScript Editor Extensions
      	State	=	Enabled
      	Version	=	1.1.2
      
      	JScript IntelliSense Para Extension
      	State	=	Enabled
      	Version	=	1.1.1
      
      	JScript Outlining Extension
      	State	=	Enabled
      	Version	=	1.1.1
      
      	JScript Word Highlighter Extension
      	State	=	Enabled
      	Version	=	1.1
      
      	PowerCommands for Visual Studio 2010
      	State	=	Enabled
      	Version	=	1.0.2.3
      
      	Productivity Power Tools
      	State	=	Enabled
      	Version	=	10.0.20626.18
      
      	Regex Editor
      	State	=	Enabled
      	Version	=	1.5
      
      	Visual Studio PerfWatson
      	State	=	Enabled
      	Version	=	1.1
      
      	Microsoft All-In-One Code Framework Sample Browser
      	State	=	Enabled
      	Version	=	4.85
      
      	Code Contracts Editor Extensions
      	State	=	Enabled
      	Version	=	1.4.40314.1
      
      	PerfWatson Monitor
      	State	=	Enabled
      	Version	=	1.2
      
      	Spell Checker
      	State	=	Enabled
      	Version	=	2.23
      
      	DPack
      	State	=	Enabled
      	Version	=	3.0.15
      
      
      
      -------------------------
      
      Environment Data
      VisualStudio.Version	=	10.0
      VisualStudio.Edition	=	Premium
      VisualStudio.FullName	=	C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe
      VisualStudio.RegistryRoot	=	Software\Microsoft\VisualStudio\10.0
      VisualStudio.LocaleId	=	1033
      VisualStudio.DisplayMode	=	vsDisplayMDITabs
      Time.UTC	=	12/25/2011 10:52:39 PM
      Time.Local	=	12/25/2011 4:52:39 PM
      OS.Architecture	=	x86
      Environment.Version	=	4.0.30319.239
      Environment.HasShutdownStarted	=	False
      Environment.OSVersion.Platform	=	Win32NT
      Environment.OSVersion	=	6.1.7601.65536
    • [Continued]
      CurrentThread.Id	=	1
      CurrentThread.Name	=	[null]
      CurrentThread.ThreadState	=	Background
      CurrentThread.IsBackground	=	True
      CurrentThread.UICulture	=	English (United States)
      CurrentThread.Culture	=	English (United States)
      Process.PagedMemorySizeMB	=	182.328125
      Process.MaxWorkingSetMB	=	1.34765625
      Process.NonpagedSystemMemorySizeMB	=	0.0463943481445313
      Process.PagedSystemMemorySizeMB	=	0.892070770263672
      Process.PrivateMemorySizeMB	=	182.328125
      Process.VirtualMemorySizeMB	=	632.00390625
      Process.WorkingSetMB	=	207.28515625
      Process.UpTime	=	00:00:25.5987443
  • Is there any way...
    5 Posts | Last post December 19, 2011
    • to know who the offending party is?  I've noticed recently that something is causing VS to lock up for a few seconds (probably an extension) intermittently.  If it was possible to hover over the monitor and see some information about what was happening when the monitor pegged...
    • +1!
    • [Split over several replies due to forum limits]
      Will Sullivan and Oliwa ask if there is any way to know who the offending party is. That is, can PerfWatson Monitor report what component in Visual Studio is responsible for the delays? Unfortunately, this is a very difficult question, and not one that can be answered reliably and accurately. 
      First of all, when a delay is detected, all that PerfWatson has for analysis is the call-stack on the UI thread. Usually at the top of the callstack will be a call into the operating system kernel to, for example, read a file or wait for some other thread to set an event. With a little bit of work, PerfWatson Monitor could look up the symbols of this stack frame via the Microsoft public symbol servers, and make a report that said “The UI thread is blocked reading a file” or “The UI thread is blocked waiting for an event from a background thread”. That’s not very interesting. Finding the name of the file in question, or a description of the event would be an improvement, but that’s highly specific to the specific delays and not generally applicable.
      PerfWatson Monitor could also do more sophisticated analysis of the call-stack, resolving symbols again using the public symbol servers until it found a few stack frames in Visual Studio code. For example, if one of the stack frames said “msenv.dll!CToolbox::Populate”, PerfWatson Monitor might conclude that the delay occurred in the Toolbox component. However, very few stack frames are as obvious as this example. For example, the Toolbox is extensible – other components can contribute controls to the Toolbox - and sometimes the “blame” isn’t with the Toolbox itself, but with one of those components. It would be incorrect to blame the Toolbox entirely for a misbehaving 3rd party control.
    • [Continued.]
      Taken to a ridiculous extreme, nearly every call-stack from the UI thread gathered by PerfWatson has a frame on it like “msenv.dll!EnvironmentMsgLoop” – the main message pump for Visual Studio. Does that mean that the message pump is responsible for all the delays?  Clearly that couldn’t be the case.
      Finally, some delays are caused by a sequence of actions, but the call-stack captures only the last one. The history is important, but PerfWatson doesn’t have access to that history.
      The analysis we do at Microsoft with PerfWatson reports is based on aggregation of call-stacks. Each call-stack delay reported to us is put into a database where we match it with other, similar call-stacks. They don’t have to match perfectly, particularly in the top few frames where OS differences and the exact time when the call-stack is taken can introduce variability, but they do match very well at the “bottom” and the “middle”. The middle frames are the most interesting because they are not too general (EnvironmentMsgLoop) and not too specific (kernel32.dll!MmAccessBlah). These “Goldilocks” frames naturally rise to the top of our frequency analysis and we can begin to put them into buckets. There is quite a bit of human involvement here, and experts who know the components involved can define the buckets by splitting, folding and grouping queries into meaningful units. For component owners, this is sometimes eye-opening, and always rewarding to see how their component is performing “in the wild”. For more information about this, please see http://blogs.msdn.com/b/visualstudio/archive/2011/08/24/how-we-use-your-perfwatson-data-to-identify-unresponsive-areas.aspx
      
    • [Continued.]
      Now, it might be possible one day, to “close the loop” and have PerfWatson Monitor contact the PerfWatson database via a public WebService and see if the just-captured call-stack matches any of the defined buckets to give a “best guess” at the cause for the offending component. The Visual Studio Responsiveness team has talked about doing that, but it hasn’t made it onto our backlog yet. We would need to sanitize the data for public consumption by removing all trace of internal bug IDs and email aliases and by ensuring that we had a sensible “offending component name” for each bucket.
      Unfortunately, the Responsiveness team is currently busy with other tasks at the moment and none of this is likely to happen any time soon, if at all. Sorry.
  • Version 1.1 released
    5 Posts | Last post May 17, 2011
    • Version 1.1 is now released. It displays a yellow warning triangle when the 2 second threshold is approaching and turns the graph background red when the 2 second threshold has been exceeded.
    • Hi Paul,
      
      thanks for this extension. I've installed the PerfWatson extension 2 weeks ago and tried the PerfWatson Monitor extension today but I can't see the graph in the statusbar. At the point on your picture Resharper displays some data in my VS2010. Do both extensions work side by side?
      
      I'm using Win7 x64 Ultimate Sp1 (German), VS2010 Sp1 (English).
      
      best regards
      André
    • Hi, Andre. I'm sorry PerfWatson Monitor isn't working for you. I don't have Resharper installed, so I haven't tested the two together. There's no policy for adding controls to the status bar, so my code uses a conservative algorithm to add itself. That algorithm will give up if something isn't quite right. In this case, I expect that, by the time PerfWatson Monitor tries to add the graph control, Resharper has already modified the status bar and PerfWatson Monitor cannot find the right place. Let me see what I can do.
    • I installed a trial version of Resharper 5.1 and fixed the problem. Version 1.2 of PerfWatson Monitor has the fix.
    • Hi Paul, I can confirm this. Version 1.2 works fine.