The Windows Home Server Data-Corruption Bug (2007–2008): What Happened

For a product whose one job was to keep a household's photos, documents and backups safe, few bugs could have been worse than one that corrupted the very files you trusted it with. Yet that is exactly the problem that shadowed the first release of Windows Home Server in its opening year. This is a look back at what the bug was, why it mattered so much, how Microsoft handled it, and what it still teaches anyone building or buying a system that pools storage across several drives.

What Windows Home Server was supposed to do

Windows Home Server (WHS) was Microsoft's first serious attempt at a consumer home server: a small, always-on box, usually headless, that sat in a closet and quietly did the unglamorous jobs a household never gets around to. It ran automated nightly image backups of every PC in the house, published Shared Folders over the network for music, photos, videos and documents, and offered remote access to those files from outside the home. It was sold both as software for build-it-yourself machines and pre-installed on turnkey appliances from hardware partners.

The feature that made it distinctive was Drive Extender. Instead of asking a non-technical user to understand RAID levels, drive letters or volumes, Drive Extender presented every hard drive you added — of any size, added at any time — as one growing pool of space. You could tick a box to have a shared folder duplicated, and Drive Extender would keep a second copy of that folder's files on a different physical disk, so that losing any one drive did not lose the data. To make all of that work, the server was constantly, silently shuffling files between disks in the background: balancing free space, and creating or refreshing duplicate copies. That background movement is the heart of this story.

The bug: corruption during background storage movement

The problem appeared in a narrow but very real set of circumstances. If you opened a file that lived on a WHS share and edited it in place — that is, working on it directly across the network on the server rather than on a local copy — and Drive Extender happened to be migrating or duplicating that same file in the background at that moment, the file you saved could come back corrupted. In effect, two things were writing to the same data at once: the application saving your changes, and the server relocating the file. When their timing overlapped, the result could be a damaged file.

Why certain applications, and not others

The trigger was not simply "editing a file." It was tied to how an application reads and writes. Programs that open a file and hold it open, writing to it repeatedly or in place over the course of a session — rather than writing out a complete new copy and replacing the old one in a single step — were the ones exposed to the race. That pattern is common in media libraries that update embedded metadata, in some database-style or personal-finance files, and in other applications that keep a working file open and mutate it as you go. Microsoft's support article named the programs it had confirmed could trigger the problem — Windows Vista Photo Gallery, Windows Live Photo Gallery, Microsoft Office OneNote 2007 and OneNote 2003, Microsoft Office Outlook 2007, Microsoft Money 2007, SyncToy 2.0 Beta, Intuit QuickBooks and uTorrent — while noting that users had reported the same behaviour with other applications it was still investigating. The honest, durable description, though, is behavioural rather than a fixed roster: the danger was the "keep the file open on the share and edit it in place while the server rebalances" pattern.

Crucially, this was a software defect, not failing hardware. A brand-new server with perfectly healthy disks could still produce a corrupted file, because the fault was in the coordination between Drive Extender's migration and the application's writes — a race condition — not in any single component going bad.

What the original Windows Now post said

Doug Knox's short note on the original windows-now.com flagged this for readers as soon as Microsoft documented it. He pointed to a Microsoft Knowledge Base article — KB 946676, first published in December 2007 — under the plain-spoken heading that when certain programs are used to edit or transfer files stored on a Windows Home Server-based system that has more than one hard drive, the files may become corrupted. The value of that early note was simply awareness: it told owners, before they lost anything, that the safe-storage box had a condition under which it was not yet safe.

Why this was so serious

Most software bugs are an inconvenience. This one struck at the product's entire reason to exist. People bought a home server precisely so they would stop worrying about losing files — so they could point the family's irreplaceable photos at it and trust the duplication feature to protect them. A defect that could damage those files, quietly, during the server's own routine housekeeping, undermined the core promise. It was also insidious in two ways. First, corruption could be silent: a file might look fine in a listing and only reveal its damage when you next tried to open it, possibly long after the fact. Second, because duplication and backups were part of the pitch, some users assumed a second copy would save them — but if the corruption occurred at save time, both the working file and anything derived from it afterward could carry the damage forward.

For a young product still earning trust, and for the hardware partners who had staked appliances on it, the reputational stakes were high. Enthusiast forums lit up, and the issue became one of the defining early talking points of the platform.

How Microsoft responded

To its credit, Microsoft did not stay quiet. Its response came in the sequence you would want to see for a data-integrity issue:

• Acknowledgement. Microsoft documented the problem publicly in a support article rather than downplaying it, describing the conditions under which corruption could occur and which kinds of programs were implicated.
• Interim guidance and workarounds. While a proper fix was developed, the practical advice was to avoid the exact pattern that triggered the race. In broad terms that meant: don't edit the affected files in place directly on the share. Instead, copy a file down to a local PC, edit it there, and copy the finished version back — so that the server only ever received a complete file to store, not a live one being mutated mid-migration. This was inconvenient, but it removed the overlap that caused the damage.
• A code fix in a later update. The lasting resolution shipped as part of a Windows Home Server Power Pack 1, the first of the cumulative service updates Microsoft used to roll out major fixes and features for the platform. Once that update was installed, the underlying race between Drive Extender and in-place editing was addressed, and the earlier "edit locally, copy back" workaround was no longer necessary.

The episode is often cited as a case where the handling — acknowledge, mitigate, then truly fix — was reasonable, even though the bug itself should never have shipped in a storage product.

The present-day takeaway

Windows Home Server itself is long discontinued, and Drive Extender was eventually dropped from the platform's later direction entirely, so there is nothing here to patch on a machine you run today. What endures is the lesson, and it is a sharp one for any system that pools or tiers storage — from later Microsoft technologies to today's home NAS boxes, drive-pooling utilities and cloud sync clients:

• Silently moving data is a promise, not a convenience. The moment a system relocates files in the background, it takes on responsibility for what happens when an application is writing to those files at the same instant. That concurrency has to be provably correct, not merely likely to work.
• "It has redundancy" is not the same as "it is safe." Duplication and RAID protect against a drive dying. They do not, on their own, protect against a file being corrupted at the moment it is written. Genuine safety needs correct write handling and redundancy and real backups that are periodically tested by actually restoring from them.
• Test the mundane middle case. The WHS bug did not need exotic conditions — just an ordinary file, edited in an ordinary app, while the server did its ordinary housekeeping. The most dangerous bugs often live in the overlap of two features that each work fine alone.

Seen from the present day, the Windows Home Server data-corruption bug is less a cautionary tale about one dead product and more a durable reminder: when software takes custody of your files and moves them around on your behalf, the burden of proof for correctness sits with the software, every single time it writes.