In some cases, however, AppDomain isolation does not suffice:

• Reliability: A hang or a crash in a hosted UI component usually affects the host. In the most basic setup, the UI components run on the same thread, which crosses the AppDomain boundary to deliver window messages to the child window. The host is often not in a good position to catch an exception from the add-in or to distinguish it from an exception coming from its own code. That’s because exceptions often occur in the context of UI event handlers, which are ultimately responses to Win32 input messages, which get delivered to the target window by the message pump of the thread. WPF runs a standard Win32 message loop via Dispatcher.Run(). Application code is not directly involved in this loop, and even if it can be, it could not identify the source of an exception that originated many abstraction layers away.

With some effort, a child window can be hosted on its own thread. Since each UI thread is supposed to run a message loop, the above problem could be largely avoided. (On top of that, the host would have to guard every direct call into the add-in’s entry points.) However, the hang problem remains. The native window manager automatically merges the input queues and states of threads that have windows in a parent-child relationship. This is generally very beneficial as it facilitates building seamless UI with focus integration and “accelerator” keys just working across the boundary (which requires Alt/Ctrl/etc. key states to be shared), but the message loops get implicitly synchronized: A call to GetMessage() blocks as long as there are messages at the front of the queue destined for the other window. You could opt out of this synchronization by calling AttachThreadInput(NULL), but then a lot of things that you normally take for granted “break”, and dealing with all induced problems quickly becomes overwhelming. There’s a living proof, though, this approach is viable and greatly beneficial (if you can afford the engineering cost ;-) ): Loosely Coupled IE.

• Unloading: To begin with, AppDomain unloading is not guaranteed to succeed. The reference documentation for AppDomain.Unload() has big enough caveats. On top of that, WPF has its fair share of problems with releasing of native resources and breaking object reference loops on unloading, which tend to show up in the context of CLR Add-Ins. Empirically, we know explicitly calling Dispatcher.InvokeShutdown() in an add-in’s AppDomain, on every thread that has had a Dispatcher or WPF object used on it, is often the practical solution. However, this requires cooperation from the add-in and, at least in the case of partial-trust add-ins, loading a host assembly in the add-in’s AppDomain (to be able to call Dispatcher.InvokeShutdown(), which is a privileged operation). If an add-in gets stuck in native code or merely runs a message loop on some thread that gets no user input (presumably different from the host’s UI thread), AppDomain unloading is guaranteed to fail.
  
• Native code cannot be easily convinced to follow AppDomain state isolation. This is a common integration challenge with legacy components that were not created with use from managed code in mind. Also, the bitness of the native component needs to be matched with that of the host process. This can be a problem because many legacy components are not available in 64-bit form. (Even the Flash and Silverlight ActiveX controls are not (yet).)

Cross-process UI isolation is the strongest, largely because it’s supported at the OS level. In particular, you can always kill a process and rely on complete cleanup. A typical add-in crash will just leave a blank “hole” in the host’s window. (Incidentally, this is what happens in the browser on the rare occasions the XBAP host process, PresentationHost.exe, just crashes.) The host can detect an unexpectedly vanished add-in process (for example, via Process.WaitForExit()) and restart the add-in. Unfortunately, hangs are still a challenge, due to the forced synchronization of UI thread message queues. But there is an effective mitigation for that: The host can have a “watchdog” thread that periodically pings the add-in’s UI thread and, if found unresponsive, offers the user to forcibly recycle the add-in.

Unfortunately, WPF does not directly work with CLR Add-In model’s out-of-process hosting (and provides subpar input & focus integration even in-process when the add-in’s UI runs on its own thread). First basic problem is that the host process does not start in an STA thread. This can be worked around by using an add-in side adapter, but that gets awkward. A further problem is with input flow and tabbing across the thread/process boundary. The HwndSource/IKeyboardInputSink integration we have implemented in the FrameworkElementAdapters is designed for single-threaded cases. When a child window is running on its own thread, it doesn’t need to rely on the host for input, although selective delegation of accelerators may be desirable, but it is often expected to “bubble” unhandled input to the host and/or possibly give the host ‘first chance’ to handle select special keys. A future version of the framework may provide better support for cross-thread UI add-ins.

The easiest way to have part of the UI isolated in a separate process is via an XBAP. You can navigate the WebBrowser control directly to the .xbap file. (This can be WPF’s WebBrowser or WinForms’ or, in a native application, directly IE’s ActiveX control.) The XBAP will run in an instance of PresentationHost.exe, and its child window will be attached to the WebBrowser control. There are, however, some downsides to this approach:

