Building Servicable Devices

There's a new whitepaper on MSDN that I've authored called Building Servicable Devices.  It's been in the works for a while - I wrote the bulk of it a few months back, but then ran out of bandwidth with all the XPE SP2 work I was doing.  By the time someone got traction on it, it was July.

Anyway, the paper is there and covers some high level topics on how to think about servicing XPE devices.  There are links to key Windows technologies that can help, and there's talk that a more in depth paper is coming as well - more on that as it happens.

Let me know if any reads the whitepaper (or this blog for that matter).

Remote Boot deployment issues

I've been working on an issue for two different customers who are trying to use Remote Boot Server (RBS) as a deployment tool.  The scenario goes like this - build a remote boot image, boot a device using that RBS image, then copy a different image from your network to the underlying media on the device.  The steps for building the RBS SDI include booting the device through FBA, then cloning the image using FBReseal.  After the cloning, you build an SDI from that golden master image to capture the image ready for remote booting.

The problem occurs when the media you built the RBS SDI on differs from the underlying media now in the machine.  For example, if you built the RBS SDI on a 256 Mb flash card, but the device you're booting now has a 128Mb flash card, you cannot see or access the 128Mb flash.  This is a known issue for us - we have a bug on it.

The good news is there is a workaround for this issue (which is 99% of the way to resolving the issue for one customer).  Creating the RBS SDI is a two step process - copy the golden master image to a partition in an SDI file, then read that partition into a second SDI file that becomes the remote boot image.  Before you create that final SDI, but after the image has been cloned, you need to delete the following registry key:

HKLM\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\gendisk

This key is created during FBA and is tied to the underlying media.  Because the media is changing between the time of cloning and the time of booting, there is no longer a connection between the two, so if the media changes, the connection is lost and you can't see the media anymore.  By removing this registry key, PnP will detect the underlying media, recreate the key, and make the link between the two.  Viola!  Now you can see the underlying media (usually as drive D:, since the RAM disk is drive C:).

No need to thank me - that's what I'm here for.  Well, that and the free soda...

Inaugural WE-DIG meeting date set

I just joined the Windows Embedded Developer Interest Group (WE-DIG), based here in Seattle for now.  It's a group of embedded developers who use Microsoft technology - that includes Windows CE, Mobile, and of course, XPE.  Our first meeting is set for September 1, 6:30pm-9:00pm, on Microsoft campus - if you find yourself in Seattle around that time, drop me an e-mail and I'll give you directions and make sure you can get in.  The meetings are open to all embedded developers, not just MS employees - in fact, the group was spearheaded and is being led by Paul Yao, an eMVP who focuses on CE development.

I'd also encourage everyone, even if you can't get to Seattle for the meetings (first Wednesday of every month, same time), to go to the WE-DIG web site and sign up.  We've got plans for original content, a wiki for everyone to contribute to, and regular news items.  Everything's RSS enabled as well, so once you've signed up, you can keep up to date in your favorite RSS reader.

There are plans to expand WE-DIG to other cities - we've got some people interested in setting it up in other locations as we speak (or as we type and read, whatever).  We want to see how this works in Seattle right now, then we franchise.