KM Blog

Dragon Soars and Yukon Finds Gold: Showing Depth and Breadth of AMD Platform Advantage

2009-01-30T12:30:00.000-08:00

Did you see this?

Looks at the photos and videos. This is impressive, isn't it?
AMD, as usual, shows itself as being one of the most innovative companies in the Hi-Tech industry. Tough times but they still break the walls within R&D.

AMD/Home Cinema PC: Who wants a Home Theater PC anyway?

2008-12-05T11:02:00.000-08:00

AMD has published a nice article "Who wants a Home Theater PC anyway?".

AMD's blogs can be found here.

XPe tip #52: Registry guide

2008-02-06T17:37:00.001-08:00

One of the best registry guides I've ever seen created for Win2000 and XP (and therefore for XPe) can be found here.

For instance, beautiful and very detail info on the [HKLM\HARDWARE] key and its subkeys is here.

XPe tip #51: Language/Keyboard layouts switch at runtime

2008-01-31T17:09:00.000-08:00

Situation: Multiple Language Support
In TD you added several preconfigured Input Language/Keyboard layouts to choose from.

Bug: At runtime you cannot change (add new) a keyboard layout. It fails with an undescriptive error message "it cannot load the keyboard layout".

Fix: Add "IME Prototype" component to yor project in TD, rebuild and deploy the image.

XPe tip #50: Smallest Windows XP(e) based thin client image

2007-06-01T11:08:00.000-07:00

Another post in the newsgroup has led me to an investigation in results of which I came up with probably the smallest networked XPe image that include fully functioning RDP client.

Basically I suggested to start with image that would include the following:
- Your hardware + HAL (only hardware you plan to support in the image)

- NTFS FS/File format. The latter is zero-size and may bring more components in as dependencies - however not actually required if you don't plan to format disks in NTFS under XPe.
NTFS will help you to compress the file system and thus to minimize the disk space usage.

- Basic: NT Loader/Nt Detect/Windows API - GDI, Kernel, User, Advanced/Shell32 API/Ole32, OleAut32/Language support/Winsock/Common Controls and dialogs/etc.

- Terminal Server Client

- Windows RAM Disk Driver (this is for RAM or Remote Boot support if you plan to use it)

- Winlogon or Minlogon (big difference in image footprint and significant difference in boot time)

- CMD shell (useful for debugging purposes). You can remove this shell later when you are done with the image config, or replace it with your own custom shell or the MSTSC.exe (RDP client) running as the shell.

If you do the above with Minlogon your image size can be less than 96Mb (uncompressed). With Winlogon it will grow by ~20-30Mb. The given numbers are rough and I got those off some of my demo images I have here with RDP client working. The actual image size may very dependent on some other system specs. I often do more optimizations for image sizes in TD and post-FBA even if Minlogon used. Then 96Mb can go down to 64Mb or less (with RDP still working).

Perhaps, the most sensitive area is the hardware support. If you use TAP output to create platform macro component please make sure to disable there as many component dependencies as possible based on your final target device specs. I typically use Selector Prototype component as the prototype for all my platform macros and it helps me to disable unnecessary hardware support in TD.

Often, the challenge is to get the networking to work properly in the MS Client network environment and not blow the image size with lots of network components that have over-crossing dependency chains.

So, continuing the path I just drew I got my VPC Minlogon image with fully capable RDP client running and tested down to uncompressed size ~38Mb / compressed ~28Mb.
Plus you'd want to add 2-3 more Mb for the Terminal Services dynamic cache that is created at run time.
Note: one real device the image would be smaller.

As you can plainly see, the image is small enough to fit on cheapest 32Mb USB stick (yes, possible to make it to boot the image off a USB 2.0 device). Just imagine - you carry a stick that you can boot off on any Intel/AMD based machine and it will give you a Terminal Server Client capabilities to your network - cool!

XPe tip #49: Why HORM restricted to EWF-RAM?

2007-06-01T10:47:00.000-07:00

There was an interesting question posted to the newsgroup recently that I attempted to answer. Thought I want to add the ideas posted to my blog as well.

The question was why HORM (feature of XPe SP2) is limited to EWF-RAM mode. HORM stands for Hibernate-Once-Resume-Many embedded enabling feature.
In Fp2007 to the ewfmgr console tool (as well as to EWF API) a couple of new commands/functions have been added that are directly related to the HORM and basically allow you to activate and deactivate the feature at run time.

You will also find a lot of internals on how HORM works in this thread where Slobodan and me discussed the HORM feature implementations way before it was called HORM :-)

Now back to the original question. Why we are limitted to RAM overlay when HORM is used?
I guess the main "limitation" there of EWF Disk mode vs EWF RAM Reg is that by default the overlay data is "persistent" in Disk mode.
The major reason for using EWF RAM for HORM scenarios was that the changes you do while you work with the image that are redirected to RAM are going to get lost on reboot. This way whatever OS does about the hibernation file (hiberfil.sys) will be lost as well and you can always go back to the original state of the device - this is basically the main purpose of the HORM.
With EWF Disk the changes are redirected to Disk overlay (another hidden partition on the disk) and EWF will pick them up at the next boot until you clean the overlay or commit the changes (there is also a minor difference in behavior depending on what restore level you selected for the disk mode but it is irrelevant to this discussion).

So, imagine the following scenario:

1) HORM is enabled. Hibernation file holds a valid state of the system saved at some point of time.

2) EWF is enabled too. Disk overlay is used. Initially the cache is *clean* (not really possible with EWF Disk mode when you enable HORM but just for the sake of this explanation).

3) You boot the image and it boots fast from the hiberfil.sys file.

4) You work. FS (actually disk level) writes are redirected to Disk overlay, no files on the protected partition are actually changed on the disk including the hiberfil.sys.

5) You reboot the system (gracefully or not doesn't matter since you are EWF protected).

6) The system boots from the same (old!) hiberfil.sys file. This means it will restore all the driver and application states to whatever states they had in memory at the moment the golden image was hibernated. EWF driver also has some (old) state there where it remembers what was the Disk overlay content at that time, i.e. it thinks the overlay is *clean* (see step#2).
However, your actual Disk Overlay is not clean since it was modified in an earlier OS session (see step#4). Now you get a discrepancy between the disk overlay and its state in RAM (EWF state machine). This will likely lead to an exception within the EWF driver and, since EWF is a kernel driver, to a BSOD.

The situation is even worse if we go real and don't assume the *clean* initial state of the EWF overlay. Since at the time we hibernated the image the EWF was already enabled (it must be enabled) you already got some changes to the disk (often unintentional such as logs, registry hive changes, etc.) that were redirected to the overlay.

Another issue could be that if you need to commit the changes (and stop the HORM) you won't be able to do that. The actual commit in Disk overlay mode occurs at the next boot time after you issued the commit command. At boot EWF driver reads all the changes off the hidden data partition and applies them to the disk. Obviously, this happens way later than the OS (the loader and the kernel) loads the RAM image off the hiberfil.sys (i.e. restores the system from the hibernation file). Since the hiberfil.sys file is the old one the EWF driver there (its state machine) doesn't know the commit command was issued and you will never get out of the loop.

The only way to test the above scenario is to use one of the "hacks" we discussed with Slobodan in the newsgroup (see the link above). Otherwise, HORM will be disabled as reported by the ewfmgr. I also discovered that hibernation won't work at all while EWF Disk Mode is protecting (enabled) the system partition that holds the hiberfil.sys file.

The actual bug, in my opinion, is there in the latest Enhanced Write Filter component UI in TD. There Microsoft added the checkbox for HORM - very nice feature - but hesitate to disable the option when the settings are changed to Disk Overlay usage.

XPe tip #48: Get rid of System Tray icons and remap the UI

2007-06-01T10:26:00.000-07:00

There are some 3rd party applications (and even Microsoft application like BlueTooth systray agent) that install icons in the SysTray area - the right-lower corner of the Desktop screen. Some of these application rely on the presence of that icon to provide a way to access their UI. Unfortunately, often there is no other way left.

When you are trying to get rid of Explorer shell (on some embedded devices that run a custom shell apps it will make sense) you will remove the SysTray ("Notification Area") as well since it is a part of the Explorer application. More precisely it is a part of the TaskBar feature of Explorer Desktop that runs as system shell.

So, the question is how to get rid of the SysTray (the Explorer) but yet have a way to access such application UI? No easy answer.

Here is what I'd suggest (posted my thoughts in this newsgroup thread).

1) The best approach would be to implement the missing Explorer features within your own custom shell application. It is really hard with regards to some features and requires a lot of debugging on XP/XPe to understand how those features work and how to invoke and integrate them into your own application.
Just to encourage you, I've done this for some of the Explorer features such as AutoPlay, Taskbar, Volume Manager and etc.

2) How 3rd party applications install the icons in the System Tray area?
It is basically about about one API function - Shell_NotifyIcon - that is being used by applications to add icons to SysTray area and be able to receive notifications from the shell by user clicks on those icons through the application window procedures (when you call that API you register your window procedure to receive the events). The Shell_NotifyIcon is exported by shell32.dll. Assuming you don't use shell32.dll in your image that is supposed to run a custom shell, you can create your own version of shell32.dll that will expose (export) that function only. Used as a shim it will give you the full control over what and when that application is doing in the UI.

3) Another way, much simpler, is to find out what messages are sent to the application window procedure when user clicks on the application specific icon in SysTray area or selects an item on the appropriate menu shown by the left-[right-]click on the SysTray icon. Knowing those messages and their parameters (likely WM_COMMAND messages) you can always implement them and send them out from your own shell to the 3rd party application being investigated. This way you can "remap" all the functions of the application icon in SysTray to your own UI.
The best way to watch for the messages is to start with Microsoft Spy++ tool. Next steps is to subclass the window (via global hooks in Win32) and watch for the messages through debug output.

XPe tip #47: UNMOUNTABLE_BOOT_DISK BSOD on VPC

2007-06-01T01:28:00.000-07:00

While working on demo images that I deploy on VPC (Virtual PC 2004-2007) I noticed an interesting thing that makes a perfect sense though.

I use the newest feature of Virtual Server 2005 R2 (and I love the feature) - Virtual Disk Mounting. That basically requires Microsoft Virtual Server SCSI disk device driver.
What I noticed is that if I leave the VHD (virtual disk image) mounted in the OS on my development machine and I try to boot that image in VPC - I catch the UNMOUNTABLE_BOOT_DISK BSOD right away.

This makes sense since the volume is not available for writes from within the VPC as the host OS locks the VHD image with the new disk device driver in the chain.

The tip is simple - don't do that! Don't mount the VHD and try to boot from it in VPC.

XPe tip #46: Another EWF related BSOD: UNMOUNTABLE_BOOT_DISK

2007-06-01T01:12:00.000-07:00

Just discovered that if you use EWF Disk Overlay mode and set the disk overlay size (in TD) to something very small (by default it is only 1024Kb) you are going to get the UNMOUNTABLE_BOOT_DISK BSOD (Blue Screen of Death) right after the second reboot after you enabled the EWF.

The reason is, probably, that when you enable EWF and reboot (to take the change in affect) the OS starts redirecting all the disk writes to the Disk overlay. It is trying to but obviously the size of the overlay (the size of the hidden partition that holds that Disk overlay) is not enough to cover all the changes, even unintentional ones like underlying system logs, changes to registry hives, etc. Somehow EWF doesn't give you any notifications about it (and that may make sense on a headless embedded devices, btw). At the next boot the disk writes saved in the overlay are validated and this leads to the BSOD.

It is actually easy to prove that it is the EWF (not corrupted FS or etc.) that is the cause fot the BSOD. Just open up the system registry hive of the crashed image offline (from another OS load such as XP Pro or WinPE) and remove the EWF from the list of volume upper filters for the disk driver. You will be able to boot the "patched" image just fine.

Another way to prove that is to delete the EWF hidden partition that holds the broken overlay. Obviously, EWF will become useless after that but you can always get it back to the default working state by issuing the following command "rundll32 ewfdll.dll, ConfigureEwf" that will re-create and initialize the EWF config (overlay) partition on the disk.

XPe tip #45: EWF and Cloning

2007-05-31T22:08:00.000-07:00

I guess the topic has been discussed in the newsgroup quite many times but since I just happened to run into a related issue and fixed the runtime I thought I should cover this in some details on this blog.

What if you are tasked to create an embedded image that must include EWF and will be deployed to devices as is. In other words, there won't be technicians who can fix known issues with the image deployment in field.

I am only going to cover here the case where all the target devices are identical - the same type of the hardware and number and type of peripherals attached. If this is not the case, it should be adopted/modified dependning on what hardware modifications you plan to do in the field (such as changing partition setup and so on).