• The relatively significant runtime cost of ClickOnce deployment. (The first run can be particularly slow.)
• You cannot control the bitness of PresentationHost.
• Before .NET v4, there isn’t a convenient way for active two-way communication between the host application and the XBAP. This post presents one somewhat involved but effective technique.
  • In v4 we finally provide neat ‘script interop’ with the help of the Dynamic Language Runtime and the language-level support for it. The XBAP’s host application can expose its API through WebBrowser.ObjectForScripting, and the XBAP can access this object via BrowserInteropHelper.HostScript.

Finally, the attached solution illustrates doing cross-process UI hosting directly, using just HwndSource & HwndHost out of the box, running the two message loops, and routing input appropriately through the IKeyboardInputSink implementations of HwndHost and HwndSource. This example solves most of the above problems with in-process/cross-AppDomain hosting and provides good flexibility and performance. Much of the code is actually dedicated to somewhat extrinsic, “implementation-level” problems, but that’s how it typically is with solving real problems… ;-) The highlights:

• Asynchronous loading of the add-in for better startup time and to avoid UI thread blocking
• Use of .NET Remoting based on named pipes for two-way cross-process communication
• Remotable object lifetime management. Graceful & fallback shutdown of the add-in process
• Input & focus integration: tabbing in & out; “bubbling” unhandled keys from the add-in to the host
• Solving threading issues. 

Input

The main thread of the “add-in” process runs a Win32-style message loop via Dispatcher.Run(). This would mostly suffice for the child-window HwndSource to get its input, but keyboard input handling generally works better if MSGs straight off the message loop are “preprocessed", before passing them to DispatchMessage() and DefWinowProc(). This helps with correct handling of accelerators, in particular with some ActiveX controls (like the one WebBrowser wraps), and avoids occasional IME translation mishaps. WPF’s Dispatcher provides a direct hook into its message loop via the ComponentDispatcher.ThreadPreprocessMessage event. When HwndSource owns a top-level window, it subscribes itself to ThreadPreprocessMessage and does all the needed preprocessing and routing internally (largely by delegating to its IKeyboardInputSink implementation). But we need a child window for the add-in. The trick I’ve used is to first initialize the HwndSource as a top-level window, while keeping the window invisible, and then immediately convert it to a child one. Fortunately, the native window manager supports this well, and WPF obliviously takes it well too.

To be able to “bubble” unhandled keys to the host, the add-in subscribes a handler of its own to ComponentDispatcher.ThreadPreprocessMessage, counting on it to be called after HwndSource’s. The MSGs are relayed to the host via a custom remotable interface. Then the host obtains the main window’s IKeyboardInputSink implementation and calls TranslateAccelerator() and OnMnemonic(). Where do the messages go further? This arrangement invokes a special input event routing mode of HwndSource: It will see that a child window ("sink") has focus and will create an event route using the wrapper element (the HwndHost here) for the child window as the “forced” target. Thus, any element up to the root visual has a chance to see and handle the events, which is much in keeping with how most WPF routed events work. (The sample application shows a couple of interesting cases of key input delegation.)

For tabbing out, the KeyboardNavigation machinery gives us a special cue by calling IKeyboardInputSite.OnNoMoreTabStops(). The add-in provides a simple implementation of this interface and relays the call to the host, which merely calls MoveFocus() on the HwndHost. For tabbing into the add-in, the host implements IKeyboardInputSink.TabInto() on the HwndHost, which is appropriately called by the internal keyboard navigation code.

The host could selectively give the add-in opportunity to handle keyboard input. Doing so, however, is not analogous to how the add-in bubbles unhandled key input. The main difference is that there is no defined target element within the add-in’s UI, because focus is somewhere within the host’s window. (That’s why the host’s thread is getting the input messages.) Thus, calling IKeyboardInputSink.TranslateAccelerator() on the child-window HwndSource will not route input across that element tree. However, the InputManager will raise its global (per-thread, really) events: PreProcessInput, PostNotifyInput, etc. The add-in could handle these events and filter for specific keys it’s interested it. Or a custom interface could be defined across which to pass “managed” KeyDown events. There is one type of key input that still makes sense to be delegated to the child IKIS: mnemonics (these are Alt+something key combinations). HwndSource’s built-in implementation of IKIS.OnMnemonic() does most of its work independently from focus: It tries to activate AccessKeys within its element tree and then “broadcasts” the input event to any child sinks of its own (say, a WebBrowser control).

