Saturday, March 31, 2007

XPe tip #10: Group Policies for locked down OS

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: 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.

Friday, March 30, 2007

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

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:

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

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:

XPe tip #7: Hide drives in Explorer shell

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.

Thursday, March 29, 2007

XPe tip #6: Completely hide the Taskbar

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 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)

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:
Now, where is the registry key is located? Here it is: [HKCU\Software\Microsoft\Windows\CurrentVersion\MediaCenter\Capabilities],"TBP"=dword:1.

Tuesday, March 27, 2007

XPe tip #5: Direct IO operations from Win32 mode

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,
- DirectIO from,
- DriverLinx's Port I/O Driver. DLPortIO component on

If you need it, check out all of them.

XPe tip #4: Image restore - general idea

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.

Monday, March 26, 2007

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

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

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 has all three components disabled.
The readme.txt, updated with the project, reflects all the changes.

MCE links

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.

Saturday, March 24, 2007

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

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

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, ...).

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)

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

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

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. (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

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

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

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!

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.