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.

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.

Older Posts

• Eventual Exceptions vs Programming in a Minimal Functional Style
• The Mystery of Flunf
• Explain it like I’m Five: The Socialist Millionaire Problem and Secure Multi-Party Computation
• Computer Science Blows My Mind
• A visit to Execution Labs in Montréal
• Transmuting Dice, Conserving Entropy
• Rule of Thumb: Ask for the Clock
• Rule of Thumb: Use Purposefully Weakened Methods
• Rule of thumb: Preconditions Should be Checked Explicitly
• Intersecting Linked Lists Faster
• Mouse Path Smoothing for Jack Lumber
• My Bug, My Bad #2: Sunk by Float
• Repeat Yourself Differently
• Grover’s Quantum Search Algorithm
• Followup to Non-Nullable Types vs C#
• Optimizing Just in Time with Expression Trees
• When One-Way Latency Doesn’t Matter
• Determining exactly if/when/where a moving line intersected a moving point
• Emulating Actors in C# with Async/Await
• Making an immutable queue with guaranteed constant time operations
• Improving Checked Exceptions
• Perishable Collections: The Benefits of Removal-by-Lifetime
• Decoupling shared control
• Decoupling inlined UI code
• Linq to Collections: Beyond IEnumerable<T>
• Publish your .Net library as a NuGet package
• When null is not enough: an option type for C#
• Unfathomable Bugs #5: Readonly or not
• Minkowski sums: examples
• My Bug, My Bad #1: Fractal Spheres
• Working around the brittle UI Virtualization in Windows 8
• Encapsulating Angles
• Unfathomable Bugs #4: Keys that aren’t
• How would I even use a monad (in C#)?
• Useful/Interesting Methods #1: Observable.WhenEach
• Unfathomable Bugs #3: Stringing you along
• Anonymous Implementation Classes – A Design Pattern for C#
• Tasks for ActionScript 3 – Improving on Event-Driven Programming
• Minkowski sums and differences
• Non-Nullable Types vs C#: Fixing the Billion Dollar Mistake
• Unfathomable Bugs #2: Slashing Out
• Script templates and base classes
• Unity font extraction
• Abusing “Phantom Types” to Encode List Lengths Into Their Type
• Constructive Criticism of the Reactive Extensions API
• Quaternions part 3
• Quaternions part 2
• Quaternions part 1
• Coroutines – More than you want to know
• Asset Bundle Helper
• The Visual Studio goes away
• .Net’s time traveling StopWatch
• Polish
• Introducing Catalyst