I have installed the latest Windows 7 SDK which contains the WPF Performance Profiler.
Perforator does display some data when I launch my app, but the Visual Profiler does not display anything. The timeline moves but not data is collected ...
Try this Link
In the WPFPerf Performance Profiling Tools for WPF 4 is now available! post, I mentioned that a bug caused the Visual Profiler to not display any data in certain time zones.
A patch is now available to fix this issue...
First check to see if its working even with a small blank WPF application. If it is not working with a blank WPF app, then it likely is the patch already mentioned (TimeZone patch to WPF Performance Profiling Tools for WPF 4 is now available).
However, in my case that wasn't the issue. Visual Profiler has a bug that causes it not to display the Element tree if it doesn't like some of the characters in its main window title bar.
Through hours of trial and error, I was able to trace the root cause of why it would not work on our application even though it would on a blank WPF application. The reason is that our application has a special character in the title bar text (trademark). If we eliminate the special character from the main window title, the element tree shows fine when the visual profiler is attached. I was able to reproduce this issue in the simple blank WPF application too simply by putting the following property on the main window:
<Window ..... Title="Test Application™" >
Looks like a bug in Visual Profiler that somehow is triggered by special characters. I didn't test for other special characters, but likely it isn't just this one.
So the workaround is to remove the special character while you are profiling until they fix this.
Check out if you are using the version 4.0 of WpfPerf. The original that comes with the SDK do not support .net 4
Related
I'm trying to use MS UI Automation to test a WPF application, and am using the Inspect Object tool (inspect.exe) included with the Windows SDK to look up the AutomationId property on certain elements.
Inspect is behaving very strangely for me:
If I close all applications and start the WPF application and Inspect, inspect is able to see the AutomationId property for various UI elements. Elements which do not have an AutomationId simply show two quotation marks denoting an empty string ("").
After I perform a few actions in the WPF application, inspect.exe hangs and I have to kill it and restart it. Even though the machine's CPU and RAM utilization are around 50% or less, I've tried waiting several minutes--possibly close to 20 or 30 mins on a couple occasions--to no avail.
After restarting, inspect.exe can no longer find an AutomationId for any UI element, even those which did have them previously. What's more, the property is completely missing when hovering the mouse over the WPF application--it is no longer listed at all, not even with an empty string value.
If I move the mouse to another screen (specifically, to another computer, using Mouse Without Borders), the AutomationId property reappears with a value of "FormDot"
If I restart only inspect additional times while the WPF application is still running, inspect still behaves the same as after the first restart.
If I restart only the WPF app while inspect is still running, inspect still behaves the same as after its first restart.
If I close both inspect and the WPF app, then start inspect, then start the WPF app, everything works correctly for a while and inspect finds the AutomationId on a few elements in the WPF app...up until the point at which inspect hangs again.
I've tried running inspect both normally and as an administrator as suggested in https://stackoverflow.com/a/7833728/44737, and it behaves the same either way.
What, if anything, am I doing wrong? Am I just too impatient and do I need to wait a really long time instead of assuming inspect is hung? And why does inspect's behavior regarding AutomationId vary?
There are more than one version of Inspect.exe. The latest to my knowledge is the one dated from 2012 that says version 7.2.0.0 in the help/about dialog box.
The old one doesn't have a tree view on the left with all detected automation elements displayed in a tree, so it's easy to check you're using the right one.
The latest one works quite correctly, however, IMHO, the best tool so far to work with UI Automation is Visual UI Automation Verify. It's a .NET program, and he source is available here:
UI Automation Verify (UIA Verify) Test Automation Framework.
Note that although it's a .NET program, it doesn't use the standard .NET automation dlls (more on that here: What's the difference of UISpy.exe and Inspect.exe? (From Microsoft Windows SDK)).
About the AutomationId property, to clarify my initial comment to the question, I meant its usefulness depends on the program that you're trying to automate.
If you own it as a developer, it's clearly interesting. For example, if you're working with WPF, you can use the x:Uid property, it's clearly meant for UI automation. In the Winforms space, it's also quite useful because UI Automation will use the control's AccessibleName by default and revert to the Name as a fallback, for the AutomationId value.
But there are many apps that don't rely on .NET (browsers, native apps, etc.) Usually, for these apps, it's easier to use other properties.
I have been using inspect.exe for a while on a Microsoft Surface Studio PC (running Windows 10), and my experience is that inspect.exe will hang much more frequently (sometimes always) when Windows Updates are pending. When the updates are out of the way, inspect.exe is still somewhat slow, but much more stable.
I am using the performance analysis tools within Visual Studio to evaluate a rather large and complex WPF application I am working on. I've been able to get cold start time reduced significantly by lazy loading most of the user controls that previously I just loaded on the application start however I am still seeing the bulk of my CPU cycles spent within the assembly 'PresentationFramework.ni.dll'. This doesn't help me figure out what the root cause is because all it says is that the time is spent on a particular user control's 'InitializeComponent' (i.e. XAML parsing) or Window.Show (i.e. XAML parsing).
My question is this: how can I get more granular insights into what specific XAML elements are causing the performance issue?
I am using Visual Studio 2013 and running Windows 8.1. I used to use the old Windows 7 SDK WPF Performance Toolkit that showed a really useful rendering time display that change the color on screen when a particular UIElement was re-drawing but I can't seem to find the same tool that runs on Windows 8.
I suspect the user control has a "deep" visual tree,so it spends time initialising. I did face this myself and used a workaround to load the user controls in background as soon as the application starts.hope this helps.
I'm a big fan of the rather obscure "Document Outline" window in VS 2008 (it's buried in the View -> Other Windows menu).
It's the only way I know to get a view of the containment heirarchy for a complicated WinForm that has a lot of nested controls.
Some months ago, this just stopped working for the most complicated form in my WinForms project. Now it just displays "There are no items to show for the selected document", no matter what I select in the designer.
No clue as to what broke it - the form contains a mix of common MS controls and some third party controls (mainly DevExpress). Several SplitContainers, but Document Outline originally had no problem with these.
Anybody else seen this, and any suggestions on how to fix it?
After some poking around, I solved the problem myself.
I just started deleting controls from the form, to see what would happen.
Turns out the 3rd party grid I'm using caused the problem - when I reconfigured it, the problem went away. (Looks like a bug in the control, which I've reported to the vendor).
Interesting...misbehaving controls can break the VS IDE, not just your apps.
I am using:
Visual Studio 2010 Professional,
Silverlight 4 Toolkit
The WPF Designer don't show (invisible) - while the Component Toolbox is showing the relevant controls, and the Windows->Windows option shows the designer to be active. It does this with ALL XAML for me, regardless of its complexity. I have already tried the /ResetSkipPkgs to no avail. I had CodeRush and DevExpress installed (demo) version but removed both since. I can get along with XAML by switching to Source Code /Text Editor, but this really boils my chops to run the app to find out that I have made a silly mistake in my XAML (while a preview would sort it out quicker, and no, please don't suggest Expression Blend for it is non-nonsensical for me to switch continuously between these applications).
When I however switch the WPF Designer to open with Encoding I get the following error - which I assume is related to the issue for not showing the XAML Editor/Designer in non-encoding:
An Unhandled Exception has occurred
Click to reload the designer
System.NullReferenceException
Object Reference not set to an instance of an object.
at MS.Internal.Providers.VSDesignerContext.VSDesignerContextHolder..ctor(IServiceProvider services, VSDesignerContext context, Object docData)
at MS.Internal.Providers.VSDesignerContext.GetContext(IServiceProvider services, IVsWindowFrame frame, Boolean createIfNotExist)
at MS.Internal.Designer.TabbedEditorPane.MS.Internal.Designer.ITabbedEditorService.get_DesignerContext()
at MS.Internal.Designer.DesignerPane.InitializeDesigner()
I have googled it silly, to no avail. I am thinking about reinstalling Visual Studio - but this REALLY is a last resort. I hate fixing things by reinstalling, rebooting etc.
Any guru with the magical answer?
I got the exact same exception today and solved it by killing a few GDI hungry apps. You can see the number of GDI objects a process is using in the Processes tab of Task manager (you will probably need to add the column using View -> Select Columns).
Hmm, I know this is old, but you should try installing SP1 for your Visual Studio if you haven't yet.
I am trying to use WPFPerf to profile a WPF 4.0 application (I have the latest WPFPerf that should work on WPF 4.0 aps). I start the tool Visual Profiler from WPFPerf, I start my aplication, but after that nothing happens and the element tree from the Visual Profiler is empty. No other error message is shown. Can anyone tell me what am I not doint right?
As an additional information, when I try to analize my .exe assembly or any other assembly from my application, I get a BadFormatException saying that the assembly was build with a newer version of .NET. From the download page http://go.microsoft.com/fwlink/?LinkID=191420
I see that this version of WPFPerf should be ok for my app
TimeZone patch to WPF Performance Profiling Tools for WPF 4 is now available
http://blogs.msdn.com/b/jgoldb/archive/2010/08/24/timezone-patch-to-wpf-performance-profiling-tools-for-wpf-4-is-now-available.aspx
First check to see if its working even with a small blank WPF application. If it is not working with a blank WPF app, then it likely is the patch already mentioned: TimeZone patch to WPF Performance Profiling Tools for WPF 4 is now available
However, in my case that wasn't the issue. Visual Profiler has a bug that causes it not to display the Element tree if it doesn't like some of the characters in its main window title bar.
Through hours of trial and error, I was able to trace the root cause of why it would not work on our application even though it would on a blank WPF application. The reason is that our application has a special character in the title bar text (trademark). If we eliminate the special character from the main window title, the element tree shows fine when the visual profiler is attached. I was able to reproduce this issue in the simple blank WPF application too simply by putting the following property on the main window:
<Window ..... Title="Test Application™" >
Looks like a bug in Visual Profiler that somehow is triggered by special characters. I didn't test for other special characters, but likely it isn't just this one.
So the workaround is to remove the special character while you are profiling until they fix this.