Tag Archives: Microsoft

Microsoft mechanism to load WPF resources is broken. (looking for a better title)

I’ve been using WPF along with .NET and have been a staunch supported of the technology for years now. The pattern of separating presentation from logic gained a lot of traction. Technologies such as iOS’s cocoa touch, JavaFX and others follow same model. Even HTML5 forced all the pure presentation/layout markup out from HTML and into CSS. So the idea is sound. But what about execution.

WPF implements this pattern using XAML. XAML markup is used to design the visual this xaml is stored in the xaml file, whose name usually matches the name of the class. For example, MyWindow.xaml. During compilation, an auto-generated file marries the code that defines the visual (MyWindow.xaml.cs) and the xaml file itself (MyWindow.xaml.cs). The autogenerate file would be named MyWindow.g.i.cs and it would contain the implementation of the InitializeComponent() method that’s referenced in the main MyWindow.xaml.cs class. The contents of the method looks something like this:

[System.Diagnostics.DebuggerNonUserCodeAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("PresentationBuildTasks", "4.0.0.0")]
public void InitializeComponent() {
	if (_contentLoaded) {
		return;
	}
	_contentLoaded = true;
	System.Uri resourceLocater = new System.Uri("/MyLibrary;component/mainwindow.xaml", System.UriKind.Relative);
	
	#line 1 "..\..\MainWindow.xaml"
	System.Windows.Application.LoadComponent(this, resourceLocater);
	
	#line default
	#line hidden
}

So far so good right. OK, let’s talk about some of the advanced uses of .Net. Specifically support for having multiple versions of same assembly (dll) to be loaded in a single AppDomain. Such use case comes handy in a framework use case. A framework supports multiple plug-in modules, each can be developed by other developers who may rely on different versions of common libraries. I am not talking about things like log4net, I am talking about shared assemblies that define common logic and can be reused by each module. If 2 modules are loaded into a single app-domain and both depend on their ‘private’ version of the common assembly, a good framework should not force both modules to share latest version of the library, because

  • ‘latest’ does not mean backwards-compatible
  • ‘latest’ may have bugs that ‘earlier’ version did not
  • …I can go on for a while on this one. It’s 2014, dll hell is well known to software developers of the 20th century.

Now, let’s say that 2 different versions of the shared library called MyLibrary are loaded and one version is used by Module1 and another version is used by Module2. During compilation, assembly name along with the version are recorded in modules’ manifests so that when .NET encounters request to execute code defined in MyLibrary the source module will tell .Net which version of MyLibrary contains the code it wants executed. This is a basic building block of .NET and a very attractive feature.

Now, what about WPF? Well that’s not that clear is it? Look at Line #8 above: System.Uri resourceLocater = new System.Uri(“/MyLibrary;component/mainwindow.xaml”, System.UriKind.Relative). It defines what it calls a resourcelocator which the system will use to find the xaml resouce in an assembly called MyLibrary. I don’t know how WPF resolves the assembly, but if I were to write the logic for resolution, I would not have enough information to find a proper assembly MyLibrary, because I don’t know which version to load. I would have to guess. And as we know in any science guessing is bad. Computer Science is an exact… well… science. Guessing, hoping, holding fingers crossed or other techniques that do not produce determinate result will break at the worst possible moment! I can see how developers armed with inaccurate knowledge or with little experience make mistakes like this, but when Microsoft’s tools generated code that’s faulty, and make it impossible to intercept and fix, there is no other way to call it – they fucked up! How can they expect developers to trust their tooling if they, themselves, auto-generate code that sometimes breaks.

This breaks in a most bizarre way, too. MyLibrary version 2 was loading the MainWindow class, which then was running the InitializeComponent() method above, encountered the LoadComponent call, which asked to load the resource from the MyLibrary assembly without a version, and the code picked the wrong version of the MyLibrary assembly, which did not have the MyWindow class, nor the resource. What a way to blow up!