The task first seem to be trivial - you just have to properly clone the image on multiple target devices. Dependening on how you plan the clonig process (factory mode, etc.) and what's the target working environment will be (LAN, domain network, Internet, etc.) you will or will not include and setup the System Cloning Tool component.

Unfortunately, that is only going to be that easy if you use EWF RAM Reg mode. The reason is simple - in RAM Reg mode EWF stores all the configuration settings in registry. So when you copy the image to another device, all the EWF settings will be properly copied along with that. No need to worry about hidden partitions and such. You can simply use xcopy to copy the image files. Certainly, cloning tools such as Ghost or Altiris can be used as well no problem.

However, in you happened to use EWF RAM or Disk mode you got yourself in troubles. If you just xcopy the image (or use ghost tools the same way you'd use to capture as smallest image as possible) at the cloned system launch you will notice that EWF is not working. If you execute EwfMgr commands it will report the it cannot find the EWF volume (and there it will refer to the EWF config volume that stores all the EWF configuration settings and, in case of EWF Disk mode, the overlay data). Obviosly, with the Windows standard tools (xcopy and etc.) you won't be even able to see the EWF partition. So another approach shuld be taken and here is a few I can think of:

1) Use Ghost's -IR switch (or similar switch of another cloning tool if suported) when capturing the golden image. It forces the ghost to grab every raw data byte of the source disk vs going through the file system to copy only files as the ghost without IR switch does.
Big disadvanges of this solution is that depending on the target device's hard disk setup you may end up with a GHO file with a huge size (ghost with IR switch doesn't know anything about files on the disk and capturing every single byte of the specified storage device). Also, this way you won't be able to operate and clone partitions, only entire disks.

2) Create a tool that will copy over the hidden EWF partition to all the target devices. Something like WinHEX editor or any partition management tool that allows you to view and save the content of disk sectors would help you here. I typically use Paragon Partition Manager for that.
This approach is quite complicated and not easy to automate without a 3rd party tool which may add some extra licensing to your device production.

3) Have EWF disabled in the golden image and re-enable it on the cloned runtime very early at the first boot. You can then xcopy the image files to target devices or use Ghost the regular way (FS aware).
However, this would only work if you re-create the EWF Config partition on the cloned image. Here is the command that will help you to accomplish that:
rundll32 ewfdll.dll, ConfigureEwf
- or -
rundll32 ewfdll.dll, ConfigureEwf Start
(both seem to have worked for me)

You can launch this command with a FBA Generic command set up to run after the cloning phase (phase number > 12000) or use [HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce] key or Startup Menu item if the Explorer Shell is used in the runtime. Otherwise you can use [HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon],"UserInit" key to add more command you want to run at run time. Just make sure to clean up that key and return its value to original (default) when the job is done. If you do all the commands from a batch file that will also add some .reg files that will do it.

Obviously, after you created the EWF Config partition you will need to issue "ewfmgr : -enable" command and reboot the target device so that EWF can take that command in affect. Again, all these commands are easy to combine in one batch script file.

4) Switch to use EWF RAM Reg mode. After all, there is almost no advantages of EWF RAM mode over the RAM Reg mode (except the ability to use -disable command). However, EWF with Disk Overlay has its own value that would be hard to replace with EWF RAM.

XPe tip #44: Where are the system shurtcuts?

2007-05-25T15:11:00.000-07:00

Where the system shortcuts are coming from? Administrative Tools, Programs, Programs\Accessories (Accessibility, Communications, System Tools, Entertainment), Games, Messenger, Movie Maker, Wireless Network Setup Wizard, Remote Assistance, Windows Media Player?
The answer is trivial - "Standard Start Menu Shortcuts"component.

Btw, that component is a great resource for those who wants to learn how to create shortcuts on XPe directly in TD.

XPe tip #43: CDFS/UDFS

2007-05-25T15:08:00.000-07:00

Problems accessing the content of CD or DVD under XPe keep being posted in the newsgroup.

The tip here is very simple - include the CDFS/UDFS components - CD/DVD file systems.
This is surely going to work assuming you've got all the CD-ROM/DVD-ROM driver issues resolved first.

XPe tip #42: Media file metadata access

2007-05-25T14:54:00.000-07:00

This interesting post in the newsgroup led me to discovering another nasty bug of latest XP Embedded bits (SP2, FP2007).

Basically the issue was that the poster was having troubles accessing the metadata of media files on an NTFS partition. More specifically, their script code that called to getDetailsOf method of the Shell.Application object was failing to return proper results but returned the success error code.

The issue showed up when the developer moved to FP2007. First thought was the problem was there due to a missing component that could disappear (vs old builds) because of the major re-factoring Microsoft did in that Feature Pack.

However, the source of the problem was in the new component that was added to the database update - "Windows Media Player 10.0". The previous player components - "Windows Media Player 8.0" and "Windows Media Player 9.0" (this one is ghost component) - included the shmedia.dll library but the Player 10 didn't. That library is actually responsible for parsing file content, that shell API are loading up, and extracting and parsing the metadata that file may contain. That metadata is heavily used by newest media file grouping feature of Explorer shell with Windows Media Player instead on XP system.

Conclusion: make sure to include shmedia.dll library and register it (it is a COM object so you want to use the regsvr32 tool at run time or simply add a FBA DLL/COM Registration resource command in TD.
Note that the shmedia.dll library is surely in the XPe repository because of the previous versions of the player component.

XPe tip #41: "Processor scheduling" registry setting

2007-05-23T22:03:00.000-07:00

How to preset Processor scheduling settings in TD?
These settings you can get to from Control Panel-->System-->Advanced-->Settings (Performance)-->Advanced (Processor scheduling section).
Answered here.

The Processor scheduling settings are mapped to the following registry value:
[HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl],"Win32PrioritySeparation".

You can overwrite this value in the Registry Data section of the "Client / Server Runtime (Console)" component.

This binary mask value should be set to (or just include) 0x18 to optimize the system to use a greater share of processor time to run background services.

The mask can actually be tuned much more precisely with setting particular bits of the value. More info on the bits meanings can be found here.
For instance. Clicking Background services sets the value of this entry to 011000 (0x18), and provides for longer, fixed-length processor intervals in which foreground processes and background processes get equal processor priority.

XPe tip #40: "Adjust for best performance" registry setting

2007-05-23T21:56:00.000-07:00

How to preset Visual Effects settings in TD? These settings you can get to from Control Panel-->System-->Advanced-->Settings (Performance)-->Visual Effects.
Answered here.

The Visual Effects settings are mapped to the following registry value:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects],"VisualFXSetting".
That flag should be set to 2 to optimize the system for best performance. Value 1 is for best appearance.

The same value could be set under HKEY_LOCAL_MACHINE branch to affect all user accounts (global policy). Or under HKEY_USERS\.DEFAULT branch to effect the default user accounts as well as all other user accounts since on XPe they all use Default User settings for defaults during FBA.

No component in TD brings in that registry value by default. It is probably getting [re]set during FBA.

XPe tip #39: Prevent BSOD from locking device

2007-05-23T21:41:00.000-07:00

There was a topic we have covered in the newsgroup long time ago I thought I'd want to have listed here as a tip.

We are all familiar with XP famous BSOD - blue screen of death - a stop error displayed after encountering a critical system error. BSOD on 2K/XP is basically first chance exception within the kernel space (the kernel code or a kernel driver) that the system cannot recover and therefore has to shutdown the system. Instead they first show the exception info and, if set up properly, dumping the memory to a crash dump file.

How to prevent the system from showing BSOD? That may be important on an embedded device that is setup to be headless or does not require user interaction during normal hours of operation.

Only way to do that I know of is by setting the following registry entry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl],"AutoReboot"=dword:1
that is mapped to XP's Control Panel/System/Advanced/Settings (Startup & Recovery)/System Failure/Check-Automatically Restart GUI element.

This registry value belongs to "Computer Prototype" component and in TD can be set (modified) under HAL (PC) component registry data section (e.g., "Standard PC" or "Advanced Configuration and Power Interface (ACPI)").

XPe tip #38: Ramdisk drivers

2007-05-20T21:19:00.000-07:00

Newbies on XPe often confuse the "Windows Ram Disk driver" component with a ramdisk that they may want to use a a temporarily file storage for things like Internet Explorer cache and etc. That component, however, is only a ramdisk driver that is used in RAM boot (Remote boot) scenarios and gets loaded by the loader to emulate the system running off a ramdisk (the entire image is copied to RAM and launched from there).
More info about the RAM boot can be found here.

There are quite many ramdisk driver for creating a device that can be used as a temporary storage available on the Web and created for Windows 2K/XP. For instance, the one from picobay.com.

However, I prefer not dealing with extra software licensing on XPe and tend to use sample driver from sources like Microsoft, CodeProject.com, CodeGuru.com and such where I can always modify the driver to meet my system requirements or simply compile it and use for free.
Here is a couple driver with their sources I used on XPe:
- Microsoft RamDisk sample driver.
Note: this one was created for Windows 2000 but an extremely easy to port to XP and the require porting steps are mentioned in the knowledge base article linked.

- CodeGuru's driver.

Note that for both drivers there are some settings (the ramdisk size and so on) that you may want to preset in the registry while integrating into your XPe.

Honestly I have happened to use other 3rd party ramdisk drivers on XPe but those were tied to customer's SKU's, required an additional license costs and not to be listed here. More ramdisk driver sources I mentioned in the newsgroup.

XPe tip #37: mpnotify.exe is not held by any component

2007-05-20T16:04:00.000-07:00

There was an important and interesting post in the newsgroup recently that I have missed due to the MEDC and WinHEC conference attending.

The problem posted was about some API function (such as NPLogonNotify) not working under a full blown XPProEmulation XPe image. Obviously the issue was there not due to a missing component since XPProEmulation virtually includes all software components from the XPe database.
From the newsgroup thread you will see that the debugging the poster team has done showed that their own credential manager was working fine on Desktop OS and only failed to get notifications under XPe with interactive logon.

It appeared that the issue was there due to missing mpnotify.exe - the executable that is responsible for issuing Winlogon notification to registered network credential providers. The NPLogonNotify won't work if mpnotify.exe is not running (e.g., missing or crashed). Basically, it is the mpnotify.exe process who calls the NPLogonNotify function of the network provider .dll file.
The above fact is perfectly documented in this Microsoft Knowledge Base article.

The problems with XP Embedded is that although the mpnotify.exeis in the XPe Repository it doesn't belong to any component. It is basically left out from the component database which makes it harder to include in the image if you don't know what is required to get Network Providers to work and being notified by Winlogon.

A couple more useful links for the proper credential manager Dll integration into your image:
- Required authentication registry keys
- A very good guide written for Logon Filters - a sample credential manager from CodeProject.com.

XPe tip #36: Changing IP with EWF/FBWF On

2007-05-19T22:38:00.000-07:00

There was an interesting topic recently covered in the newsgroup where I had to spend some time to answer the poster questions and got some new knowledge (as very usual while answering other's questions in the newsgroup, btw :-) ) about Microsoft's Registry Filter component.

I won't go into details of that conversation (read in on the newsgroup archive if you wish) but I will just summarize the task, the problem and the solution.

Prerequisites: We have an embedded device running XP Embedded image with EWF or FBWF filter protecting the system partition including system registry hives.

The task: For a person administrating the device (IT, end user, whoever with the sufficient rights to access the network stack on the device) it is required to change system network settings to either switch to required static IP or, if already a static IP used, change the IP address.

The problem: With the write filter protecting the system registry it will be required to commit the entire system registry hive in order to make the IP address change persistent. With EWF it is even worse - you have to commit the entire system volume to accomplish that. The bad part there is that along with the IP changed you will commit all user modifications he might have done on the device and in the system registry. Often, those modifications are undesirable and lead to an unstable device (the beauty of the WF protection of the system volume is getting lost). I am not even touching the sensitive area of viruses and malicious software that a networked device might be exposed to.

The solution: What if we only commit the changes related to the IP settings in registry (what those are? see below...) and leave the system with the fully protected system volume yet.
Yes, it is possible with the component called Registry Filter which has become public within Feature Pack 2007 (there was a QFE for SP2 release that brought in the Registry Filter but that QFE was only available to OEMs).

The Registry Filter was only created by Microsoft to fix the famous issues with Domain Secret Key and TSCAL (license for Terminal Server client). However, the way the component works allows you (undocumentaly, of course) to use it in the purpose of working around some other issues with Write Filter protecting the system volume.

The way Registry Filter works is that it allows you to specify registry keys to make them persistent across reboots while the write filter is ON. Basically Registry Filter creates and initializes a file-backed ramdisk - the hidden system regfData file under the root of the system volume. On that ramdisk it stores files that contain the selected key contents.

My suspicion (as I indicated here) is that the way the \regfData gets away from the EWF protection is through a mechanism similar to the EwfMgrCommitFile. On FBWF, of course, it is much easier to by-pass the protection for the selected file since this filter is file system aware and doesn't require a hack like the EwfMgrCommitFile API.

Now, when we know how the Registry Filter works, lets try to use its functionality to "unprotect" other registry keys we may need to may persistent across reboots with the write filter enabled on the system volume and system registry hives.
Sample registry entries that have to be added to your XPe image at the design time (at run time of design) I already showed in the newgroup. (Note: now we know the time zone info is not the right key for monitoring because of the way Registry Filter gets started - it gets started after the system checks for time)
Here is a sample for reference:
[HKEY_LOCAL_MACHINE\ControlSet001\Services\RegFilter\Parameters\MonitoredKeys\2]
"ClassKey"="HKLM"
"FileNameForSaving"="YourFileName.rgf"
"RelativeKeyName"="Software\YourRegistryBranch"

But what are the keys that have to be set for monitoring by Registry Filter to make the IP change persistent?
Initially I thought these:
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\{}],"IPAddress"
and
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\{}\Parameters\Tcpip],"IPAddress"

