The Tale of the Obscure Weblog Engine Bug

A couple of days ago I wrote about Oslo in my blog entry Getting started with Oslo – Introducing “M”. It turned out quite a bit of a hassle to get the thing posted for various reasons that make my setup not ideal. Here’s what the battlefield looked like:

A short combat with IntelliMirror. Our network infrastructure allows to set up folder redirection, so that your documents follow you everywhere. However, Windows Live Writer kept claiming the disk was full. I had forgotten where Windows Live Writer stores its stuff (obviously under My Documents which were on the file server), so my reaction was: “can’t be true – I have plenty of space free on my disk”, so I opened up Process Monitor only to conclude Windows Live Writer was honest to me and reminded me in an indirect way I was IntelliMirrored:

And the rest was easy to figure out: I had reached my quota (due to other large Windows Live Writer drafts with lots of pictures).

Convince my network stack to connect to the FTP server to upload pictures. Turned out I didn’t have the ISA Firewall Client software installed yet and our IT department knows how to lock down network access quite well :-). Another time Windows Live Writer wasn’t to blame at all.

But now the final challenge came up:

Let’s spell out the message for search indexing friendliness: “Blog Server Error. Server Error 0 Occurred. Specified argument was out of the range of valid values. Parameter name: The requested index value does not exist”. Hmm, looks like an IndexOutOfRangeException to me, doesn’t it? Yes, it was a pretty complex post in terms of size, number of pictures, etc, but nothing too fancy in there (and It Should Just Work, irrelevant link). The fact the title of the error says “Blog Server Error” told me Windows Live Writer was putting the blame on my blog engine, so I turned my attention to that one. It started to feel like the cloud was letting my down that night :-).

However, I couldn’t really find a clue in the exception logs on the server, so it was about time to train my psychic debugging skills (for various, non-technical, reasons I can’t debug through the source code of the blog engine). Let’s analyze what I’m trying to do: posting quite some text with images in it, but I also added new categories from within Live Writer:

Maybe the server tried to access the new categories and hit an issue doing so (because they were too new or so, you never know). Bummer, deselecting the categories doesn’t fix it. What else? Lots of images in my post, but that has worked before. It should be the text somehow, but I couldn’t yet think about special things in there. So, I started a new post, copying in parts of my original post and try to isolate the problem using divide and conquer (a proven technique). The precise same post without the images still had the problem, so that was assuring. As I started to cut out pieces, I came to the realization there was something different about this post: it had SQL code in it, something almost unprecedented on my blog.

Thinking I was on the right track with a theory about SQL code being the root cause, I removed my SQL fragment and sure it worked fine. So, I started to weed out the duplicate statements (multiple create tables, insert intos, create schemas, etc), and was able to isolate the issue to something like this:

Ultimately I removed everything but the [ Name ] thing (notice how I’m inserting spaces now), and sure it still failed to post. If square brackets somehow are the issue, I thought I should find something about it around the web. I searched and found: Problem with brackets and Date in CS 2, another blogger sharing a technical story in the realm of SQL, with OLAP. I ended up dropping the SQL fragment for now (it was meant to be an introductory post anyway, or how a bug can help you to improve introductory content :-)), but the “fix” was easy: don’t use some special names within brackets.

I’ll apply the real fix soon: upgrading to a new build of the blog software. But for now, I’m satisfied rational thinking (and directed web searches) still pays off when trying to debug through issues. After all, a happy ending!