• Allows you to profile managed memory that uses .NET 2.0, 3.0, 3.5, or 4. 
  (However, you must always have .NET 4.0 installed on your box in order to use CLRProfiler V4, as CLRProfiler itself contains managed code that depends on .NET 4)
• Can target Silverlight 4 web apps.
• Can attach to and detach from live processes, to generate heap graphs. 
  (Note:  This feature requires the process to be running .NET 4.0, does not work against Silverlight, and does not allow gathering allocation call stacks.)
• Understands in-process side-by-side CLR instances, and can allow you to pick which CLR instance from a given process to profile

See more details here.

You can get the fixes for WPF 4 from here: https://support.microsoft.com/kb/2297328

Enjoy. Jossef

• Silverlight Startup Best Practices
• Analyzing Silverlight Memory Usage: Part 1 – Obtaining Measurements

We plan to add additional posts in the near future, so please stay tune.

1. Install the WPF Performance Tool like you normally would by installing the Windows SDK for Windows 7 and .NET Framework 4 (Windows SDK 7.1)
2. Install the patch from https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=da041972-1eb6-4a8a-97d7-d495b314505e
3. When you get to this dialog, click on 'Repair' 
    
4. On next dialog click 'Repair' again. 
   

WPF will always attempt to use HW rendering, but in certain cases WPF will fall to Software rendering and the application may not be aware of it.
Some folks wanted to better understand all the possible cases, so am I am listed these below.
WPF will render in Software when:

1. Machine video driver date is old (before 11/2004)
2. WPF detected a "Tier 0" graphic card.
   This means that no graphics hardware acceleration is supported and DirectX version level is less than version 7.0.
3. The rendered Window's size exceeds the max video card texture size.
   One common scenario for this to happen if you have a WPF window spanning across multiple monitors.
4. You run your application over Remote Desktop Protocol (e.g. Remote Desktop, Terminal Server, Remote Assistant, etc)
   Until NET 3.5 SP1 and earlier, remoting between Vista to Vista with DWM on, leveraged a custom WPF primitive remoting protocol. In all other scenarios content was remoted as bitmaps. Starting with the release of NET 3.5 SP1 (including NET 4), WPF renders the application content using a software rasterizer on the server and then remotes the content as bitmaps in all cases. Read more here.
5. Rendering in Virtual Machine.
   WPF will try and render in HW but on some VMs the graphic emulator that comes with the VM is not working correctly. User will have to switch to software to fix the problem. 
6. The Application is calling the force Software API. E.g.
   RenderOptions.ProcessRenderMode = RenderMode.SoftwareOnly;       // Force Software rendering per Process – New in NET4
   hwndTarget.RenderMode = RenderMode.SoftwareOnly;        // Force Software rendering per Window– Introduced in Net 3.5 SP1
7. You set the global registry key. E.g.:
   (HKEY_CURRENT_USER\Software\Microsoft\Avalon.Graphics] 
   "DisableHWAcceleration"=dword:00000000 )
   Note: Since this reg key impacts all WPF application consider using this key for testing purposes only.
8. Application uses legacy style bitmap effects.
   Note: these are obsolete in NET4.