But after I've done some tcpip driver stack debugging it is clear to me that the first key is the important one. The second will be auto-reset by the system (tcpip driver will refresh the values there grabbing the values from the first key).

So, cool, this means that we just have to add in registry at run time something like the following and it should work:
[HKEY_LOCAL_MACHINE\ControlSet001\Services\RegFilter\Parameters\MonitoredKeys\2]
"ClassKey"="HKLM"
"FileNameForSaving"="TcpIp.rgf"
"RelativeKeyName"="SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{}"

Note1: The CurrentControlSet is used here correctly. But in case you like the actual ControlSet00X key please make sure you work with the right one that gets used for the hardware configuration you are working with (typically the ControlSet001 on the XPe images by default).
Note2: Replace the interface GUID with the real GUID you can read off the registry at run time and that gets generated unique for your NIC adapter and interface.

The problem #2: No, the above didn't work and that is what the initial poster indicated.
The IP gets changed and the system is ping'able. However, as soon as you reboot the ipconfig.exe tool will report the old IP address that you had before the IP change. While the Tcpip GUI (the UI you get to when you go to the network connection properties) or netsh commands report the new IP. I should also note here that the actual IP of the system that you can feel on the network is still the old IP.
Why?

The upgraded solution: After some debugging I've done for the tcpip stack on XP as well as the Registry Filter and EWF components the issue appeared to be related to the loading order of the filter driver. Let me quote myself from the newsgroup.

First I created an image where I could perfectly repro the problem (Minlogon, netsh, EWF, RegFilter). Then I debugged some system stacks to understand what's going on there when we change the IP with the RegFilter on and set to monitor the keys I mentioned earlier. (I picked up EWF vs FBWF to simplify the debugging, having FBWF there won't change the picture)

I must admit the result was a bit surprising to me. Despite the fact that the behavior of the protected system with IP changed and rebooted was quite strange - no sync in the results from ipconfig.exe tool and "netsh interface ip show address" command (the same as you'd do with TCPIP GUI) - the source of the problem was not in the Tcpip stack or the registry keys picked up for the monitoring. The tcpip driver (or a driver from the ipv4 stack) indeed reads the network adapters info into a buffer (link list) at initialization from the registry's Tcpip\Interfaces key. This, of course, includes the IP address settings. When you do "ipconfig /all" it doesn't really go into the registry again but rather queries the driver for that info stored in the cache (buffer). While the netsh commands are more "dynamic" and will scan and return the results from the registry.

It is important to understand that RegFilter doesn't make the monitored keys transparent to the registry hives. The RegFilter rather applies the new registry values - the values that were saved in the monitored key hives on the protected system volume's ramdisk - to the image's registry hives at the next boot time. Some time during the driver init it loads the ramdisk and reads the files on it. Then it sets the actual values in registry to whatever values it reads from the file contents on ramdisk.

The tcpip driver will populate the internal stack buffer very early during the system boot. Looks like the initialization actually happens before the RegFilter is loaded. This leads to the Tcpip structures populated with the old data but the registry info already reflected the new data (laid out by the RegFilter) after the boot. So we end up with the IP addresses reported out of sync between the ipconfig and the registry.

To summarize the above, the real problem there seems to be that the Regfilter and one of the drivers from Tcpip stack belong to the same driver load group. Without the RegFilter enabled the IP would be changed properly (assuming the change can be flushed). This fact is extremely easy to prove with the following simple experiment.
Forgot for a minute about the RegFilter. In fact remove the Tcpip related registry paths from its MonitorKeys branch, commit EWF and gracefully shutdown the image (now the RegFilter doesn't "unprotect" the tcpip keys). Load up the image SYSTEM hive offline (open it with a regedit on a XP Pro machine). Go to the [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\{}] key and modify the value of the "IPAddress" property there. Unload the hive and boot to the embedded image and verify that the address has changed and is in sync between ipconfig and netsh results (or GUI). Note that you don't even have to mess with the [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\{}\Parameters\Tcpip] key as it will be automatically updated during the boot (tcpip driver does that at the init time).

It is also easy to confirm with a hex editor that the ramdisk image from the runtime contains the new registry value (new IP address) but the system registry hive has gotten the old one (and this is ok when you think about the Regfilter architecture and design).

So, what's left to fix the solution we created is to change the loading order of the interfering drivers. We can't mess much around the RegFilter driver - it is very dependent on the EWF/FBWF and, the same time, must be launched early at the system boot. So we only can fix the issue by moving the tcpip driver to load it later than the RegFilter and thus pick up the right values from registry hives.

The easiest way, perhaps, to accomplish that would be starting the tcpip driver by the Service Control Manager (SCM) instead of the kernel. The following value would do that:
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip],"Start"=dword:2.
That will put the driver in the auto-start group (started by the service control manager) instead of the system started (kernel or loader started).
This is a pretty safe change unless you've got some custom drivers in your image that demand the network connectivity (IP) very early at the system boot.

With the changes above committed (if you mess with all this at run time), you can try to change the IP and reboot (without an extra commit) and the IP should be the correct one reported by the netsh (or GUI) and the ipconfig as well. At least this is what I am seeing working here.

Just a side note: Domain Secret Key and TSCAL issues were "easier" to fix for Microsoft with the RegFilter approach since those keys are only read late at the boot process (by Winlogon and Terminal Services components).

MCE tip #3: Filter "More Programs" items

2007-05-10T11:44:00.000-07:00

I had a need to hide some items under "More Programs" menu in Vista Media Center app.
Unfortunately there appeared to be no way to create a real filter that would help me to apply some "programmatic" criteria to such area of MCE. However, I just found the simplest way to hide items there. All you need to do is to remove the entry points (application registered in MCE) from the following key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Extensibility\Entry Points]

For instance, I knews that the following registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Extensibility\Entry Points\{115EADF1-41C4-471b-8FE5-7A52B91BFE75}]
is the entrypoint for Chess Game item of the "More Programs" menu. It is easy to prove if you look under the key and find the "Run" value there. It points to %ProgramFiles%\Microsoft Games\Chess\ChessMCE.lnk shortcut which is obviously responsible for launching the Chess Game.
All I had to do to hide the Chess is to remove the entrypoint registry key.

The main reason I wanted to hide the game items (or any other registered program items) is that some of them still don't comply to the 10 foot UI requirements. Some games are totally 2' UI based and require mouse and keyboard - not sure who decided to put those in the MCE which is supposed to target TV users as well (and hopefully soon will not target PC users!).

MCE tip #2: How to launch Media Center app directly to the setup screen

2007-05-09T23:54:00.000-07:00

There a re a few places on the web (e.g., The Green Button, Media Center Sandbox Blog, driverheaven.net, etc.) that discussed various way how to launch Media Center and direct it to particular applications. Two most command ways - command line arguments (directmedia and homepage switches) or sending a Win32 message to the MCE window with certain wParam and lParam settings.

I have read all the info and played with it myself. Too many limitations there. Basically you can only redirect the MCE to some [very few] applications - to Live TV, Video Library, etc..

A hacky way I tried - to grab the XML resource names off the MCE binaries - didn't work well. Most of the XML pages there require some machine state variables being passed from the main application entrypoint and this makes the MCE unstable. Mostly it just crashes at the launch.

Only helpful XML page I found I could bring up that way, that wasn't mentioned on the Web, was the Media Center Setup page. All you have to do is to launch MCE with the following command line:
%SystemRoot%\ehome\ehshell.exe /homepage:Options.SetupMediaCenter.xml /PushStartPage:True

Extending and fixing MCE

2007-05-09T23:23:00.000-07:00

What you can do if you want to change some functional behaviour of MCE (Media Center application) or add some more functionality there? Or what you can do if you need to fix some 2 or 10 foot UI issues of the Media Center app?

Well, the only way I could come up with is - a global hook or Dll-injection. There are a few techniques known in Win32 world (I wish those exist in Windows CE as well :-) ) how to do the Dll injections (from writing to another process address space to the supported global hooks). Despite the fact that it may be a dangerous implementation (stability issues, lowering security, etc.) this is the only way that seems viable. Two main reasons:
- to have a better and faster implementation for your own monitoring agent application you'd probably want to stick to C/C++ to easier the access to Win32 APIs (P-Invoke's are costly and require lots of coding for missing header). MCE SDK doesn't allow you to write add-ins in native C++. (or perhaps it does but I didn't investigate this deep enough)
- too many limitations there on background add-ins for Vista MCE. You will always lose the MCE launch moment and some other events as well.

I have implemented a MCE hook-up agent that keeps monitoring the Media Center app on a complex of things - messages, windows, positions, etc. - including WM_INPUT (raw input messages), keyboard and mouse messages and etc.

A piece of advice - if you are playing with MCE on Vista, try to stay away from a service implementation for your app. On Vista, services are running in a separate, isolated Windows session (session 0) and it may take you an effort to implement the cross-session interface between your hook into MCE and the service. (not impossible but just over-complicates the implementation)

MVP Heroes Campaign

2007-05-08T15:32:00.000-07:00

My photo got published on MSDN again :-)
I got a chance to participate in MVP Heroes Campaign program. My take-out from the campaign - Microsoft has an awesome Studio!

XPe tip #35: Language Packs

2007-05-07T22:39:00.000-07:00

Recently I have forwarded a reply from Microsoft to the newsgroup in response to the question whether XPe supports Ukrainian MUI. The reply was negative - no, XPe doesn't have the Ukrainian language pack despite of the fact that there is XP Pro Language Pack exists for Ukraine locale.

Basically this means not all Language Packs that have been created for XP Professional were "ported" (componentized) for XP Embedded. Complete list of all the Language Packs for XPe (RTM, SP1, SP2) can be found here.

FP2007: What is it?

2007-04-24T23:55:00.000-07:00

I liked that straightforward question posted in the newsgroup.

In fact, FP2007 - Feature Pack 2007 - is a nice addition to the SP2 release of XP Embedded tools. It does have some new features that were never rolled out as QFEs for SP1.

More info on the Pack can be found on the product team blog.
The entire XPe documentation tree has been moved to FP2007.

FP2007 is free for XPe SP2 Toolkit owners.
Non-eval version is out there on Extranet website of Microsoft (ECE). Used to be available on OEM Secure Website that was unfortunately deprecated by Microsoft.

The best thing I loved about FP2007 is the stability of the toolkit. I can finally enjoy working with XPProEmulation and other huge projects and the development tools are not crashing. I have checked - it only required to change a few lines of VB script code that runs within TD (Target Designer) to fix the VB memory related issues while loading a huge number of components.
However, there are still some bugs in FP2007 about the toolkit. For instance, it doesn't like setting big pagefile on some ACPI HAL components. Please refer to this thread for more info posted on that bug.

XPe tip #34: Domain Security Key

2007-04-24T22:33:00.000-07:00

What is the Domain Secret Key that many times was mentioned in the newsgroup and even required a special fix for EWF to make persistent the key in domain environment? Going forward quickly want to mention the EWF fix - Registry Filter that allow to make some registry keys persistent with EWF enabled and protecting system volume including registry hives.

