There's a new version of Q824704 at the URL below:

Download details: XPE QFE Rollup, Summer 2003

Let me tell you, this one was a bit of a surprise, but looking at it in reverse, it's understandable. Here's the story...

Normally, I author all the QFE's. To do this, I grab versions of the SLD's we use to build our main database, make the modifications, and send them off for testing. This one was a little different - someone else actually made all the changes to the components. Instead of grabbing SLD files used to build the DB, she grabbed the SLD files that were provided by the other MS teams.

For better understanding, you need to know about cooked and uncooked components. When a feature team gives us a SLD file, it has the files, registry keys, and FBA resources already in it, and maybe some file dependencies. We put those SLD files through a process we call cooking, which (among other things) resolves all the file dependencies into component dependencies. Those cooked components are what we bring together to build the XPE database, and what I use to build QFE's.

Since uncooked components were used to make this particular QFE, the fact that some of those components had been QFE'd previously was missed. When we test, we test the QFE alone to make sure it doesn't screw anything up - if we tried to test every combination of QFE's together, we'd never ship anything. So, when the QFE was ready to ship, it was already conflicting with existing QFE's (Q328310 and Q814078). By conflict, I mean we had two different components with the same revision number, but different GUID's and resources. Whatever got added last won, which meant you'd be missing part of a QFE somewhere - definitely bad ju-ju.

Anyway, to fix it, I took the previously QFE'd components from Q328310 and Q814078, made the changes that were needed from Q824704, bumped the revision, and sent it off for retest and publishing. We're in the middle of implementing a new QFE process that should eliminate this problem, using components in a master XPE database as source for QFE authoring and testing. This one just fell through the cracks. On the bright side, it's the first and only screw-up of it's kind we've had, and the post-mortem on the issue was done before I could get the component re-authored and off to test.

And that's what we like to call a small part of QFE Hell (TM).

OK, there's now an XPE version of MS03-039 ready for download at the link below.

Download details: Windows XP Embedded with SP1 (824146)

And for those of you who wonder why it takes so long to get QFE's otherwise, and why this one showed up the next dat from the Pro release, that's my next story....

Heads up - there's a new RPC QFE on it's way. The XPE version is coming within a few days, but you might wanna get your desktop systems prepped now.

Download details: Security Update for Windows NT 4.0 Workstation (KB824146)

Quick update this morning - Sean Liming's new book on Windows XP Embedded is available via Barnes and Noble at the link below. It's a good book - I've read it (helped review it as it was being written), and it's a much more complete treatment of XPE than the Cseri book.
Barnes & Noble.com - Windows XP Embedded Advanced

Perhaps the best place to really start with XPE QFE's is to go over, as best I can, the QFE process from my point of view.

Most QFE's don't start with the Embedded team - they start with the Windows team. There are exceptions, but for the purpose of argument, we'll assume every QFE published for XPE starts with bits patched for the Windows XP product. I routinely author security builletins, available through the MSDN Security Bulletins page and Windows Update.

QFE packages for the desktop contain two very important things - a set of patched files, and an INF file that direcs the live installation of those files. The INF also contains registry keys that are needed by the patch. This INF tells me which files need to be updated and which registry keys need to be added to an XPE runtime to implement the QFE.

From there, I go a'hunting - I find the components that own the updated files and registry keys. In some case, no component owns the registry keys - most QFE's come with a set of tracking registry keys which need to be added to the runtime. Once I've identified the components, I find the original SLD files we used to build the database and update them.

The updating process is fairly straight-forward, but a little confusing. First, the components have certain metadata changes made to help us ID the new component as a QFE, like the name, version, revision, and additional extended properties. The repository is also changed to point to the SP1 QFE repository found in Q811279. A new package for the QFE components is created in Component Designer to give us a quick way to remove the QFE later.

Once that's done, I rename all the patched files, prefixing them with the QFE number. This is to avoid any file name collisions with the older, unpatched files already in the SP1 repository. Then I change the Source Name property of the file resources representing the patched files to reference the new name.

The new registry keys are somewhat tougher - if there is more than one component being affected by updated files, I need to pick one component to hold the new keys. Sometimes it's easy, sometimes not, but it always gets done. Updated registry keys are much easier - just change the keys in the owning component.

With all that done, it's time to package everything up into an installation package. We developed an installer for XPE QFE's that automagically imports all the components and copies the files into the SP! QFE repository. It's driven by it's own INF file, which needs to be written. The the whole thing gets tested twice - once by me, and once by our stellar Test team. We also loop in the testers for the feature being updated to help us make sure the functionality works as expected on our runtimes.

Once everything is fully tested and has everyone's OK, I digitall sign the executable package and publish it to the Microsoft Download Center. Once it's published, I send that info to our web masters for inclusion on the Microsoft Embedded web site.

That's about it - pretty dry, but necessary for a complete understanding of why it takes a while for QFE's to get out to you. I need to start with a complete QFE package for the desktop, go through some reauthoring and a lot of testing, then the publishing process which requires more verification along the way. Throw in some cross-group cooperation with other test teams, many of whom I've never met before and may not know anything about XPE, and mix in some hot QFE's that need to be done immediately that throw the whole schedule off, and you can see the difficulties.

Next time, I'll tell you what kind of stress of worm writer can induce....

Here is the first of what I hope to a set of weekly posts on the subject of Windows XP Embedded QFE's.

It's the rivetting tale of a young boy, set loose on the world with nothing but a dirty MS Natural Keyboard Pro and a talent for flipping bits, seeking his fortune in the workaday, hob-nob, up and down, in and out, business world. Using nothing but his keen eyes, freckled nose, and rather hair fingers, he captivates audiences world-wide with his nail-biting exploits, trying to feverishly patch operating systems and keep customers happy. I'm your host, Jon Fincher, Program Manager with the Windows Embedded team at Microsoft and XPE QFE Lead (a lofty title that conveys much glory, but very little booty). Try to hang on to the sides of the boat as we navigate these treacherous and exciting waters - I'm not coming back to pick up stragglers.

OK, so it's not William Burroughs, but it's a start. But why a blog? Well, I've written some columns for MSDN, which have been moderately well received. This blog is a personal venture (sanctioned by my boss, of course), and being so, I can be a little more relaxed and free flowing. Plus, in keeping with the spirit of the Internet, I figure if something is interesting to me, it must be interesting to everyone, enough to use up hard drive space on someone (else's) server. So I'm gonna write and talk and be painfully clever and exercise all the dry wit I learned watching BritComs and be wildly successful at it.... OK, maybe not, but if someone other than my immediate family members reads this blog, I'll score it as a victory.

We'll start with some meat in the next post - there are some stories to tell. Names will be changed to protect the innocent. Once again, I'm your host Noj Rehcnif - see you next time.

The jokes get better, I promise, just stay with me....