A letter from a reader

Well, I guess I better start updating this a bit more – there are actually people reading it that I didn’t approach with the request, “PLEASE READ MY BLOG!”  Not that I’m that desparate for a readership, but who knows?  Should I decide to turn the corner from Helpful Embedded Guy to Evil Genius, a solid readership makes for a ready source of Evil Henchmen recruits… :-)

Anyway, on to the letter – Sana in Pakistan found my e-mail on the blog and is asking about Remote Boot.  His problem description (minorly editted):

I deployed (the base image) to target pc's hard-drive and ran it until I got Machine-resealed message. Further, I prepared a .sdi file from it. Using windows 2003 server, I configured dhcp & remote boot dervice. I gave Client's MAC address, boot program and boot image name in remote boot manager.

.sdi file size is 180 MB.
RAM: 320MB
Processor: 385MHz

The ramdisk image started loading and it completed. Next, the light blue screen, that showed that it's an XPE image of evaluation copy and it will expire in 120 days, was displayed.

Further, it moved to the page that we get when xp starts, like welcome page. Then it got stucked there though i waited for 30 mins. but it did'nt log on.

OK, so my take on this is that 320Mb is nowhere near anough memory to host a 180Mb RAM boot image plus have memory enough to run.  For any remote boot application, the bare minimum I think acceptable is twice the size of the SDI, plus a little extra (note that this is my opinion, not a statement of supported configurations).  In this case, the 180Mb RAM image leaves only 140Mb to load the system plus everything else.  Remember, when you boot the machine on HD, you’ve got 320Mb of memory to load stuff into (like FBA, services, drivers, etc).  Now you’ve cut down the memory by more than half – I’d expect some teething pains.

However, I realize that the runtime should have done something within 30 minutes, albeit slowly (assuming you have a shell defined properly – I’m skipping over some of the more obvious troubleshooting here, assuming the runtime boots on the PC properly).  My first step would be to shut the machine down, reboot into a safe build, and check the event logs on the embedded system – something may be failing that’s necessary.  Second step would be to try to boot with a kernel debugger hooked up.

Of course, I’d also try stripping as much unnecessary HW/SW from the machine as possible – check out my MSDN article on small footprint to find out how.  Basically, start with as small a system as possible as a sanity test on remote boot, then add things to the runtime until you’ve got your whole device up and running.  By starting small, you can eliminate a bunch of things that might be causing a problem, and if things stop working after you add something, you can isolate your troubleshooting to what was just added.  The problem is that you can’t just strip down a 180Mb runtime – you’ll have to start over with a small runtime and add things to make it functionally complete.

Any comments from the rest of the readership (both of you) are welcome.