I am actually not sure who came up with the name "Domain Secret Key". Perhaps, XPe product guys :-) Domain Secret Key is in fact nothing more but the machine's computer account password in a domain. Basically machines - PCs in the network - can be made members of groups just like users can. They log in to the domain just as users do by proving knowledge of their master key, which each machine that is a member of a domain stores in its registry.

So where does Windows store that key? That is very easy to find out (Web Search or the Registry Filter component's script) - [HKLM\Security\Policy\Secrets\$MACHINE.ACC]. If you want to explore that key, run the registry editor as LocalSystem account (the easiest way to do this is from an administrative command prompt; type "at time /interactive regedit.exe", substituting whatever time is appropriate: make it one minute in the future, or use atnow.exe tool I posted the info about in an earlier blog post). Once regedit fires up, carefully look at the subkeys under [HKLM\Security\Policy\Secrets]. In this very key Windows stores a lot of secrets that need to be kept in plaint text for further usage, including service account passwords. You're looking at the machine's password cache, aka LSA private data store, and if the machine is a domain participant, you should see a subkey called $MACHINE.ACC, where the machine's master key lives in.

Why Registry Filter was requested? Specifically to fix the Domain Secret Key issue (and one more key issue irrelevant to this post). In domain environment the default policy is to change the computer account password every 30 days. If EWF is enabled, after 30 days you may end up with the device not being able to logon to the same domain it has joined to. So the Domain Secret Key needs to be made persistent in registry to avoid password age issues in domain environment.

EWF Registry Filter creates and initializes a file-backed ramdisk used. On that ramdisk it stores files that contain the selected key contents. The secret policy protection key file is named MacAcc.rgf.

Below is just my idea on how things could be fixed if no Registry Filter was acceptable.

Using device's Local Security Policies you can change the password age:
[HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters],"MaximumPasswordAge"=dword: (default 30 days)

You can also disable the password change completely:
[HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters],"DisablePasswordChange"=dword:1
Or refuse to domain controller's change of the computer password:
[HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters],"RefusePasswordChange"=dword:1
Corresponding local security policies are:
Domain Member: Maximum machine account password age (MaximumPasswordAge)
Domain Member: Disable machine account password changes (DisablePasswordChange)
Domain Controller: Refuse machine account password changes (RefusePasswordChange)

You can see them if you launch gpedit.msc (Group Policy Editor) and go to Local Computer Policy-->Computer Configuration-->Windows Settings-->Security Settings-->Local Policies-->Security Options.

I think in domain environment those policies are getting pushed to clients from domain controller. So a domain admin can always change those on the server side before turning on the policy on multiple clients.

Some more info you can find in the following MS KB articles: KB175468 - Effects of machine account replication on a domain, KB154501 - How to disable automatic machine account password changes, TechNet article about MaximumPasswordAge.

XPe tip #33: New hardware UI

2007-04-22T15:37:00.000-07:00

What component is responsible for the UI you see when a new hardware is attached and detected on your target PC?
The answer is simple - newdev.dll - Add Hardware Device Library. The newdev.dll library can be brought in your image if you add "Add Hardware Control Panel" component.

That library implements all the GUI for the Add New Hardware wizard. It is also getting called from Device Manager when you are trying to Update a driver. It is interesting though the Device Manager does not seem to explicitly depend on the Add Hardware Control Panel component or, at least, newdev.dll (as a rawdep). I'd call this a bug.

If the newdev.dll removed, it gives you an image that is deaf to installing new hardware. Very useful feature for headless devices.

XPe tip #32: Best practices for power interrupt safety on headless devices

2007-04-21T21:00:00.000-07:00

What if you are creating a headless device (truly headless - with no VGA - or just with no console devices attached such as keyboard and mouse) and you want to make sure the OS runs stable and reliable if an power interrupt occurs.

Below is list of things you may want to look at in the XPe documentation or that make common sense.

- Use UPS (Uninterpretable Power Source).

- Make use of XPe Write Filters: EWF/FBWF - protecting the storage media with write filters will make it more reliable for the system to recover: http://msdn2.microsoft.com/en-us/library/ms912906.aspx, http://msdn2.microsoft.com/en-us/library/aa940926.aspx.

- Headless support - this is what you may need if no console devices are attached to or supported by your hardware: http://msdn2.microsoft.com/en-us/library/ms932872.aspx.
Also, it may be a good idea to remove newdev.dll library (Add Hardware Control Panel component) from your image so that there is no GUI fired up if new hardware is attached to the target device.

- Don't include Safe Mode and Dr. Watson components in your image.(http://msdn2.microsoft.com/en-us/library/ms940820.aspx)

- Setup the system crash dump procedure to restart the PC automatically when a GPF occurs. Set the following reg.entry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl],"AutoReboot"=dword:1

- Get rid of all [most of] system popups and message boxes that may get your system GUI unintentionally locked:
http://msdn2.microsoft.com/en-us/embedded/aa731206.aspx,
http://msdn2.microsoft.com/en-us/library/ms933122.aspx.

- It often makes sense to create your own custom shell for the target XPe OS where you can control the GUI behavior (to make it more "headless compliant") and get rid of Explorer Shell that is not really headless friendly: http://msdn2.microsoft.com/en-us/library/ms913692.aspx.

XPe tip #31: Wallpaper change

2007-04-20T09:50:00.000-07:00

Want to change the wallpaper of your Desktop? Just follow this procedure:

The registry entry you want to preset in TD is:
[HKEY_CURRENT_USER\Control Panel\Desktop],"Wallpaper"=Reg_sz:"path to image"

To affect all users:
[HKEY_USERS\.DEFAULT\Control Panel\Desktop],"Wallpaper"=Reg_sz:"path to image"
Note: This entry will also be used as wallpaper in Winlogon time.

That registry value can be overwritten in the registry section of "Win32 API - User" component.

MEDC 2007 is coming..

2007-04-19T12:24:00.000-07:00

MEDC 2007 is coming! I am anxious to go there this year and hear the latest on XPe and CE front. So much info and so little time though.
Sessions info is looking very encouraging and interesting.

AutoPlay without Explorer

2007-04-19T12:06:00.000-07:00

I am filing this not as a tip but rather as an encouraging info. Unfortunately, I cannot reveal any technical details of my implementations here at this stage of the project (done for a customer) but more to show up soon, I hope.

It has been a problem for quite some time to get some of the Explorer-only features working on XPe without Explorer shell. Myself I had a negative post to the newsgroup on the subject.
The real challenge appears there not when you remove the Explorer.exe from the image but when you stop launching Explorer as shell.

Removing Explorer gives you a lot:
- Explorer is in general a big security hole.
- It is hard to get rid of all unwanted pieces of the Explorer.
- Explorer is not for embedded (it is not "embedded" type of application and have never been really componentized).
- Explorer increases your image footprint. Explorer dependencies are awfully big.
- Explorer implements only 2 foot UI and it may be very inconsistent to your own applications GUI.
- so on.

Anyway, I finally managed to develop my own shell that implements missing pieces that were only working with Explorer Shell so far. Someday I will post what are the missing features among which is the AutoPlay. But the important message now is that AutoPlay can be working without Explorer shell running in background. You just have to do some hacking and coding within your own shell app.

Another good news is that I got the same shell app up and running on Vista (with some mods though) where I stripped out Explorer components.

XPe tip #30: Where is intl.cpl?

2007-04-19T11:49:00.000-07:00

Surprisingly enough but this question keeps coming up in the newsgroup.

The answer is simple: beside the "Regional and Language Options" component that you might have already added to your configuration, please also add "International Control Panel" component that is located under "Software : System : User Interface : Shells : Windows Shell" category.

XPe tip #29: How to prepare and add Group Policy at build time

2007-04-19T11:30:00.000-07:00

We all know how Group Policies are helpful in XPe world. It is not a problem to edit the policies at run time with GPEdit (Group Policy Editor) or directly in registry. But who want to repeat the same procedure many times while deploying images during development time?! So, this needs to be somehow automated.
Also, not to mention that the GPEdit with all the dependencies it requires is quite heavy.

But how to set up the policies you want in TD at image design time?
A few way to accomplish that:

- Mess with the Group Policy INF files and get them into your image updated. This is typically more complicated way because it is often not clear how policies described in the INF. Also, you'd need to bring GP updater tool as well.

- Set up most of the policies you need as registry entries and add them in TD via your own component or TD Extra Registry section.
Here you will find a helpful page (Group Policy Settings Reference) where you can download Excel document with most of the Group Policy listed with corresponding registry entries mentioned.

