Possible problem with MS05-052

PSS has found a potential problem with XPE SP1 and SP2 systems after MS05-052 has been added to them using the Desktop QFE Installer versions of the updates. The issue is that ActiveX controls may not activate properly. If you experience this problem, add the following registry keys to your runtime:

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{0000031A-0000-0000-C000-000000000046}]
@="ClassMoniker"
[HKEY_CLASSES_ROOT\CLSID\{0000031A-0000-0000-C000-000000000046}\InprocServer32]
@="ole32.dll"
[HKEY_CLASSES_ROOT\CLSID\{0000031A-0000-0000-C000-000000000046}\ProgID]
@="clsid"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\CLSID]
@="{0000031A-0000-0000-C000-000000000046}"

Note that you can cut and paste the above snippet into a .REG file and apply it using RegEdit, if it's on your runtime. If not, you can add the keys offline, or using a script.

Also note that you may see this problem with the componentized version - the registry keys are owned by the COM Base component, but I'll do some more investigation and see if I can't resolve this in the components for December.

Running XPE on multiple SQL Instances

There's a great post on the Embedded Team blog that stems from some work we've been doing in Windows Servicibility. My test lead, Randy, came up with this technique in a day - another day to clean it up and make it readable, and you have the post Lynda submitted. What is it?

Well, it's how you can run two XPE databases on the same server, like maybe an SP1 DB along with an SP2 DB, all on one machine. No more second servers to handle the SP2 upgrade.

Why did we come up with this? Simple - automation. I've been talking a bit in this blog, and to MVP's and other customers at events, that moving security work into WinSE meant we had to automate a lot of stuff. One of the first things we automated was the creation of update packages, and the WinSE Build lab is integrating that automation into their normal build processes.

The problem came when they realized they needed to XPE DB's to do the XPE update builds, one for SP1 and SP2. They were really agitated when I told them that, if there's an SP3, they'd need a third server for it as well. They needed a way to use only one server if possible.

SQL Server supports multiple instances - basically, other DB servers running as separate processes on the machine. But CMI was never written to handle multiple instances - it just connects to the default instance on a given machine. The server to connect to is just a single string - no extra setting for which instance to use. But SQL already provides a syntax for selecting a server and specific instance - it's /. If you set that as the DB to connect to in DB Manager, CMI happily connects to the specified instance.

A few things to note about the steps Lynda provides:

1. We developed these steps for the WinSE Build Lab, which has a SQL Server installation being used for other purposes. Therefore, we added two new instances, one for SP1 and one for SP2, so their default instance wouldn't be affected by XPE. In your setup, you may not need to be so diligent and be able to use just a single additional instance.
2. In our build environment, it's important we keep our repository files separated, so step 6 is necessary. You may not need to do this - repository separation is provided in the DB's themselves, and all the update files go into separate repositories, so this may not be necessary. It does duplicate a few Gb of data, so if you're tight on space on your server, you should be able to skip this without affecting your builds.
3. Step 5 has you copying databases from one instance to another - we did not test, and do not yet know, if you can install the DB directly to a given instance. If anyone tries this, let us know how it worked.

That's it - questions on this procedure should be sent on a comments to either this post or the original.

October Updates, and news

Well, part of the October updates are on the OEM Secure Site - the ones for use with the (inaccurately named) Desktop QFE Installer Tool have been posted. I'm looking into why the component updates aren't there - they were actually released by me the day after the desktop updates.

A few notes about these persistent delays - in the past, the delays have been due to engineering delays. We wait until the second Tuesday (when the Pro updates are public) to start our componentization process. Now, however, we're actually done with the componentization and testing a week before everything is ready for release - that week gives us time to actually do the release of the componentized updates. The release process has changed as well - we're releasing via CD direct to the Authorized Resellers, so you can actually order the update CD from the company from which you get your XPE tools and device licenses. Everything up to the burning of the CD I have some control over - after the CD is burned, it's a black box to me.

So, while from my POV we're simultaneously releasing Embedded updates with the Pro updates, the process of getting them onto the OEM Secure Site is still a time consuming process, and means that you still see a week delay. I'm doing everything I can to decrease that time to be as small as possible.

One other note - October included an update for DirectX 9 for both SP1 and SP2(MS05-050, KB904706). XPE SP1 did not ship with DX9, so there won't be a componentized version of the DX9 update for XPE SP1 in the package that gets released. We did ship a DX9 component for XPE SP1 as a separate feature update - I plan to have an update for that feature in December. It will be setup so it won't install on your XPE SP1 DB unless you have the DX9 feature added - let me know if this is important to you by commenting here.

And one final note - you'll want to keep visiting both this blog and the Embedded Team blog in the coming weeks. We're working on something pretty cool that we should have figured out years ago, and I think you'll want to see it.

Format change

Sorry to have to do this, but I'm getting tons of comment spam - at least 10 a day, from all my blogs. Since I blog on Blogger, they have a way to defeat it - code word verification. Simply put, if you want to comment, you have translate the modified bitmap phrase into typed text. Since automated systems can't do this, I don't get comment spam from them.

It's a hassle for you, but to be honest, I really don't need real estate advice from someone who thinks my blog is "really cool", "has tons of great info", and "will definitely bookmark your blog!"

Hi, remember me? Been a LONG while since I've posted anything, I know (like July). No good news to report until now...

Seems like Sean Liming's kept himself busy - head up to his Tools page, and towards the bottom, you'll see a link to a new tool called SLDDiff. For those of you who have his latest XPE book, the Windows XP Embedded Supplemental Toolkit, this will look familiar - it's a lot like SLXDiff, but it compares SLD's.

I'll confess that I was the impetus here - I was looking for a way to find differences in 30+Mb SLD's (like our monthly rollup SLD's) and had nothing. I hacked together an XSLT that would pull the pertinent data out of the SLD, sort it, and dump it to a text file. Do that on two different SLD's, then run the text file output through WinDiff (or suitable differencing engine), and you've got a really terrible way to figure out what changed. Sean took that idea, wrapped it in a neat interface, and came up with a tool I use when necessary.

As for the latest set updates, they're on their way - the desktop versions should be on the OEM Secure Site RSN (Real Soon Now), and the component updates are on their way as well. The only thing that you won't find in the component updates is the DX9 update for XPE SP1. XPE SP1 shipped with DX 8 - we do have a DX9 component for XPE SP1, but since I didn't have that installed when I ran the updates, I didn't pick it up. It will be out in November.

One other piece of good news is that we're now using an automated tool for generating updates for XPE - it does everything we used to do over 1-2 days in about 15 minutes, integrates into the existing build process for XP Pro updates, and cuts down on our test time. We're not pushing so hard anymore to get fixes developed and tested, and can take some time to implement more test automation as well. Our hope is to code ourselves out of jobs, but not until we speed up the release process... :-)