.NET Memory Profiler is an excellent tool, and one that I use frequently to diagnose memory leaks in WPF applications.
As I'm sure you're aware, a good way to use it is to take a snapshot before using a particular feature, then take a second snapshot after using it, closing the window, etc. When comparing the two snapshots, you can see how many objects of a certain type are being allocated but not freed: this is a leak.
After double-clicking on a type, the profiler will show you the shortest root paths keeping objects of that type alive. There are many different ways that .NET objects can leak in WPF, so posting the root path that you are seeing should help identify the ultimate cause. In general, however, try to understand why those objects are holding onto your object, and see if there's some way you can detach your event handlers, bindings, etc. when the window is closed.
I recently posted a blog entry about a particular memory leak that can be caused by certain bindings; for that specific types of leak, the code there is useful for finding the Binding that's at fault.