Threading

The two message loops appear to operate independently, and they are certainly unaware of each other per se. But the OS does the input queue & input state merging I mentioned earlier. Each input MSG is destined to a specific window, but the two message loops are essentially forced to serialize access to their respective messages. This creates implicit synchronization between the two threads (specifically around their message-pumping activity). One unfortunate practical implication is that the add-in can hang the host. A good strategy to mitigate this risk is to avoid doing any non-trivial input processing on the UI thread. While this is healthy practice in general, it’s not a guarantee, it's difficult to be so disciplined, and an external add-in may not cooperate. The “watchdog” feature I described earlier can be implemented if the host needs a stronger reliability guarantee.

Regardless of the specific IPC method chosen, for the two threads to be able to talk to each other, the receiving one has to be awaiting a Win32 message, that is, waiting in a call to the native GetMessage() or similar function or blocked in a message-alertable state supported by MsgWaitForMultipleObjects(). This is the general convention in Windows user-mode programming: A thread can be “hijacked” to respond to an external event (relatively) safely only around message pumping or when explicitly blocked in the special alertable state. Thus, for a UI thread to be responsive to external “calls”, it’d better be doing what UI threads are supposed to do most of the time: message pumping.

When making a simple, “one shot” call, the calling thread might just block until the call is processed and returned. But if the called thread decides to call back before returning, we have a problem: a deadlock. This kind of “reentrant” calls tend to occur naturally between related UI components, and even handling of basic window state changes such as resizing and focus move require making synchronous handling of window messages sent from one thread to another. Consequently, the calling thread should prepare itself to handle incoming messages while waiting for the call it has just made to complete. The most common traditional solution for this problem in Windows has been provided by COM. Being a means for cross-thread and cross-process communication and being used in UI scenarios, it had to. That’s one of the essential features of Single Threaded Apartments: Outgoing calls run an efficient local message loop waiting for the call to return and simultaneously dispatching all sent window messages and COM runtime’s internal window messages used to marshal STA calls from RPC thread-pool threads to the right thread. The CLR has had to accommodate message-based reentrancy as well, and as a pretty tough compromise at that: “Managed” blocking, such as via WaitHandle.WaitOne(), is window message permeable on an STA thread. While helping with interop scenarios and crucially preventing deadlocks, this tends to bite unexpectedly due to the unintuitive reentrancy allowed by an explicit “blocking” operation and the potentially asynchronous/random nature of such reentrant calls. I should not digress too much, because Chris Brumme has written the definitive treatise on this subject.

Because I’ve used .NET Remoting, and not COM, for the cross-process communication in the example implementation, I had the somewhat unexpected occasion to experience and ponder the above reentrancy vs. deadlocking issue. It turns out that the particular chosen IPC transport—named pipes (which is the most efficient available out of the box) does pretty hard blocking when sending “messages” and awaiting a response: At the bottom of the abstraction stack, a call to the ReadFile() native function is made to read the response message stream, and this function blocks unconditionally. So, for example, if the add-in tried to bubble some unhandled key to the host and the host decided to talk to the add-in while handling the given key or performed some window operation that affects the add-in’s window too, we’d get a deadlock because the add-in’s main (UI) thread is hard-blocked. To avoid this, all deadlock-prone calls across the boundary (in either direction) are made not from the UI thread but from a worker thread. WPF’s Dispatcher is run on this worker thread to be able to conveniently marshal calls to it. And there is a crucial side effect of calling Dispatcher.Invoke() cross-thread: The calling thread gets blocked in the message-permeable way described above, thus permitting reentrant calls via window messages. How would such a call actually be delivered? Via the Dispatcher again, but that of the pseudo-blocked UI thread. A Remoting call is normally received first on some random thread-pool thread. (That’s just how Remoting works. MarshalByRefObjects are treated as agile—not bound to any particular thread; thus, the runtime can deliver an incoming call on any thread.) For calls where some trivial processing is done not involving UI objects, no thread switching is needed. But WPF is pretty unforgiving if any UI object is accessed from a foreign thread. For such cases, that object’s Dispatcher is used to do a callback.

General Notes

