The same bug, five times: offline network locations

One bug class caused every freeze DeskDrawer has ever had. It was fixed in five separate releases before the pattern was fully understood.

If you had asked me after 1.1.4 whether the freeze problem was solved, I would have said yes. I would have said it again after 1.2.2, after 1.2.3, and after 1.2.4.

It shipped again in 1.2.5.

The bug class#

On Windows, a file-system call against a location that is unreachable does not fail quickly. It blocks until the network stack gives up, which can be tens of seconds. Make that call on the thread that pumps window messages and the entire application stops — no repaint, no clicks, and distinctively, no mouse wheel, because wheel messages queue behind the blocked call like everything else.

A desktop organizer is unusually exposed to this. Desktops collect shortcuts to network shares, mapped drives that are only sometimes present, VPN paths, and NAS folders that sleep. Every one of them is a call waiting to block.

The five occurrences#

Each was a real fix. None was the last one.

Why "move it to a background thread" was not enough#

The first fix was the obvious one: move info-tip resolution off the interface thread. Correct, and it solved the reported symptom completely.

It did not generalize, because the problem is not one call site. It is that a large number of ordinary-looking operations end in a file-system call, and the dangerous ones are not obviously dangerous when you read them. Resolving an icon reads the file. Building a tooltip reads the file. Deciding whether a drop target is a folder reads the file. Deciding whether a drag should copy or move reads the file, to find out which volume it is on. None of those look like network code.

1.2.4 is the clearest example. The shortcut pointed at a local path, so it passed every "is this remote?" check — but that local path was a symbolic link that redirected to an offline share. The remoteness was one level of indirection away, and every check was looking at the wrong level.

1.2.5 is the other shape of it. The Recycle Bin query was not about a file the user had touched at all; it asked Windows about the bin across every drive, which includes mapped network drives. A sleeping NAS in a drive letter you had forgotten about would stall the application when you deleted an unrelated desktop file. The fix was to scope the query to local fixed drives.

What actually changed#

The rule stopped being "move known-slow calls off the interface thread" and became:

The interface thread never touches the file system. Not for icons, not for tooltips, not for drop-target tests, not for volume checks, not for Recycle Bin state. If a code path on the interface thread ends in a file-system call, that path is a bug, whether or not anyone has reported a freeze from it.

That is a stronger and much less comfortable rule, because it condemns code that currently works. It is also the only version of the rule that generalises, since the whole difficulty is that you cannot tell by reading whether a given path will be fast.

The uncomfortable part#

Five releases is not a story about one difficult bug. It is a story about repeatedly fixing the instance in front of me instead of the class behind it, and being satisfied each time because the reported symptom went away.

The reported symptom going away is very weak evidence that a bug class is closed. It mostly means nobody has hit the next instance yet — and with no Telemetry in this product, "nobody has reported it" is even weaker evidence than usual. See Shipping with no telemetry, and what it costs.

If DeskDrawer freezes on your machine, it is almost certainly this, it is almost certainly a path I have not found, and the report genuinely matters. Troubleshooting has the diagnosis steps.