F12Chooser: Amazing New Tool for WinForms Application Hosting Web Browser Control

Earlier we talked about how to debug JavaScript remotely from Internet Explorer and any other process. If you haven't read the post, then here are the links.

http://blogs.msdn.com/b/prakashpatel/archive/2015/10/23/vs2015-remote-debugging-javascript.aspx

http://blogs.msdn.com/b/prakashpatel/archive/2015/11/04/vs2015-remote-debugging-javascript-part-2.aspx

VS2015 is great for debugging remote applications (or processes). It gives me a lot of power. I can debug applications deployed in QA, testing, staging, integration etc. environment where I can't install Visual Studio. What if I want to debug memory leak issues on one of those machines? F12 comes to rescue for sure but what if the application is a WinForms application hosting Web Browser Control? Well, I pretty much run out of options. DebugDiag can help me identify where the leak is but without the access to private symbols, you may not be in luck. You'll have hard time trying to find JavaScript memory leak. If you have been in this situation before then you'll appreciate the new tool F12Chooser that ships with Windows 10.

To know more about F12 Tools please read Using the F12 developer tools MSDN article.

• Inspect running JavaScript with the Debugger
• Diagnosing memory problems in your webpages

Download Links for Source Code and Sample Application

In this simple demo, I'm using a WinForms MDI application. We'll open two forms and debug them. You can download the sample application and source code here. This application has simple modifications made to the previous demo. Basically, I have converted it to an MDI application.

1. TestApp2.exe
2. TestApp2.zip
3. TestLeak.html
4. TestLeak2.html
5. TestApp.zip (for previous blog)

Debugging WinForms Application Hosting Web Browser Control

1. I'll start a sample app named TestApp2.exe
2. Click File à New Form to open a child window
3. Open TestLeak.html file inside it. You can simply drag file on to the web browser control and it will navigate to it.
4. Click File à New Form to open another child window
5. Open TestLeak2.html file inside it. You can simply drag file on to the web browser control and it will navigate to it.
6. Click Window à Tile Horizontally so we can see both windows clearly.

    

7. Now, open C:WindowsSysWOW64F12F12Chooser.exe or C:WindowsSystem32F12F12Chooser.exe application. The choice would depend on whether your application is running as 32-bit process or 64-bit process.

    

8. Click on the tile displaying TestLeak.html. You'll see the familiar F12 window. Now the business is as usual.

    

9. Insert a break point on the onclick method of TestLeak.html. Click on Throw an error button and it will break into the F12Chooser (rather F12) debugger.

    

10. If you click on the Console tab, you'll see the error we just encountered.

     

11. An awesome thing you may have already noticed here is that I can debug each form independently. In other words, I can attach more than one F12Chooser debugger to one process. In the above example, I can debug both TestLeak.html WinForm and TestLeak2.html WinForm at the same time.
12. You can do all cool things you do with F12 tool. For example, changing the document mode or user agent string and testing the behavior.

     

Debugging Memory Leak in WinForms Application Hosting Web Browser Control

Steps 1 through 6 are same as previous. In fact, if you read previous section then skip to step 7

1. I'll start a sample app named TestApp2.exe
2. Click File à New Form to open a child window
3. Open TestLeak.html file inside it. You can simply drag file on to the web browser control and it will navigate to it.
4. Click File à New Form to open another child window
5. Open TestLeak2.html file inside it. You can simply drag file on to the web browser control and it will navigate to it.
6. Click Window à Tile Horizontally so we can see both windows clearly.
7. Now, open C:WindowsSysWOW64F12F12Chooser.exe or C:WindowsSystem32F12F12Chooser.exe application. The choice would depend on whether your application is running as 32-bit process or 64-bit process.

    

8. This time select LeakTest2.html instead of LeakTest.html. Select memory tab. You'll be surprised to see that you can't trace memory leaks with this application.

    

9. Important Note: Even though you have IE11 version, the page is still rendered in IE7 mode. Web Browser Control by default renders page in IE7 mode. This is mainly for compatibility reasons as a lot of intranet sites within corporate may have broken if rendered in Edge mode. I'll blog about other details later on but there are different ways to force edge mode instead of default IE7 mode. You may find quite a few articles as well.

    

10. So let's change the document mode to Edge and then come back to the Memory tab.

     

11. Click on Start Profiling button or press Control + E key combination.

     

12. Take snapshot of the memory

     

13. Click on Start Memory Leak button and then after 4-5 seconds, click on Stop Memory Leak button.

     

14. Take another memory snapshot in the F12Chooser window.

        

     

15. Compare the two snapshot, by right clicking on one of the snapshot and selecting the other one as shown. Or you can simply clicking on the difference icon.

     

     

16. If you'll select one of the string that has leaked, you'll see that it is rooted in a global array

     

17. Similarly, the div elements are rooted inside the DOM

     

18. I'm not going into the details of debugging memory leak as Diagnosing memory problems in your webpages article covers it really well. It gives you step by step instructions on how to do that.

     

19. One of the changes we made to F12Chooser tool was that it would display process id so you can identify the correct process. I'll check on it and update you what I find, maybe I have an old version!

     

Summary

• F12Chooser ships with Windows 10 and it allows you to harness the power of F12 on any process.
• You can debug IE, Edge, Web Browser Control hosting applications and many other processes as well.

• It looks like Edge is doing a good job of reducing memory pressure here. It uses a a completely new parsing engine for DOM.