9. Application printed content.
10. Rasterized content that uses RenderTargetBitmap
11. Tiled content that uses TileBrush
12. Use of too many light objects in your 3D scene. Read more here.
13. Layered windows (only on XP SP2/W2k3 or before that do not have Hotfix installed.
    See: https://support.microsoft.com/kb/937106/en-us.
14. Graphics hardware failures, such as "Out Of Video Memory" (OOVM).
    WPF try to free up video memory and stay in HW rendering but it may not always work and WPF will fall to Software  

Which tools can I use to detect if my app renders in Software?
The easiest way is to use Perforator which is included with the WPF Performance Profiling Tools and check below check boxes.
Read more here.

How can I detect if my app renders in Software in code?
Check the RenderingCapability.Tier . You can also listen on the Tier change event.

1. KB981107 (See: https://support.microsoft.com/kb/981107)

This Hotfix fixes the following memory leaks in .NET 3.5 SP1 WPF-based applications.
Issue 1:
This affects an app that contains styles or templates that refer to application resources (via StaticResource or DynamicResource), and that creates a large number of elements that use these styles or templates but never need the actual value of the resource.  In this situation, the app can leak DeferredAppResourceReference objects, even after the elements themselves have been reclaimed.  (In addition, the app can leak WeakReferences and array space, similar to the issues described below.)

An example:  App resources define   <sys:Double x:Key="{x:Static SystemParameters.HorizontalScrollBarHeightKey}">20</sys:Double>     This creates a resource that's used by any control that can display a horizontal scrollbar.  Creating a large number of such controls that never actually display their scrollbar will encounter the leak.

Issue 2:
This affects an app that creates a large number of short-lived elements with properties that are data-bound to a DependencyProperty of longer-lived elements. In this situation, the longer-lived elements maintain lists of WeakReference objects, used to notify the short-lived elements about property changes. The app can leak WeakReference objects and the array space to hold them, even after the short-lived elements have been reclaimed.

An example:   ListBoxItem binds its HorizontalContentAlignment property to a similar property on its governing ListBox.   An app that creates a large number of ListBoxItems (say by doing a large number of additions and deletions to the ListBox's ItemsSource) will encounter the leak.

Issue 3:
This issue affects classes derived from TreeView or Selector (including ListBox, ListView, Menu, DataGrid, and many others).   These classes register for an internal notification from the KeyboardNavigation class, used for controlling keyboard focus.   An app that creates a large number of these elements can leak WeakReference objects and the array space to hold them, even after the elements themselves have been reclaimed.
An example:  An app that creates a large number of short-lived ListBoxes will encounter the leak.  This can happen in a nested scenario, where an outer ListBox displays a collection that undergoes a large number of additions and deletions, and where each item is displayed using an inner ListBox.

These fixes are not included in NET4. We are considering this Hotfix also for NET4, but this decision has not been made, so stay tune.

2. KB967634: (See: https://support.microsoft.com/kb/967634 )

This fixes a memory leaks in .NET 3.5 SP1 WPF-based applications when using software 3D rendering involving a VisualBrush or DrawingBrush.
This fix is already included in .NET 4.

3. KB967328 (See: https://support.microsoft.com/Default.aspx?kbid=967328)

This Hotfix fixes memory leaks when a deferred resource isn't inflated due to the resource reference expression hooking up to the Inflated event on the resource dictionary entry.
If the resource dictionary is an application or theme dictionary, then these are essentially global and can cause these expressions to stay alive.
There are some discussions on this issue here.
This fix is already included in .NET 4.

Many folks however are looking to overlay WPF content over Web content. Chris Cavanagh posted sometimes ago a blog that explain how you can do so using Google's web control.
Sources for a sample are available on Codeplex. You would need to license the wrapper called Awesomium.

To use:
During debug, in a DataTip, Watch window, Autos window, or Locals window, next to a WPF object name, click the arrow adjacent to the magnifying glass icon.
See images below for the SDK example I used:

This version includes other impressive list of improvements that you can read about here.
Thanks to Corry Plotts and others (Dan Hanan, Mark Kharitonov, etc) who improved on Pete Blois’ original Snoop.

The WPFPerf tool comprises of a suite of performance profiling tools that allow you to analyze the run-time behavior of your WPF application and point to potential performance bottlenecks.
We finally release the version that also supports .NET Framework 4 (WPF 4).

This version of the tool (WPFPerf 4) will allow you to profile both WPF 3.5 SP1 and WPF 4 based applications.
The WPFPerf 4 tool is included with the Windows SDK for Windows 7 and .NET Framework 4 (Windows SDK 7.1). So you are welcome to download and send us your feedback.

By the way, the tool itself will run on machines with only .NET 3.5 SP1 or only .NET 4, if both are present it will use .NET 3.5 SP1.
Also, I am not sure how many people had a chance to look at the documentation that is installed with the tool , but we think it is very useful so don't forget to check it out.

Update (6/14/2010):
We heard that few folks complain that the Visual Profiler cannot correctly attach to the WPF application in the new WPFPerf for WPF 4.
After some research we think this has to do with a bug in our DateTime initialization which cause anyone in a time zone > GMT to not get any data in VisualProfiler (for a few hours at least).
Until we post a fix, a temporary workaround is to set your time zone > GMT (e.g.to Eastern or Pacific Standard Time Zones) when you first attach VisualProfiler.

Please try this workaround and let us know.

Update (8/24/2010):
A patch to that fixes the bug in Visual Profiler for certain time zones is now available.
See here.