Such nonsense was reported to them too! This connect ticket marked as “Wont’t Fix” describes the problem: https://connect.microsoft.com/VisualStudio/feedback/details/668914/xaml-generated-code-uses-resource-uri-without-assembly-strong-name. StackOverflow also has references to this problem: http://stackoverflow.com/questions/1453107/how-to-force-wpf-to-use-resource-uris-that-use-assembly-strong-name-argh/6341678#6341678. Luckily one of the suggestions led me to the best solution.

The Fix


We were lucky to have our builds automated via scripts which rely on MSBuild to build the solutions. All I needed to do is to modify the script and pass the /p:AssemblyInfo=$version parameter to MSBuild. (http://stackoverflow.com/a/26689750/195275). This would tell the build system to add assembly version to the Resource reference in line 8. It now looks like the code below. Problem solved, but could have been avoided on the first place!

Shame on you, Microsoft!

[System.Diagnostics.DebuggerNonUserCodeAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("PresentationBuildTasks", "4.0.0.0")]
public void InitializeComponent() {
	if (_contentLoaded) {
		return;
	}
	_contentLoaded = true;
	System.Uri resourceLocater = new System.Uri("/MyLibrary;V1.0.23;component/mainwindow.xaml", System.UriKind.Relative);
	
	#line 1 "..\..\MainWindow.xaml"
	System.Windows.Application.LoadComponent(this, resourceLocater);
	
	#line default
	#line hidden
}

What is Runtime Broker and why does it eat memory for lunch?

It started happening soon after I got my Surface.  I started noticing that it would slow down considerably.  I began rebooting it just to get it back to its happy, snappy state.  I decided to dig a little deeper.  Because WinRT is, basically, Window 8 compiled for the ARM processor, I can use familiar Windows tools, like Task Manager to look under the hood.

I sorted by Memory in descending order like this:

TMSortByMemory

and noticed that the top offender was a process called “Runtime Broker”.  I started a thread about this on the forums and soon learned that the Runtime Broker process is responsible for ensuring that the new Windows Store Apps behave.  But there was no explanation as to why its memory consumption grows over time.  Someone mentioned that  a misbehaving app can cause the Runtime Broker process to bloat, but there was no indication as to which app that was.

Recently, my thread was updated with a more detailed information.  Apparently, one of the early-released clock apps has a bug which causes Runtime Broker to grow in size like that, and it does not only affect Surface, it affects any Windows 8 PC running the rogue clock app.

So uninstalling the app worked. My Broker Manager never grows beyond its normal memory size of under 10MB and Surface runs well. But can we really blame the App Developer for this? The answer is a definite No. AFAIK a good operating system isolates processes in such a way that one process cannot cause others to suffer. But this is exactly what’s happening here. I am not sure whether Microsoft knew about this problem before they released Windows 8, but if they did, they should have been a lot more vigilant in their App approval process in order to block any such rogue app from making it into the Windows Store. This is a serious FAIL on Microsoft part. It shows that not only were they in a hurry to release Windows 8 and in haste missed a few critical issues, but they also were or are very lax in their app approval process, as they a aim for quantity, not quality of the app. This is not going to help them in the long run. I hope they adjust their strategy, at least on the app approval part.

My Support Thread:http://answers.microsoft.com/en-us/windows/forum/windows_rt-performance/runtime-broker-uses-too-much-memory/9484a1bc-b302-4451-af7d-a2db4f266b2e

Similar Thread: http://answers.microsoft.com/en-us/windows/forum/windows_8-performance/what-is-runtime-broker-and-why-does-it-use-so-much/44cf8012-3d0f-48fb-8802-100fb88143b2

PS.  I ended up in this situation because Windows 8 does not display a clock in it’s Modern Start menu, a normal main window when running Windows on a tablet.  I referred to this as a major omission in my earlier blog. This is, IMHO, a big deal