Microsoft released a HotFix for NETCF v3.5 on Windows Mobile 6.1.4 onwards, to address basic functionalities of WebBrowser control

  • Yet another demonstration of the added value provided by the Technical Support
  • A very impressive example of collaboration between Technical Support and Dev Team
  • FIX is public now (link to KB Article)
  • Update: the fixed CAB is automatically deployed by Marketplace

A few weeks ago I’ve started handling a Service Request coming from a ISV whose NETCF v3.5 Application relied on the WebBrowser control to display a HTML FORM with some links on it… Imagine simply the following form’s code:

 private string m_Html = 
"<html><body>" +
"<a href=\"\">MSN</a><BR>" +
"<a href=\"\">MSN</a><BR>" +
"<a href=\"\">MSN    </a><a href=\"\">MSN    </a><BR>" +
"<a href=\"\">MSN    </a><a href=\"\">MSN    </a><a href=\"\">MSN</a><BR>" +
"<a href=\"\">MSN</a><BR>" +

private void menuItem2_Click(object sender, EventArgs e)
       this.webBrowser1.DocumentText = m_Html;

Problem is that, after the HTML is loaded, when using navigation “buttons” (up\down\left\right):

  • On WM6 I can navigate through the links: this is the expected behavior… and when pressing the action button the control navigates to the href link.
  • On WM6.1.4 the whole page is moved instead; and when tapping on a link, nothing happens (the expected behavior was that the control navigates) apart from “giving focus” to the link: at this point even if you press the action button the control doesn’t navigate
  • On WM6.5 the behavior is similar to 6.1.4’s, and here even horizontal and vertical scrollbars don’t appear

The problem is easily reproduced on the Emulators as well, thus demonstrating that the issue is not OEM-ish…

I also found at least 2 other developers reporting the problem through Microsoft Connect:

Troubleshooting steps included verifying which native control is wrapped by the NETCF v3.5’s WebBrowser: I noticed that when using the NATIVE code Mike Francis provided in his blog post (code sample available here), then I get the desired behavior on all the 3 Emulators. Mike’s code is based on the WM6’s SDK Sample named “Browse” (\Samples\CPP\Win32\Browse\browse) and explains how to add gesture- and selection-support to a native application hosting the NATIVE web-browser control.

So, the problem was just with the NETCF v3.5’s WebBrowser here! And interestingly it’ NOT reproduced with NETCF v2 SP2 that ships in-ROM on WM6.x. So… what are the loaded DLLs (i.e. what is the native control wrapped by the NETCF v3.5’s WebBrowser)? And which Windows? [I was intereseted on Windows’ ClassNames due to a possible technique to customize the WebBrowser’s context-menu, which I discussed here]

using NETCF v3.5 WebBrowser




WND ClassName PIEHTML Internet Explorer_Server Internet Explorer_server
Loaded DLL webview shdocvw shdocvw


using Native Control (Mike’s code)




Loaded DLL webview + htmlview webview + htmlview webview + htmlview


To recap: the issues are due to the NETCF v3.5’s WebBrowser control loading the new native IE6on6 (shdocvw.dll) instead of relying on the native webview.dll + htmlview.dll, and this makes impossible for the user to (a) click a href link and (b) to navigate through them by using the up\down\left\right pad. Also, (c) on 6.5 the scrollbars are not created. When loading the same HTML by the same NETCF application on a WM6, the behavior is as expected. There’s NO problem on WM6.1.4 and 6.5 when using the native control directly (htmlview.dll and webview.dll), for example through the WM6 SDK Sample \Samples\CPP\Win32\Browse\browse.

What happened at this point? As I mentioned other times (for example here), one of the added values provided by Technical Support is that we have a channel to the Dev Teams which we can use to advocate final users’ needs. You can imagine how many customers the Technical Support reaches every single day: we’re basically one of the ears of the Product Groups. And also this time I received an impressive collaboration from  the NETCF Dev Team, which firstly accepted to package the FIX, and then did it in a very few days: this is not the usual way it works, so if you’ll ever request a fix then don’t expect this in general. As you can imagine this depends on the code that needs to be modified, in terms of both the complexity and the possible regression risks that a modification introduces, compared to the risks of application usability and other factors if the fix is not provided. For example, many times developers and users can accept a “workaround” while waiting for next version of the product or the possible next Service Pack – I’ve discussed about an example of this here.

To conclude: a FIX is ready to be asked to the Technical Support. KB Article is:

FIX: You cannot scroll through a Web page or browse to a link by using a .NET Compact Framework 3.5-based application that hosts a WebBrowser control in Windows Mobile 6.1.4 and 6.5

For the time being it’s a separate hotfix, maybe the Dev team will consider packaging it within a Service Pack – this is not yet decided. This is another demonstration of a kind of historical change, as this is just the second separate hotfix provided for NETCF on Windows Mobile-based OSs. First one was release few months ago and I blogged about it here.

A question may arise: can ISVs distribute the FIX? I mean, imagine I’m an ISV and developed a NETCF v3.5 app based on the WebBrowser control: if I want to make my app usable on WM6.1.4 and 6.5 devices of my clients, do I need to ask each of them to open a Service Request to Microsoft asking for the hotfix? The answer is: ISVs can distribute also the “patched” NETCF’s CAB.


<UPDATE date=”February 4, 2010” topic=”redist of the fix”> At the time I wrote this post, Marketplace was not yet opened so I didn’t mention an interesting detail regarding the distribution of the fixed NETCF v3.5 CAB: well, if you use Marketplace to distribute your application, then you don’t need to worry about the fixed CAB of the NETCF, because Marketplace will distribute the most updated Build of the NETCF runtime your application targets, accordingly also to the Application Submission Requirements for Windows® Marketplace for Mobilewhose point “7.4. Restriction on .NET Compact Framework Redistribution” states:

Application providers should not include the .NET Compact Framework (.NET CF) redistributable package with their applications. The Windows Marketplace installation process will ensure that either the .NET CF 2.0 or .NET CF 3.5 runtime is installed on the device as required.

I did a quick test with a freeware application I knew was built for NETCF v3.5, on a WM6.5 Emulator (so just hard-reset with only NETCF v2 “in-ROM”) – note the user-friendly process (I grayed the portions naming the application becasue I’m sure there are many others out there based on NETCF v3.5 Open-mouthed):


When the download\install finished, just to verify which exact Build of the NETCF v3.5 was installed, I’ve run \Windows\cgacutil.exe and could see that, at today, the Build is 3.5.9198, which is precisely the one mentioned in the KB Article I’ve mentioned above:



WARNING! Remember that analogously to every other hotfix you can ask to Technical Support about whatever Microsoft’s product, you should install it only if you're sure it’s for the problem you're being affected by. This is because a hotfix is meant to address a specific issue and has been tested precisely for that: it didn't go through the whole regression testing that it's usually done when packaging many hotfixes into a Service Pack. In this precise case, you don’t have to install this hotfix if your NETCF v3.5 applications doesn’t use the WebBrowser control.