Unfathomable Bugs #1: You can have things! You can have things IN things! You ca...

Unfathomable Bugs #1: You can have things! You can have things IN things! You can have …

This is the first post in a series about bugs you can’t avoid, can’t predict, and can’t even diagnose without significant time investment. Bugs that aren’t your fault, because they are in your tools. The bane of time estimates and deadlines, the unfathomable bug.

Today’s bug comes courtesy of Microsoft. Thank you, Microsoft, this series wouldn’t exist without the generous support of entities like you.

(Side note: This is not meant as a jab at Microsoft. It’s just what I intend to be the standard intro line. This side note may self-destruct.)

Windows 8 RTM and Visual Studio 2012 RTM were finally available for download. I had downloaded them, installed them, and even finished fixing the new compiler errors that were preventing our windows 8 solution from building. Things were going relatively smoothly. I could tell a lot of things had been fixed by the RTMs, because some spurious compiler warnings were gone. I ran the solution, expecting good things. It immediately crashed. No compiler errors or warnings, just an immediate crash.

The first indication that something was terribly wrong was the location of the crash. The program had not failed in our code, but inside code generated by Visual Studio’s XAML designer. The code appeared to be responsible for loading an instance of the control by parsing the control’s XAML asset, but otherwise there was no hint at the underlying issue.

As is standard for this type of situation, I started coming up with guesses, testing them, and eliminating possibilities. This stage lasted for some time, until there was actually nothing left on the control. It was just a blank control… that crashed as soon as I ran the solution. I even removed other projects from the solution, until I had a single project with a single control with no contents… that crashed as soon as it ran.

I was certain something was wrong with visual studio or windows. I started writing up a bug report for Microsoft, but when I tried to repro the issue with a new project, it didn’t crash. … what?

At this point my best guess was that the project was somehow tainted. In the past I’ve worked around “unfathomably tainted projects” by copying content out of a tainted project into a fresh new project. I tried doing so and it even seemed to be working, until the copying was almost complete and the fresh project started crashing too. The taint was infectious. Not a good sign. But, determined, I tried a few more variations of “move contents out of tainted project into untainted project”, failing each time, until I finally got lucky and noticed a difference between a blank control in a tainted project and an untainted project: the tainted control had a long namespace, like “org.project.component”, instead of “NewProject1″. Changing the namespace made the issue go away.

A few more minutes and I had it nailed. If a control in a windows runtime component project is in a triply nested namespace, like “n1.n2.n3″ or “a.b.c”, then it will fail inside its InitializeComponent call at runtime. Entire projects could be “tainted” by their default namespace, which I had been doing without realizing the implications. AUGH!

With the bug fixed, I confidently ran the project and… ran into content for my next unfathomable bug post.

Comments are closed.

Twisted Oak Studios offers consulting and development on high-tech interactive projects. Check out our portfolio, or Give us a shout if you have anything you think some really rad engineers should help you with.

Archive