• Most of the example solution and the foregoing discussion are valid for any cross-thread child window hosting, including in-process. In spite of the implicitly UI thread synchronization, overall responsiveness may be better than with single-threaded UI because there is opportunity for true concurrent processing. While you would not get the stronger reliability guarantees afforded by having a separate host process for the child window, performance will be noticeably better, especially if the application-level APIs are chatty. Also, .NET Remoting has special, optimized cross-AppDomain in-process marshaling mode.
• Also of practical interest is hosting WPF content in non-WPF applications. Since the essential integration interface between the “host” and the “add-in” in the above solution are a native window handle (HWND) and the fairly abstract IKeyboardInputSink, it is conceivable the host side could be implemented without WPF. For a purely native host application, however, .NET Remoting would have to be replaced with another IPC method, the most obvious and versatile choice being COM (and with it the deadlock/reentrancy issue is solved for free :-) ).

[Update, 4/29/10] Windows hosted by HwndHost tend to flicker heavily on resizing. This really shows with the WebBrowser control in my sample project, perhaps exacerbated by the cross-process window messaging. The solution is shown in this KB article: http://support.microsoft.com/kb/969728. (WFH derives from HwndHost, but the problem really is in HwndHost.) I updated the attached project.

X-Proc WPF Hosting.zip

When an XBAP is hosted in an HTML [i]frame, it has limited means to communicate with script in the host page. These are: passing parameters to the startup URL (which can be read from Application.StartupUri or BrowserInteropHelper.Source); exchanging HTTP cookies (Application.Get/SetCookie()); and, as a last resort, use a web service at the site of origin as an intermediary. The biggest obvious limitation of these methods is that they are passive: you don't have the equivalent of a method call. Thus, a commonly requested feature by XBAP developers is the ability to directly communicate with HTML script in the page hosting the XBAP. Until such feature is provided, there is a somewhat unobvious way to do this, but only from a full-trust XBAP and only in Internet Explorer.

The basic idea is this: Crawl the browser hosting container hierarchy starting from BrowserInteropHelper.ClientSite; get to the IWebBrowser2 of the frame hosting the XBAP; then get to the HTML DOM window object, and finally get its Script object, which represents the scripting environment of the HTML page. Having that object, "the magic" of COM Interop makes script function calls and parameter passing possible. On the managed side, you just do Reflection (late-bound) calls. Unfortunately, this is pretty ugly in C#, but with some helper methods it can be covered up. Since VB.NET has built-in support for late-bound method calls ("scripting"), the calling syntax can be fairly clean.

For HTML script to "call into" the XBAP can be arranged a little indirectly: The XBAP passes a 'scriptable object' to its host page, and then the late-bound calls from script are translated to managed method calls by COM Interop again, just in the opposite direction (via CCWs). The scriptable object needs to be marked with[ComVisible(true)] and expose some public API.

The attached project is a rudimentary demonstration of this technique. Incidentally, it also has an example of other interesting things you can do once you have IE's main interfaces: closing the tab/window in which the XBAP is loaded. (This is something for which there is no managed API. The XBAP can be running top-level in the browser, not in a frame.)