- My favorite. I have provided this answer in newsgroup a while ago.
Set up policy settings on XP Pro machine or on your own working XPe image that includes GPEdit tool and then save the following folder with all its content:
%systemroot%\system32\GroupPolicy.
This folder contents MACHINE and User specific policies set up. Those are just .POL files. It also contains the shutdown/logon/logoff scripts (only if you didn't change the default location for those in GPEdit).

XPe tip #28: Boot.ini Extra Switches

2007-04-19T10:27:00.000-07:00

How do you change boot.ini for an XPe image during build time? The answer is - manually :-(

TD does generate boo.ini for you with the default ArcPath based on what you set up on the Configuration page. It is done by the EndOfBuild event handler of the Base Component that basically contains the Configuration build logic. However, if you plan to play with dual boot or want to change a logo or add some other boot.ini switches you have to modify just built boot.ini manually every time you do a build in TD. This is typically not a big deal but annoying, especially if you forgot to change boot.ini just before you deploy the image.

There was a few requests in the newsgroup for a way to change boot.ini content directly in TD. E.g., this one. For some reason Microsoft hesitated to implement that (I suspect the feature got a low priority) so I finally decided to step in and do something for XPe devs in this area.

Since TD doesn't support plug-in interfaces I could only implement that feature through undocumented CMI interfaces. Moreover, I didn't want to rewrite the Base Component (possible and I've done that once for debugging purposes) I decided to add functionality that allows us to add extra boot.ini switches. After all, we could always change ArcPath on the Configuration settings page but never were able to change, say, boot loader logo (the famous bootlogo switch).

I ended up with a script that I added to my XPeTools package that does what I described above. Via an additional field of XPeTools macro component's settings page you can add extra switches to the default ArcPath of boot.ini.

Note: added boot.ini extra switches are persistent and won't be wiped out when you start another session of TD with the same project (or simply close and re-open the project in TD). This is done the same way as I did that for other components of XPeTools package. They all have some advanced component properties used as a storage for the component functionality required settings.

A screenshot of TD with the boot.ini extra switches page open is attached.

XPeTools component update

2007-04-14T23:27:00.000-07:00

Thanks to Jim, a documentation bug was discovered in the DependencyExplorer component.
I now had some time to go over that bug and fix it in the new version of the component.
I uploaded the updated package of XPeTools on www.xpefiles.com. Updated package also includes some bug fixing for XPProEmulation component in UI and script areas. From UI I have removed the leftover Active button, assigned name to the Group filters to remove the confusion caused by the undocumented exclusion filter, fixed other minor UI issues.

XPe tip #27: PID - how to use?

2007-04-13T17:43:00.000-07:00

This is an old topic but unbelivably comes online once in a while.

XPe devs should understand the difference between runtime licenses and licensed XPe Toolkit.
Runtime license is provided to you after you signed a legal agreement with Microsoft (through XPe distributor) called CLA. Then you are given stickers with PID numbers on it (numbers like xxxxx-xxxxx-xxxxx-xxxxx-xxxxx). Used to be that the stickers all had different unique PIDs, nowadays they are the same in one multiple-license volume purchase. Depending on how many licenses are covered by your agreement you should be getting some amount of stickers. You use just one PID from any sticker and type it in the Runtime ID field on Configuration Settings page in TD. This will get rid of the "Evaluation build ..." text at run time (it other words, your runtime will be properly activated).

Another story with the toolkit. To be able to create activated runtimes, to even see that Runtime ID field in TD, you must be having and using the licensed toolkit. In Eval toolkit (the one you can download from public MSDN or receive on Eval CDs) that field is hidden, thus not allowing you to create activated runtimes. The CD-key you are getting from Microsoft (aka the toolkit Serial Number) is to be used once when you are installing the tools (TD, CD, database, etc.). Don't put this number in the Runtime field in TD - it is a wrong place for it. Rather type in there a PID from a sticker.

Also, just FYI. In SP2 times there was a QFE issued by Microsoft that was patching the toolkit to be able to use new PID range in SP1 database. That QFE was to address Extend Runtime Product Key Range for Windows XP Embedded. Quote: "This update allows OEM's and embedded developers to use runtime product keys provided after the release Windows XP Embedded with Service Pack 2 on a database containing Windows XP Embedded Service Pack 1 or earlier component databases.".

If you contact your XPe distributor, they should be able to explain you all the details about PId and etc.

XPe boot-wish-list

2007-04-13T17:37:00.000-07:00

To continue my post about MBR problems.

I believe XPe documentation doesn't describe this topic in the details it should have to. In some places in the documentation they assume you've got XP Pro running on the device. Which means you've already properly partitioned and formatted the local storage to boot from using XP Pro Setup.
Below is my personal wish-list about what should be included in the next Service Pack for XPe if Microsoft will release one:
- Create one tool (better Win32 app that we can launch from WinPE, XP Pro or any other flavor of XP and nowadays Vista) that will properly partition local storage on target device. After all, XP Pro Setup does that *much* better and more reliable then any tools from XPE toolkit.

- Provide more detail troubleshooting section in the documentation that will cover as many failed case as possible - from broken MBR to boot sector, from changing timeout of boot.ini to debug parameters for KD.

- There should be documentation section (part of XPe docs!!) that explain how BIOS loads the MBR, info about MBR structure, boot sector, boot sequence of XP, loader (how it gets loaded by bootsector) and etc. Ideally they should include info about all the fields of MS version of MBR and boot sectors. After all, most of this info is out there in MS KB articles (but hard to search) and on the Web.

- Provide a set of tools (my best wish is to have one complex command line tool with a bunch of switches like myu favorites MbrFix and NirCmd) that will do fixing for all the parts that may get broken - from MBR to bootsectors (all types!) and partition setup (I secretly don't get why we should be using 3rd party tools like MbrFix, for instance?).

I will probably update this list once in a while when my memory flashes out with more ideas I've been having.

XPe tip #26: Msvcr80 in XPe world

2007-04-13T17:21:00.000-07:00

The newest Visual Studio (VS2005 and next version Orcas) by default will link all C/C++ applications you create with the IDE wizard to the latest CRT library which is msvcr80.dll. By default, again, it uses a shared library link (dll must be present in the system path on the target).

Only XPe FP2007 brings in the library but as a part of the huge .Net 2.0 Framework component. It is not even wrapped into a separate primitive component. Obviously, you don't want to add such beast as .Net 2.0 to just add msvcr80, unless you need .Net 2.0 in your image.

Here is a few tricks you can use to get rid of possible problems with missing msvcr80 at runtime:
- Copy msvcr80.dll along with msvcm80.dll and msvcp80.dll libraries from VS2005 folders on PC where you run the VS tools (typically somewhere under "\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT").

- Make sure you are working with the proper version of the libraries corresponding to the project settings - Debug or Release. Often, people are working with Debug build (which is default by the wizard, btw) that requires debug version of the msvcr80 - msvcr80d.dll.

- Please copy manifest built along with your application exe in VS2005. This will make sure it will use the right dependencies versions.

- Often (depends on your application logic and implementation) you can simply use only basic Win32 API and you may not need the CRT libraries at all. The MSVCR80 may get linked however if you have "Multi-Threaded DLL (/MD)" or "Multi-Threaded Debug DLL (/MDd)" option set for the Runtime Library on the Code Generation tab in the C/C++ branch of the Project Properties in VS2005. Just use the single-threaded Dlls there and disable Exceptions. Or, alternatively and my favorite, just link statically to the library to remove the dependency at all (use "Multi-Threaded (/MT)" option for instance).

- Make sure to include side-by-side components in TD.

- If the above doesn't help, install VS2005 (x86) Redist package at runtime.

- If the application still fails to load, run the application through DependencyWalker on the target devices. More precisely, run it through Profiler of the DependencyWalker. Then you should be able to see why it's failing to load.

XPe tip #25: Dial-up autoconnect

2007-04-13T17:04:00.000-07:00

Adam has recently posted a link to a nice dial-up tip in his blog that I commented a little bit. Thought I would mention the fix in my blog as well but all credits should go to Adam.

To get rid of the annoying Dial-up connection dialog appearing every time an application is calling to create an Internet connection through WinInet API (the exact component responsible is rasdial code) all you have to do is to set the follwoing key below:
[HKEY_CURRENT_USER\RemoteAccess\Profile\<ConnectionName>],"AutoConnect" =dword:0.
Where the ConnectionName is the name you assigned to the dial-up connection created.

This and more info you can read about dial-up autoconnect in this MS KB article.

I worked a lot on the rasdial components in WindowsCE a while ago but on XP those are a bit different structured and, obviously, without the source code you are provided with less control on XP over the RAS than on WinCE.

XPe tip #24: CSDVersion

2007-04-13T16:56:00.000-07:00

On versions of XPe toolkit (database) prior to FP2007 update there was a problem related to version info that gets set in the system registry hive and gets returned by APIs like GetVersion[Ex]. Some applications code or application installation scripts make queries for the system version info to either visualize it to end user, change install path or setup or change the application logic if not quit automatically on unsupported OSes.
Obviously, if the version info is set incorrect those application will fail or won't work as expected (as tested on regular XP Pro with the same SP level installed).

The system version is stored in the CSDVersion string registry value under [HKLM\SYSTEM\CurrentControlSet\Control\Windows] key. You can easy find out what the permitted values are but instead just simply match whatever you've got on the same level SP XP Pro machine under the same key.
Some of the right values I mentioned in this thread.

XPe tip #23: Account password expiration

2007-04-13T16:33:00.000-07:00

I hate the account password expiration feature on XP. But on XPe image it is even worth because your users may get stuck there forever if their account is expired. Giving the fact that your locked down image may not allow to fix the problem with GUI, the person who is administrating the target devices will hate you even more.

So, how to get rid of the account password expiration? Actually, easy. A few way you can accomplish that depending on what's included in your image already:

- Use GUI User Manager at run time to change that flag.

- Run the following command at run time:
net accounts /maxpwage:unlimited
You can automate and launch it during FBA with FBA Generic command, for instance.

- My favorite: use command line version of User Manager - usrmgr.exe tool from 2K or XP Resource Kit. It supports a command line argument to change the password expiration on selected accounts. E.g.:
cusrmgr.exe -u UserName +s PasswordNeverExpires.

-Use Group Policy (GPO) template to reset the security settings of password expiration timeouts. Here is a nice MS KB article explaining how to do that. The option you are looking for is MaximumPasswordAge under [System Access] section. So, you create a similar INF file, where you set the MaximumPasswordAge to -1 - unlimited, and install it during FBA using secedit.exe tool (Security Configuration Engine Command Line Utility component). Here is a simple INF you could create to get rid of the annoying password expiration feature:
[Version]
signature="$CHICAGO$"
[System Access]
MaximumPasswordAge = -1

XPe tip #22: Disk read errors

2007-04-13T16:22:00.000-07:00

Perhaps, most of us who ever tried to partition a drive manually (not using XP Setup CD) have seen a boot time error where it says "disk read error" or something similar coming from BIOS.

There was quite many thread about that in newsgroup. Here is one of the latest.
I am not going to go deep here and explain why it might have happened if you used Microsoft tools like diskpart and etc. Just keep in mind that tools like diskpart are intended to be used by IT technicians who know their stuff and dealt with similar partitioning problems many times. Now you also do :-)

I found it extremely easy to repro the issue if you use VPC (Microsoft Virtial PC 2005-2007). Just create a new image there and partition the drive with diskpart. Even if you set the system partition active, you may end up with no booting image because of the screwed MBR record. This of course tends to be the case from machine to machine. I mean it is not 100% reproducible if you move to another PC.

The fix is actually quite simple. I posted it many times:
- Mark the system partition as active if you haven't done so.
- Try fixing MBR. You can do it manually (just have to get used to MBR binary flags and partition table settings) or you can use MbrFix tool I mentioned in the newsgroup and in this blog. MbrFix tool is lovely and provides lot more functionality.

XPe tip #21: Dependecy Explorer vs Configuration Explorer

2007-04-13T15:15:00.000-07:00

There was recently a bug found in the documentation of the Dependency Explorer component that led to some confusions I had to remove in the newsgroup.

So, what's the difference between Dependency Explorer and Configuration Explorer components.
The DependencyExplorer component is aimed to walk through components in the database. While the ConfigurationExplorer component serves the purpose of walking through components in the Configuration.

If you fire up Settings page of the DependencyExplorer component and type in a component name in the search edit box and hit Apply button you will see the following sections listed in order:
"Components:" section lists components that comply to the search criteria. Even if you typed in an exact component name, you will still likely see a few components listed here as there might have been a few revisions of the same component imported in the database and released.

"Component Dependencies:" section lists components that the component selected (clicked on) in the above section depends on.

"Component Chain:" section lists components in the inheritance chain of the component selected in the first section.
Note: the inheritance chain has nothing to do with the dependency chain.
Here you're supposed to see all the base prototypes of your components, if any, up to the very root one and the component itself.

"Custom Properties:" section lists advanced properties of the DependencyExplorer component (not relevant here).

Now about the ConfigurationExplorer Settings page:

"Configuration Components:" section lists components that comply to the search criteria and belong to the config. Here, if you typed in an exact component name, you will likely see one component listed as it is hard to add a few revisions of the same component to the same configuration (but not impossible!).

"Component Dependencies in Configuration:" section lists components that the component selected in the above section depends on. Only those dependencies listed here that are included in the configuration.

"Configuration Components depend on the selected component:" section lists components that depend on the component selected (clicked on) in the first section but only included in the config. This is similar to the result of the DEPTREE command of XPECMD tool released by Microsoft with FP2007 but not exactly the same. The difference is that the DEPTREE walks through the database while the ConfigurationExplorer also filters out components to list only those that belong to the same Config. If you need the DEPTREE functionality there, you just use ConfigurationExplorer component within a huge config like XPProEmulation project.

"Component Chain:" section lists components in the inheritance chain of the component selected in the first section. Here again you are supposed to see base prototypes of your components, if any. The prototype components are all listed here, regardless of if they all belong to the Config, and the component itself.

"Custom Properties:" section lists advanced properties of the ConfigurationExplorer component (not relevant here).

Now let me show you the results you actually get from if you explore XPProEmulation component within XPProEmulation project using both tools.

DependencyExplorer:
Search box: XPProEmulation

"Components:" section:

XPProEmulation [Version ...], [Visibility=1000]

"Component Dependencies:" section:
No component dependencies found.

"Component Chain:" section:
XPProEmulation [Version ...], [Visibility=1000]
Default Prototype Component [Version ...], [Visibility=1]

"Custom Properties:" section:
....

ConfigurationExplorer:
Search box: XPProEmulation

"Configuration Components:" section:
XPProEmulation [Version ...], [Visibility=1000]

"Component Dependencies in Configuration:" section:
No component dependencies found.

"Configuration Components depend on the selected component"
XPe Tools [Version ...], [Visibility=1000]

"Component Chain:" section:
XPProEmulation [Version ...], [Visibility=1000]
Default Prototype Component [Version ...], [Visibility=1]

"Custom Properties:" section:
....

Hope this clears things up.

XPe tip #20: XPe Tools package

2007-04-13T13:21:00.000-07:00

I keep mentioning XPe Tools package from www.xpefiles.com in newsgroup.
So, what is it? It is a set of tools I created for XPe developers to help exploring components and configurations, upgrading to newer version of SP, fighting with component dependencies and so on and so forth.
Actually, the initial purpose I created the first component in the package (XPProEmulation) was to get familar with undocumented CMI interfaces that XPe toolkit uses. Some day I'll write a few notes and hopefull articles here in the blog about CMI and what can be done using it.

The tools are implemented as components themselves (I thought it would be much more useful to get your hands on the tools by not leaving TD environment). More or less TD plug-ins, although TD lacks the real plug-in interface.

When you import the XPeTools.SLD, you will get a few components added to the database and they will appear under "Software : Test & Development" category in the Component Browser in TD. No repository is provided or required.
The new components you are going to see are XPe Tools (macro), Configuration Explorer, Dependency Explorer, Derive Explorer, XPPro Emulation and Smart Upgrade. Every component from the package has a link to an encrypted CMI script and DHTML page representing that component functionality.

You may include all the components into your Configuration, the image won't grow in size since no files added, by resolving dependencies of the macro component "XPe Tools". Please use XPeTools Package that includes all the components mentioned above to operate (delete/add/etc.) on the package components at once.

You will get more details on what components do and how they are implemented if you look at the Readme.txt file provided within the same zip as the SLD file. Also, all the components have links on their Settings pages ("more info") to show you more information about the current component and functionality.

I will briefly describe here what components are and what they do:

XPeTools - macro component that brings in all other components from the package. Some useful global options and flags added. Boot.INI extra switches.

Configuration Explorer - this component allows you to navigate through Configuration components to see their dependencies and components that depend on them. It also allows you to save configurations in plain text files (useful for further project comparisions).

Dependency Explorer - allows you to navigate through XPe database components to see their dependencies. Variaty of component filter options is available.

Derive Explorer - allows you to navigate through XPe database to see derived components. (got to get this worikng on FP2007)

XPPro Emulation - allows you to add group filtered components from XPe database to your Configuration. Inclusion and Exclusion Group Filters are suported. Due to some bugs of SP2 FP2007 (me reported to Microsoft) the exclusion filter is now required in order to get rid of Hardware components from the final Software-only XPProEmulation project.

Smart Upgrade - allows you to upgrade components in the Configuration preserving their extended properties. Smart Upgrade component will allow XPe developers smoothly "port"their SLX projects to SP2 and later preserving the configuration component settings during the upgrade (the settings of the "User Interface Core" component, for instance). This component should work for SP1-->SPx ports as well as for RTM-->SPx.

One quick comment about one option of the DependencyExplorer and other components - Minimum Visibility. This option is very helpful in the filtering feature of the tools. But I mainly use it to lower the visibility below 100 as the TD doesn't really allow that (well, it does but it requires a reg hack that I will post some day).
And please don't hesitate to lower the option value down to 0. Then you will be able to see even Legacy components left in the database from previous version of the product (and still distributed by Microsoft). you should not bother to add those components to your configuration(s) but it is a great knowledge you can gain if you explore those components as well.

XPe tip #20: Active HTML Desktop

2007-04-13T12:56:00.000-07:00

An interesting question recently popped up in the newsgroup about how to get a toolbar working in Active HTML Desktop on XPe.

As you know, on XP if you wanted to set up Desktop to show an HTML page you'd go to -> Properties -> Desktop -> Customize Deskop -> Web page and add a web page (aka component) there with soem setting options assigned. When it was done, your Desktop would show the selected HTML page(s). I always use this feature on my XP machines where I set the IE Home page (typically Google.com) to be the Desktop.

This feature works ok on XPe, of course. However, an issue was reported about the toolbar of the Active Desktop not being popping up.
On XP, that toolbar (a popup that appears on the top of the Desktop when you are hovering mouse cursour over the top of the desktop HTML page) gets disappeared when you have the desktop components locked. As I mentioned, components include the web pages you set for the active desktop. The lock can be set with GUI - just open up Desktop Items dialog (Display -> Properties -> Desktop -> Customize Desktop -> Web) and clear the "Lock desktop items" checkbox at the bottom.

But we are always interested in the registry entries mapped to particular XP features when we have to pre-set those in TD for XPe builds. The HTML Desktop Lock is mapped to
[HKCU\Software\Microsoft\Internet Explorer\Desktop\Components],"GeneralFlags" dword registry value. It is a bit mask and corresponds to a few general options of the page display.

If it is set to "2" (or better say, the second bit set) the desktop items are locked and the toolbar won't be sliding out. You should reset it to 0 if you want the toolbar to appear by mouse hover event.

I am going to update this post with some more information as required to clarify a few things about the ActiveDesktop feature of XP.

First of all, the feature works great on XPProEmulation image. Note that to get it to work there didn't require any custom registry entries to be populated.
A few more tips here:
- Shell32.dll must be in the image. Well, since the feature doens' make sense out of Explorer Shell - Desktop is required - it is almost useless to say the Shell32 is required too.

- Make sure "Primitive: Browseui", "HTML Rendering Engine", "Primitive: Oleaut32" and "Primitive: Shlwapi" components are in your image. Last 3 components are probably in your image already if you resolved Explorer Shell dependencies.

- Make sure the user you are logged in have Admin privileges.

- Check if Desktop.htt file gets generated under <%UserProfile%\Application Data\Microsoft\Internet Explorer> folder.

- Make sure "Active Desktop Mover" object is registered. It will be mentioned under [HKEY_CLASSES_ROOT\CLSID\{72267F6A-A6F9-11D0-BC94-00C04FB67863}] key. Basically this object is what you see as the toolbar when you move mouse cursor over the top area of the page.

- Make sure the Low security settings for My Computer (local) Internet explorer zone are set.

To explain you why I ask you to check the above, I will have to explain you how the ActiveDektop feature works with a Web component setup. When you set it up in the Desktop Items dialog, Explorer Shell automatically generates an html based file - Desktop.htt - under a user profile folder (the one mentioned above). That HTT file is the Web page you see on your Desktop afterwards. It may contain a few components (Web pages) - they are all FRAMEs within the HTT html file (tag IFRAME used). The HTT page also has an object embedded on the page (OBJECT tag used) - Active Desktop Mover - that is basically the toolbar you see when you move the mouse cursor over the top side of the page. All the Web components and the toolbar appearances are controled by a set of values and subkeys under [HKCU\Software\Microsoft\Internet Explorer\Desktop\Components] key.

Please note that you can open that Desktop.htt file within IE as a regular dhtml page - you will notice it looks very like your Desktop. Obviously, there is no default association for .htt file on XP(e) so you will have to either manually associate it with IE or simply launch the following command line:
iexplore "%UserProfile%\Application Data\Microsoft\Internet Explorer\Desktop.htt"
(replace the %UserProfile% with the actual value of the env.var before the launch)

When launched, you will have to allow IE to render the page with the ActiveX control embedded (the Active Desktop Mover control) via a little popup appearing as the IE info bar.

All the above applies to IE 5.5 and any later version.

What launch in IE gives you? A perfect tool to test whether the toolbar appears or not when you move the mouse cursor over the top of the page. You can fire Regmon/Filemon (better Process Monitor) while running IE instance and monitor what's going on there when you navigate the browser to the HTT page. It will show you all the object Dlls loaded, registry access, etc. Or, better, run the above command line and the mouse hover test through DependencyWalker Profiler (open \program files\Internet Explorer\iexplore.exe, hit F7, type in the full path to HTT file and hit OK). It will show you in red if any Dlls is missing while you are testing the page.

Last update on the issue. When you target the feature for your XPe image and don't want to use a full blown image like XPProEmulation, please make sure you include the template for Desktop.htt. The template is going to be used by the shell to generate the actual Desktop.htt with the list of components you place on your Desktop. If you don't include the template in your image, Web Desktop feature implementation code will use a dummy HTT file that won't have a reference to the toolbar ActiveX component and therefore won't show it on mouse hover event.
Easieast way to get the HTT file in your image is to add "Images and Media" component. However, the component is quite big so you may end up just adding the HTT file only via your own component or TD Extra Files section. That file is is the XPe Repository anyway.

Good luck with debugging Web components on your ActriveDesktop!

XPe tip #19: Microsoft Access database

2007-04-13T12:53:00.000-07:00

How to get an Access database working on your image with ODBC? Answer is here.

Basically you need to include "Jet Database XXX" components in to your image config. Particularly the "Jet Database ODBC Support" component.

"Microsoft Data Access Components (MDAC)" component with all dependencies is also required.

XPe Lifecycle

2007-04-13T12:32:00.000-07:00

I thought Microsoft has covered the life cycles for their products well enough but questions about it keep coming. A recent thread in the newsgroup is a good example.

Very details answer to this was given out by the Product Team in their blog - XP Embedded Lifecycle Support.

Some more helpful links on the subject.

Life cycle of Service Packs for Microsoft Embedded products is detailed here.
Here is what it says about Windows Embedded:
Product Name General Availability Date Service Pack Support Retired Notes
Windows XP Embedded Service Pack 0 (RTM) 30-Jan-2002 22-Oct-2004
Windows XP Embedded Service Pack 1 22-Oct-2002 10-Apr-2007
Windows XP Embedded Service Pack 2 18-Jan-2005 Not Applicable
See Note Support ends either 12 months after the next service pack releases or at the end of the product's support lifecycle, whichever comes first. Visit the Lifecycle page to find the support timelines for your particular product.

Microsoft Support Lifecycle page for Windows XP Embedded.

According to Shayna Begun [MS], Feature Pack is not the same as a Service Pack - Feature Pack 2007 did not reset the support lifecyle for XPe. Regarding the next version of the product, it would be the next version of the Embedded product, so Vista would not pertain here.
Andy Allred [MS] confirmed that as well here. (you can find the whole thread here)

Just thought I'd gather all the related info in one place.

XPe tip #18: Hibernation doesn't work

2007-04-13T12:15:00.000-07:00

Things that can prevent hibernation from working on your runtime:

- Some driver conflicts or failures. The best way to fix these is to check the Device Manager to see if any exclamation marks there. Command version of the Device Manager - devcon - can also be used here. However, I personally prefer FBALog.txt and setupapi.log log files that are created under the %SystemRoot% and %SystemRoot%\FBA folders respectively.

- None or a wrong display and GART drivers installed. The same tip here - check the setupapi.log log and FBALog.txt files to see why the display driver, if was included and/or componentized for the platform, failed to install.
Note: Standard VGA driver, that takes place when you don't have native hardware driver installed, doesn't support hibernation.

- Some driver states are set to disallow the system going into standby mode. Easiest way to check this is to open a driver properties in Device Manager.

- Not enough disk space for hibernation file. Basically check here if the hiberfil.sys file is getting created on your target system partition.

- Hibernation is not enabled or you are using wrong HAL component. (Check either in TD or with Power CPL at runtime). In TD the hibernation can be enabled on the HAL (PC) component settings page - "Enable hibernattion support" checkbox under "Power Management Settings" section.

- Sometimes the "Disk Dump Drivers" component required. (The diskdump driver takes its part instead of scsiport driver when a RAM dump function is requested. It is just limited version in functionality though.)
Although from my earlier thinking the driver was required for the hibernation to work but in the newsgroup it was reported it is not. So, perhaps, it is only needed for the crash memory dumps to work. It doesn't hurt to add this very small driver component, though.

XPe tip #17: DST and EWF

2007-04-08T15:44:00.000-07:00

Pretty old topic but still no really good solution or workaround exists there on how to make DST working properly with the EWF enabled.

There has a bunch of suggestion been on how to make those two live together posted in the newsgroup: from using undocumented system's RealTimeIsUniversal flag to making your own time monitoring application that will switch or correct the system time if a DST time switch happens.

Perhaps, the only workaround that would work correctly is to disable the DST. Well, I can barely call this a workaround but at least with the DST off you won't have issues with the time changing unpredictably.

How to disable DST? Easy, just set this registry flag at run time:
[HKLM\System\CurrentControlSet\Control\TimeZoneInformation], "DisableAutoDaylightTimeSet"=dword:1

On related note, you can mess around time zone settings offline in TD if you explorer the following key:
[HKLM\System\CurrentControlSet\Control\TimeZoneInformation].
More info about this can be found on this XPe tip here.

XPe tip #16: Can be Eval SLX re-used?

2007-04-06T13:18:00.000-07:00

Recently I answered the following question in the newsgroup: is it possible to re-use SLX project created with eval version of the Toolkit with purchased copy of the tools?

We all know that there is no (easy) way to re-use database of eval installation with the full version of the toolkit. If you use it, you are going to end up with eval runtimes.

However, using the SLX (original project) create with eval version with either eval or non-eval versions of the toolkit is perfectly fine as long as you follow the following rules:
- You install the full (non-eval) version of the toolkit properly. You will have to completely uninstall eval version first including database.
- You re-import all the custom SLDs you've created to support that SLX project in to the non-eval database.
- You type in the right PID number in the RunTime field on Configuration Settings page of the loaded SLX in non-eval TD.

XPe tip #15: More useful tools..

2007-04-04T22:48:00.000-07:00

Continue finding good stuff on the NirSoft site.

Not sure how many times I had to use "at" command on embedded. Especially when I had to launch a command line within LocalSystem context (/interactive switch). Although always had to calculate timing and do a few additional commands in order to schedule and then delete the properly configured "at" command. Now I won't have all this problems with another NirSoft's utility - AtNow

Some good stuff for doing Window sniffing - from class names to style/ex-styles and etc. Two really nice utilities - WinListener and WinExplorer. The second is really good as it allows you to modify all the windows parameters via GUI instead of messing with the code and SetWindowsPos API calls.

Tools like ExeInfo and DLL Export Viewer are also nice. But there are lots of similar tools on the Web. Also, I am a fan of FAR Commander and a few plug-ins there do similar PE analisys and produces even better, more detail and visual results.

In driver and service area - ServiWin. Not as good as devcon but nice GUI makes it easier to see and filter out specific driver services. Also, it shows dependencies which is realy helpful on XP Embedded.

The CurrProcess tool is an extremely simplified clone of ProcessExplorer from sysinternals. Advantages - small and requires less dependencies in the image.

ActiveXHelper could be considered as an embedded [read: simplified] version of Microsoft OLEView tool.

DumpEDID and MonitorInfoView -interesting tools. Don't yet know how I am going to use them but I will.

USBDeview - useful, no doubt. Especially the stop/disconnect function. Although if I needed more info on a particular USB device or even a deep look into the interfaces and protocols exposed by the device, I would use an USB Analyzer.

ShellExView - could be useful when dealing with Shell extensions and namespaces issues.
OpenedFilesView - I am probably going to switch to this from similar sysinternals tools.

Many, many more tools there. Explore the utils part of the website by yourself!

XPe tip #14: The best command line ever

2007-04-04T22:21:00.000-07:00

While googling for some API call info I recently hit one website - NirSoft - that had a lot of nice tools and source code very useful for hacking and etc. We all know that we often have to do reverse engineering on embedded in order to understand, use or fix some system components functionality.

I am not going to talk about all the tools on that website but just one that made my day - NirCmd. Note: it is freeware! So much functionality in just one relatively small utility.

I have written myself tons of tools and utilities for embedded, even merged some of them. But never had so many functions implemented in one command line application.

The function I personally loved is - changing display settings on the fly. You just pass in the resolution and bit rate and you are done. Best of all, in some intermittent version they added refresh rate parameter.

Comment: the tool works great on Vista as well. This makes my life on Vista MCE much easier. Basically I can play with any TV (SD, HD, etc.) and have no wear the resolution rate is not supported or, on embedded, having no way to fix resolution problems without Display Control Panel applet included in the image.

Another tools that may be useful in changing screen resolutions and, more important, screen refresh rate is ChRes.exe. This utility is much simpler and all it does is calling to ChangeDisplaySettingsEx API. More about this tool you can find here.

XPe tip #13: SID issues

2007-04-03T15:47:00.000-07:00

We all know about possible issues that duplicated SIDs can create in your system setup and open a security hole on the network [ok, if you don't, read this]. Probably the best explanation to these issues were given by Mark Russinovich and Bryce Cogswell on the documentation page for NewSID tool.

Anyway, I am not writing this to start another thread on the SID duplication problem (if you Google for it, there are tons of similar discussion on the subject). I have recently answered a question in the newsgroup where the poster was surprised by not seeing the SIDs under HKEY_USERS key. It appeared that he was looking for long GUID-like subkeys but was playing with Minlogon based image. Here is the thread. As you may read, the poster was looking for actually Admin or User account SID which is not supported by Minlogon.

User SID duplication is not much an issue in Minlogon environment. However, there is still computer SID. You can find that SID somewhere in SAM hive (HKLM\SECURITY\SAM), typically listed in the list of Members keys. Much easier way to find out that SID though is to run PsGetSid utility from sysinternals.com. Here is where you can download it as a part of PsTools package.

Here is a list of well-known SIDs defined by Microsoft.
The one you're definitely going to catch with Minlogon image is S-1-5-18, a special account used by the operating system (aka LocalSystem account).

For Administrator account you would be looking for something like S-1-5-21-191058668-193157475-1542849698-500 on Winlogon images only. The only bolded part is machine dependent and generated randomly. All user accounts on the same system are going to have incrementally increased four last digits of the SID shown above. (1000, 1001, etc. instead of 500).
You can see the list of SIDs assigned to the user accounts on your system by exploring subkeys under [HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList] key.

And last, the good intro into what SID is on MSDN.

XPe tip #12: SetupAPI - nothing is more helpful than logging!

2007-04-02T14:25:00.000-07:00

To continue my previous post to this blog I want to mention another great tool that is always available to us, XPe developers, on target systems. When I say always I assume the right components are included - kernel and "Primitive: Setupapi". But you can barely find an XPe image that doesn't have the last component added.

Anyway, what is the SetupAPI log? It is a set of API functions that a setup application calls to perform application installation operations. The functions are available to develop a setup application that can install any type of application, from driver to user mode app. MSDN has a big and nice section dedicated to Setup API.

Since most of the issues we are fighting with on XPe are often related to components we ain't provided with source code for, especially third party drivers, having at least a way to analyze failures of those components with the logging tool is a great thing.

Anyway, some quick details for those who never dealt with Setu API logs. By Default the log is centrally located under %windir% folder and called setupapi.log. There are some registry entries to set up and configure how you want the logging to be performed. E.g., the most important value for us is logging level. Often the default log level is not enough to find out what's missing or went wrong with the image. So, increasing the level may help to get more information about the failures and possible get on the right track fixing them.

Here is the instructions on how you increase the log level. SourceQuest also has a freeware GUI utility that allows you to modify SetupAPI configuration parameters without remembering all the configuration registry paths. That utility - suplog.exe, which is already there and available for download, aims to simplify the capture and display of SetupAPI logs. BTW, changing most of the settings is dynamic and will be picked up by the new loaded instance of the app being installed and analyzed.

Quick note here. There is a very useful option for SetupAPI available that allows you to direct the logging to debugger output that you can easy capture with DebugView tool from sysinternals.com. It gives you a nice control over the log for your only component that you are trying to install at run time.

XPe tip #11: Debugging - VS2005 and WinDbg

2007-04-02T13:50:00.000-07:00

On Embedded devices we are often required to do some debugging various issues from driver install to application flow. With regards to applications and anything running in user mode everything is simple and straightforward - just stick to Microsoft Visual Studio (better the latest and greatest - VS2005 or coming Orcas) with Remote Debugging feature (firewall caveat on SP2). But how to handle driver debugging?

No easy answer there. The only option is probably KD (Kernel Debugger). There are a few debugger on the market (WinDbg, SoftIce, etc.) but I tend to think for XP and later only WinDbg has the real power to keep up with Microsoft changing environment. The latest version (6.6.7.5 to the moment) has lots of nice new features, although for XPe development we probably only need the basics. So, the winner is WinDbg (obviously, only 32-bit version is interesting option for us, XPe developers).

It requires a little bit of effort to setup the debugger to connect remotely your development PC, where you install the WinDbg tools, and target machine. Here is how you can enable remote debugging on SP2 (firewall setup, policies and etc.). And don't forget to setup the symbols.

For XP(e) you'd probably stick to COM or 1394 debugging. For Vista targets I loved the USB 2.0 kernel debugging support feature.

And you can certainly use WinDbg to debug services.

Very nice tutorial and lots of useful info about debugging with WinDbg I happened to fin on my favortie CodeProject.

XPe tip #10: Group Policies for locked down OS

2007-03-31T23:00:00.000-07:00

When we want to lock down an embedded image that uses a XP based OS, we often want to use Group Policy settings. But how to search and know which policy options are good to be used specifically for locking down the OS? Well, the first answer is - search the XPe newsgroup archive. We have discussed variety of group policy related issues there.

Just recently I unintentionally came across this very helpful KB article: http://support.microsoft.com/kb/278295. It basically lists most of the Group Policy settings that are good to be used to lock down a Terminal Server session on a Microsoft Windows Server 2003-based or Microsoft Windows 2000-based computer.

Here you will find another beautiful page (Group Policy Settings Reference) where you can download Excel document with most of the Group Policy listed with, more important, corresponding registry entries mentioned. Very helpful.

XPe tip #9: Disable Boot / Shutdown / Logon / Logoff system status messages

2007-03-30T22:47:00.000-07:00

Often there is a need on an embedded image to disable all [most of] the screens that have Microsoft branding on them or simply don't comply with the embedded device usage and GUI specs provided. Ideally, we'd want to replace the branding on those screens. This implies to text and graphics used there. However, the way XP OS is implemented (please note - this is changed in Vista!) there is no legal way to replace those screens without messing [hacking] with resources of the Microsoft binaries.

Anyway, there is still one Group policy option exists that is helpful at least to disable some screens. So if you want to disable Boot / Shutdown / Logon / Logoff system status messages (typically shown by Winlogon), just set the following registry entry:
[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System],"DisableStatusMessages"=dword:1.

You can pre-set the value in TD (your own component or Extra registry section) or at run time (a command during FBA, RegMigrate undocumented feature of FBA, Run/RunOnce request, Explorer Startup item and etc.).

XPe tip #8: Show Desktop icons

2007-03-30T22:42:00.000-07:00

This is a simple and known one.
Just want to mention the appropriate registry entry.

The value for the Group policy option that allows you to enable or disable the Show Desktop Icons feature of XP(e) is stored here:
[HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer],"NoDesktop"=dword.

XPe tip #7: Hide drives in Explorer shell

2007-03-30T22:31:00.000-07:00

I know this is an old one but questions about how to accomplish that are still showing up in the newsgroup once in a while.
The question is how to hide all local drives or some drives in the system that uses Explorer as the shell. Typically the question comes up on the way to lock down Explorer shell based embedded system.

The answer is simple - use Group Policy. There is a Group Policy exists that allows you to hide particular drives in My Computer folder of the system for specified user accounts. As with almost all Group policy settings, there is corresponding registry option that is doubled in global and per user branches:
User Key: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
System Key: [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
Value Name: NoDrives
Data Type: REG_DWORD (DWORD Value)

The "NoDrives" value uses a 32-bit word to define local and network drive visibility for each logical drive in the computer. The lower 26 bits of the 32-bit word correspond to drive letters A through Z. Drives are visible when set to 0 and hidden when set to 1.
If your not happy working in Hex, add these decimal numbers to hide the drive(s):
A: 1, B: 2, C: 4, D: 8, E: 16, F: 32, G: 64, H: 128, I: 256, J: 512, K: 1024, L: 2048, M: 4096, N: 8192, O: 16384, P: 32768, Q: 65536, R: 131072, S: 262144, T: 524288, U: 1048576, V: 2097152, W: 4194304, X: 8388608, Y: 16777216, Z: 33554432, ALL: 67108863

For example to hide drive A and drive D, you would add 1 (A) + 8 (D) which means the value should be set to "9".
To disable all the drives set the value to "67108863".

The above only hide the drives in My Computer. Sometimes, however, preventing access to the contents of selected drives may work even better in a locked down OS. Then you'd want to use another registry value there - NoViewOnDrive. The same registry path both in HKLM and HKCU branches. Its value is structured the same way as the NoDrives's one.

XPe tip #6: Completely hide the Taskbar

2007-03-29T22:06:00.000-07:00

On embedded XP we often (almost always) want to customize shell UI. The best way to do that is to get rid of Explorer shell and implement your own custom shell application. But if you don't have enough skills to write often a complex application, or you simply don't have enough time to do so, or, worse, Explorer shell must be running in order to get some functionality out of the box. Many examples to this have been posted to the XPe newsgroup, e.g. Autoplay feature.
So, what if you must have Explorer shell running but you still have to lock down OS and avoid users messing with files on disk and etc.
You can always have your own application running in full screen mode and covering all other windows from Microsoft (Desktop, Taskbar, etc.). But we all know that even with a proper Group Policy setup you won't be able to completely hide everything. There may also be cases where Taskbar will be showing up on the top of all other windows in the system regardless of the system settings. Only cure is to get control in your hands and completely hide the Taskbar (no, don't kill it - you still need Explorer's functionality). Here the tricks I came up with for hiding Taskbar.

First of all, lets pre-setup in TD the auto-hiding behaviour of the Taskbar. Although it sounds easy - just set the right registry flag - but it is not. For most Taskbar and some Start Menu options the Explorer keeps the settings stored as a set of bits in some registry values. Certainly, those bits are not documented. No problem, we always have helpful Regmon and by spending a little bit of time you'll figure out the interesting registry entry is [HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\StuckRects2],"Settings". As I mentioned earlier, it is a binary structure. Long time ago I posted a script on xpefiles.com that changed the right bits of that value to make the Taskbar auto-hiding enabled. The readme of that posting would explain how to launch the script properly and set it up in TD.

Now lets go deeper and just disable the Taskbar once and for all.
What you want to do here is just create and compile a simple app that makes a call to FindWindow() on "Shell_TrayWnd" window class name and then just do a ShowWindow(SW_HIDE) for this window handle. The same you should do with "Progman" and Desktop windows. You better also disable the windows (EnableWindow(FALSE)) before hiding.

I actually do have this app written. The code is far from bring production quality (it was just an experiment, after all!) but I will share it with you, folks, as soon as I get my hands on that drive (I took it out and put it on a shelf here quite a while ago). Will do that very soon, I think.

MCE tip #1: TBP (ToolBar Persisted)

2007-03-29T00:48:00.000-07:00

I have recently had to investigate whether it is possible to remove mouse-over toolbar from MCE (Media Center Edition application). That toolbar seems to have similar (actually, the same) implementation both on MCE 2005 and Vista MCE.

On Vista MCE (not sure about MCE 2005 - didn't have time to check it out there) there is a nice item under Tasks menu - "Media only" - which purpose is basically to make the app to run full screen and hide the mouse toolbar at the right top corner of the application window. This option however doesn't persist. If you restart the application or simply reboot, the mouse toolbar comes back (it only appears when you move mouse cursor while the app is running, of course).

I got around this by doing the following two things:
- making my monitoring agent application (see the other post "Vista tip #1") to watch on the MCE windows (certainly had to hack around a little bit first to get to know all the necessary window class names and etc.). If something wrong happens to the full screen MCE app window, I set it back - always on top, full screen, foreground, etc.
- completely removing the mouse support from the image. Not PS2 nor an USB mouse would work there, hence no way for end user to mess with the mouse-over toolbar of the MCE app.
(I needed the second also to get rid of the mouse cursor there).

Anyway, this tip is not about how to remove the toolbar. It is rather opposite - how to make it persistent so that all the MCE controls including the mouse-over toolbar are always there. (in PC mode users may like it)
For MCE unattended setup there is an option (TBP) in XML file that allows you to specify whether mouse toolbars always appear in the Windows Media Center UI: http://technet2.microsoft.com/WindowsVista/en/library/524ca8fc-af68-4e5a-9d68-3cc678a270091033.mspx
Now, where is the registry key is located? Here it is: [HKCU\Software\Microsoft\Windows\CurrentVersion\MediaCenter\Capabilities],"TBP"=dword:1.

XPe tip #5: Direct IO operations from Win32 mode

2007-03-27T15:19:00.000-07:00

Sometimes there may be a need to be able to control some hardware directly on an embedded device without having the appropriate device driver. After all, XPe is all about RAPID development and you may not have enough time or skills to develop the driver.

This is where some nice 3rd party tools like DirectIO come to the picture. Basically such applications (include their own drivers) will allow you to stick to Win32 API (CreateFile and etc.) and be able to make a direct queries to the selected and configured device (read/write/configuration/enumeration/etc.).

Long time ago I posted the list of some of those apps available on Internet to the newsgroup. Here is what that post mentioned:
- WinIO from internals.com,
- DirectIO from direct-io.com,
- DriverLinx's Port I/O Driver. DLPortIO component on http://www.xpefiles.com/

If you need it, check out all of them.

XPe tip #4: Image restore - general idea

2007-03-27T00:30:00.000-07:00

While posting to the newsgroup today I described some common rules (maybe not rules but thoughts) that might be helpful to follow while creating an image that is to be used in a restore scenario for your device.

In general the idea is simple - you have to go offline to be able to copy over/restore/replace the current XP(e) based OS. This means you want to boot another image of yours [off a XPe or PE bootable CD for instance, or bootable UFD, or from another, better hidden, partition on the same hard drive or from another hidden hard drive, or do a remote boot for a DOS/XPe/PE image, etc.] and be able to copy the *main* XPe image over to the target storage.
Obviously, for wiping out disk you can use delete [CMD's *del*] or format or diskpart or whatever tool you like and/or required by your system security spec (maybe you need to clean every single cluster on the hard disk before the restore).
It may be better to use robocopy for copying files than xcopy. There are other great and reliable 3rd party tools but not free (e.g., xxcopy). Or you can pull the image down from a network if acceptable and exists.
If the restoration image needed to be compressed and/or encrypted (for saving some space or to use an invulnerable encryption) you could always use either one of Resource Kit or PE tools or some other 3rd party tools (freeware is preferable, of course). The cabarc is an example here. Or you can use built-in NTFS compression if the underlying restoration media allows that (e.g., UFD or HDD approach).
Another point should be made about the restore-bootable image itself. If PE used, you may want to remove all the unnecessary extra packages from the image before sysprep. If XPe based, just create a small footprint image with a very limited number of components to support basic operations such as file system operations and/or network [MS or base TCP/IP] and/or whatever custom component dependencies you are adding there. Likely the image should be Minlogon based with either a custom shell or CMD shell. No need to resolve all the platform drivers in that image since you can always disable the hardware wizard and PnP system popups.

XPProEmulation update: "ghost" Kenel-FP1 and CompactPCI stack

2007-03-26T15:31:00.000-07:00

Thanks to Jimt, a couple of issues were found, identified and fixed in the XPProEmulation image.

The main issue was that a weird "Kenel-FP1" component was appearing in TD during dependency check for those who used XPProEmulation project for FP2007. The strangest thing was that myself I couldn't reproduce the issue, although I did see that component mentioned in the SLX when I did a binary unicode search in the file.

After some investigation it appeared that most likely it was me who played too much with CTP1 and CTP2 versions of FP2007 and accidentally brought in and left the R3300 version of the "1394 Kernel Debugger Support Library" component that was dependent on the "ghost" Kenel-FP1 component. Well, truly speaking, it is the TD auto-upgrader who couldn't really downgrade that component when I went from CTPx to RTM of FP2007, but obviously I am responsible for any bug in XPProEmulation anyway :-)

Anyway, I've fixed the Kenel-FP1 issue and uploaded the updated version of the SLX on www.xpefiles.com.

Long time ago I had to make a decision to include CompactPCI stack solely due to the reason that the "CompactPCI Hot Swap Support" is a "software" component and I wanted to include it into the project. This component, however, requires some hardware related stuff ("Generic CompactPCI Chassis" and "Generic CompactPCI CPU board" components) and I resolved them to minimize the effort and build errors for the devs who're going to mess around the XPProEmulation.
Quite frankly, so far I haven't seen a need for the CompactPCI stack being included so I am changing my mind now and moving that stack out the project. The latest updated SLX on xpefiles.com has all three components disabled.
The readme.txt, updated with the project, reflects all the changes.

MCE links

2007-03-26T14:34:00.000-07:00

I am now getting into the exciting world of media. More precisely, Microsoft Media.

MCE (Media Center application) is really great. However, as any other piece of software, still requires some tweaking often to get the desired behaviour or hidden functionality.

I will start here from listing my favorite blogs on MCE topics:
Matt Goyer's blog
Chris Lanier's Blog
Ian Dixon's blog
Charlie Owen's blog
Mark's MCE Blog

Some useful links about MCE as well:
The Green Button

I will continue adding links to the above list time to time.

Vista tip #1: Dialog/message box auto-reply

2007-03-24T22:19:00.000-07:00

For those who is interested...

The EnableDefaultReply functionality works ok on Vista [tested on Ultimate]. Note: the same way as on XP you don't really need to reboot or logoff to get that registry entry change in affect. The registry value gets read every time the MessageBox API is called.

There is also so-called Task Dialog API that is new to Vista. Nice and fancy thing but is there a way to intercept/suppress a task dialog system-wide? Looking for a registry entry or something similar to what's been done for MessageBox. Obviously, to answer that we need to go deep with a debugger and start somewhere around TaskDialogIndirect call. Will take some time to investigate this, I am sure.
Meanwhile I just wrote a watch-dog applicaiton that takes care of MessageBox amd TaskDialog windows in the system. Had some troubles to make it to work as a service (you know, all the services finally were moved from all applications to a separate Session 0 in Vista) but fixed that in a nice way.
Call me picky though but I still want to find a workaround (read: hackaround) to be able to suppress or, better, auto-reply the task dialogs by setting a registry flag.

XPe tip #3: XPProEmulation

2007-03-24T22:04:00.000-07:00

This one is getting popular on the newsgroup. I keep often advise people who got stuck with some tough dependency problems to try to use my XP Pro Emulation project. Yes, it is huge project and still requires some work to adopt to your own hardware platform. But the benefit is nice - you will know whether your app or driver will work on XPe for sure.

here is what I say in the project description (readme.txt included within the same zip that holds the SLX):
Purpose: Emulation of XP Pro OS using XPe Repository software components (2024 components!). Note; the number of components included keeps changing release to release but always above 2000.

Method: CMI automated script was used to add all "Software" based components from XPe database to the SLX project configuration. A few "Hardware" components were also added.

Tested: "Standard PC"-based configuration as well as "ACPI Uniprocessor PC"-based configurations tested with ACPI-compliant x86 platform (AMD, 512RAM, ...).

Recommendations:
Turn OFF the "Auto-resolve Dependency" option in TD. If you have the option on, it will add/remove/modify some important and/or unnecessary components to/from/in the Configuration. this is quite old requirement and you may not need to follow it since with FP2007 version of the project the build got much cleaner.

Run TAP on your target device and include all the component dependencies from the result macro component to your image configuration. Better do the Dependency Check and then manually resolve all necessary tasks. Modify "Target Device Settings" in order to build the image for your test hardware platform configuration. You may add/remove any components to/from the build if needed.

There have been a number of threads in the newsgroup about that project. Read them if you have time.

If you plan on using the SLX project, I beg you - only use FP2007 toolkit. Otherwise I predict you will be sending me emails asking why the project is so damn slow to load and take so long to build with SP1 and SP2 tools and so often crashes there.

XPe tip #2: Dependencies (round 2)

2007-03-24T21:39:00.000-07:00

XPe tip #2:

Let me continue about the "dependency tools"...

We all know that currently there is nothing provided by Microsoft that is built in the XP Embedded Toolkit that will help you exploring dependencies of particular components. Well, there is now (FP2007) XPECMD but it is way too far from being a perfect way since you got to use heavy graphic development tools like Target Designer and you don't really want to switch back to command line just to take a sniff of the stack of particular component.

Long time ago I came up with the nice (yes, I still consider it nice) package - XPeTools - that include some dependency exploring functionality to extend TD in a way. The first version I did was for done for XPe RTM. But since then I've been working on it - fixing bugs and adding some new functionality - for last couple years.
Take a look at the DependencyExplorer component of the XPeTools package on xpefiles.com.

Also, don't forget to glance at the ConfigurationExplorer component from the same package. There is probably no analogs from MS and other MVP. It basically allows you to explore dependencies of components included in the current config. You will notice it shows dependencies - list of components - that are only included in the current config.

PS. XpeTools component scripts are encrypted so it makes it harder to reverse engineer the techniques I used there.

XPe tip #1: Dependencies

2007-03-24T21:26:00.000-07:00

XPe tip #1:

With XPe development you always fight with dependencies, don't you?
So, what are the tools you can have that may help you on the dependency exploring adventure?

Obviously, Dependency Walker. You got to love the Profiling feature of that tool. It is basically all your need to get the knowledge of static and dynamic dependencies of an app or driver or system component.

Sysinternal.com (now just part of Microsoft) gives you the best tools ever created for Windows Operating systems. These must be a part of Windows Resource Kits, however the sysinternals tools evolve fast and changed often. Here is a few of them that are the most useful for XPe devs:
Process Monitor
Registry Monitor (aka Regmon)
File Monitor (aka Filemon)
Disk Monitor (aka Diskmon)
Process Explorer

And many, many others.

My own XPe newsgroup posts database

2007-03-24T21:18:00.000-07:00

I got to mention this here. I've been posting to Microsoft XPe newsgroup for quite a while as KM and always been saving all my posts (Outlook Express archive). The fact is that for the moment (March 20, 2007) I've got 6523 messages in that archived folder! Not bad, huh? :-)

I am thinking (read: planning) on exposing that database of "answers in XPe area" to the public some day. Perhaps, I will "somehow" link it to this blog. What's really needed is - Search engine! Otherwise it is going to be useless to see my bad english reading those numberless posts.

Starting XPe tips&tricks

2007-03-24T21:16:00.000-07:00

I am starting new type of posting: XPe Tips. Will post here whatever tips and tricks we come up with while posting to microsoft public XPe newsgroup.

The first and ever trick - please read and search the online product documentation. You will learn that it often has answers to most of your questions.

XPe useful links

2007-03-24T21:05:00.000-07:00

I will be doing this blog primarily focusing on Microsoft product reviews, tip&tricks and development stuff.

Let me start from my favor ties: Windows XP Embedded and Windows Embedded CE.

Some useful links for XP Embedded product:

Latest XP Embedded online documentation

XP Embedded public newsgroup google archive

XP Embedded Microsoft Forum

Windows XP Embedded Tips

Microsoft OEM Secure website

XP Embedded public newsgroup MSCE archive

Windows XP Embedded Team Blog

XPe 3rd party components

KM's blog - finally!

2007-03-24T20:41:00.000-07:00

The blog has been created!
I can't believe I did it. I hate writing, posting, publishing. But I feel I really need to create something for community.