A note on the debugging setup: In Project Properties, the debugging option needs to be set to Start Browser with URL, pointing to HTMLPage1.htm in the bin\Debug output folder. (This setting is per user, so it's not saved in the attached project.) The page hosts the XBAP in an iframe. This is enough for Visual Studio 2008 to be able to start debugging the XBAP, even though it's launched indirectly. (The VS project system has some intrinsic knowledge of XBAPs and coordinates the launch with PresentationHost.exe, the XBAP host process, via the -debug and -event parameters.)

[Update, 10/14/09] On initial loading of the HTML page in IE, script execution will likely be blocked, with an explanatory message in the information bar (aka ‘goldbar’). You can click on the prompt and let IE enable running script, but this will start another instance of the XBAP. You could attach to it then with the VS debugger (attach to the running PresentationHost.exe). This gets tedious after a while. Just for debugging, you could let script run automatically by selecting the option to ‘Allow active content to run in files on my computer’ in Internet Options > Advanced tab > Security section. It is risky to leave the browser running with this setting, so remember to reset it. The script blocking won’t happen if you open the host HTMP page from a UNC path or HTTP URL, but unfortunately F5 debugging of the XBAP becomes impractical then.

Another issue you might run into is that the host HTML page will load without the XBAP in it. There may be different reasons for such mishap, but a likely one with the sample is that your anti-virus program sneakily opens the .zip file and puts the Zone.Identifier alternate data stream on the files in the archive. Use of Scott’s methods to remove the stream.

Finally, to run an XBAP with full trust, the easiest way is to just run it from the local file system, which is the case of debugging in Visual Studio. If you want to run it non-locally, you have to use the ClickOnce Trusted Application Deployment model, which entails installation of the application's signing certificate on the client computers. (This has been discussed broadly on the web.)

ScriptInteropDemo.zip

If you must show a WebBrowser control or host any child window (HWND) “in” a WPF window with transparency, here is one workaround technique. The idea is to wrap the native window in a top-level non-WPF one and “float” that window over the area of the main WPF window where the control is supposed to appear, responding to layout and window resizing changes. With appropriate window “styling” and event handling, this can create a pretty good illusion of an actual hosted child window. Of course, you can expect some integration roughness with such a hacky technique, but it may work well enough for you.

So, how is this trick even possible, if child window composition does not work with transparency? (The hosted control/native window is still a child window.) Well, it does work when the “system-managed” transparency mode is used and all windows in the hierarchy use GDI for drawing. Dwayne has a great overview of the two transparency modes supported by Windows and how WPF relates to them. We cannot use a WPF window to host the native control, or we are back to the original problem. The easiest way to create a GDI window with the system-managed transparency/composition is via WinForms. This is what the attached prototype project does. To make that “overlay” window (wrapped by a System.Windows.Forms.Form object) appear as much as possible as a child window of the main WPF window, it has ShowInTaskbar=False and FormBorderStyle=FormBorderStyle.None. Additionally, it has the main window set as its owner. This takes care of minimize+restore behavior and automatically destroys the owned window with the main one.

To define where in the main window the hosted control should appear, we designate a “placement target” element, which could be a border, panel, or some other FrameworkElement. The “overlay” window has to be moved and/or resized in response to the owner window moving or the placement target element moving in layout or getting resized. Since in typical situations the location of the placement target will remain fixed relative to the window borders, responding only to its SizeChanged event is a good optimization. There is no LocationChanged event, and I don’t know if there is any more efficient way to get a notification like this than to handle every LayoutUpdated event (which looks like a per-instance event, but it’s really per layout pass, which can affect many elements across the tree).

If you need the WebBrowser control in particular and you want to avoid the dependence on WinForms, you could use a WPF window as the “overlay” one and WPF’s System.Windows.Controls.WebBrowser, but you have to give up on the browser control being transparent. The attached prototype project illustrates this alternative. (The button at the top of the initial window opens the WPF-based version.)

WebBrowserOnTransparentWindow.zip

I am a Software Development Engineer on the WPF Application Model team. This is the team that brings you the goods of windows, the navigation framework, browser-hosted applications (XBAPs), resource loading, visual add-ins, and a bunch of miscellaneous, mostly infrastructure type of services. Oh, and of course the Application class ;-).

My personal areas are browser hosting/integration, Win32 Interop, and navigation/journaling, so my posts will likely be around these topics. After months of semi-regular participation on the WPF MSDN Forum, I realize I need a more coherent and more easily discoverable repository for various pieces of useful product information and FAQs. And maybe I will throw in an occasional tidbit or good lesson learned from my day to day experience as a developer.

I drew significant inspiration from reading blogs.msdn.com to join Microsoft (which happened a little over two years ago). Now I feel it's an honor to be able to start my own. I'm just not sure how well I'll manage to keep it up. But "nothing ventured, nothing gained", they say. ;-)

We occasionally hear from users (mostly developers) about XBAPs unexplainably failing to start on particular computers. This is troubling news when everything is installed correctly on the system and the XBAP itself is known to be good. There are many pieces involved in XBAP deployment & activation, some of them external to WPF, and only one has to be slightly out of whack in order for the whole process to fail. Unfortunately, there isn't just one known cause, and the failure symptoms are often such that figuring out what exactly is broken is not easy, or just impossible for end users. As a core infrastructure feature, XBAP deployment should be highly reliable. That's why we are trying to identify the top common causes and then implement solutions in the next version/service pack of the framework. To this end, we need feedback from "the real world", where computer configurations vary greatly and OS and software installations are anything but fresh and done in a particular order.

First, whenever you get a Dr.Watson dialog saying the "Windows Presentation Foundation Host has encountered a problem and needs to close", please send the report. (PresentationHost.exe is the process that hosts an XBAP. Even though the application visually runs within the browser's window, it's loaded in a separate process for better isolation and reliability.) This is the best way for us to learn about deployment failures in the field, measure frequency of occurrence, and possibly request additional system information to be automatically sent with subsequent reports of a particular failure. If the hosted application (the XBAP) crashes, the managed exception should be caught and shown formatted in an HTML page, in place of the application's content. The Watson dialog almost always suggests the crash is due to a platform bug or to a critical system configuration problem.

Because currently all managed exceptions are caught and shown in the XBAP error page, we are preventing Watson from reporting failures due to bugs in the managed part of the framework. We'll likely add a mechanism in a future release to enable sending a report of any managed exception. This will help both us and XBAP vendors to improve reliability. Also, in SP1 (and .NET v3.5), a number of possible deployment error conditions and the majority of previously silent failures will trigger a Watson report.

For now, you can just look at the exception call stack shown in the error page and try keyword search using symbols from the top few frames. Solutions for some common causes can thus easily be found.

In particular, errors from ClickOnce are frequently occurring. You can recognize them by the assembly name and namespace - System.Deployment. Here's a sample:

There are certain ClickOnce errors that tend to occur mostly or only on developers' computers, when multiple builds of an application are deployed and in particular when doing so from different locations (URLs) and without incrementing the version number. Then you may have a corrupt ClickOnce application store (cache). To clear it, run this command from an SDK command window: mage -cc and/or directly delete the store folder:

• x:\Documents and Settings\username\Local Settings\Apps - on Windows XP
• x:\Users\username\AppData\Local\Apps - on Windows Vista.

If this doesn't help, you may have a case of a bad framework installation or bad system configuration...

A group of known issues is with NT permissions on certain system objects. The most frequently occurring case seems to be with the HKCU\Software\Classes registry key. The problem, an experimental workaround, and a manual fix are discussed in this Forum post. The gist is that the individual user's account has to be explicitly given Full Control permission. Getting this permission via membership in the Administrators group is not sufficient, because PresentationHost runs with a restricted process token. Similar, mostly isolated, problems have been observed with these objects as well:

• "x:\Documents and Settings\username\Local Settings\Application Data" folder and/or Deployment subfolder
• "x:\Documents and Settings\username\Local Settings\Apps" folder. This is the main storage for the ClickOnce application cache and mage -cc clears it, but it may  not be able to resolve NT permission problems.
• HKCR\Interface\{79EAC9C9-BAF9-11CE-8C82-00AA004BA90B} key

PresentationHost.exe released with .NET 3 SP1 and .NET v3.5 will detect these specific configuration problems, trigger Dr. Watson, and if the user chooses to send a report, we'll present a response page that leads to some patch utility. Unfortunately, for a number of reasons it is not possible to automatically resolve each of these possible permission problems at the time the framework is installed, so we have to rely on this indirect method.

Collecting diagnostic information 

If you have a case of XBAP deployment failure and the XBAP itself is known to be good (runs on another computer, other than the one on which it was built), and you are not seeing the ACL/permission anomaly involving any of the above file/registry objects, then it may be due to a yet-unknown cause, and providing us with specific diagnostic information can help us figure out the cause and possibly address it in a future release. Besides the Windows, .NET framework and browser version information, two types of logs are usually sufficient.

I. From Process Monitor. Set up two filters: 'Process name is PresentationHost.exe'  and 'Process name is iexplore.exe'. (Keep the default filters. They eliminate a lot of noise.) For Firefox, the process name is Firefox.exe. (Note that only v3.5+ will support XBAPs in Firefox.)

[Update, 10/10] It really helps if Process Monitor captures stack traces for logged events. To enable this, ProcMon needs dbghelp.dll v6 or newer. The file path is given to it in the Configure Symbols dialog, from the Options menu. You can get the right dbghelp.dll in at least two ways:

• It's part of Visual Studio: "c:\Program Files\Microsoft Visual Studio 8\Common7\IDE\dbghelp.dll"
• You can download Debugging Tools for Windows.

II. ETW traces. Both IExplore (v7) and PresentationHost are instrumented to trace significant events (when tracing is enabled). Unfortunately, the Windows SDK tools for trace collection and manipulation are not very user friendly. Just for collection, the WPFPerf tool shipped with the .NET Framework SDK suffices.