In Part 1 of this series we figured out where the logs are located. In Part 2, we learned how IBW works and what messages get written to which log files. In this final section, we’ll dig deep into the logs to determine the cause of our problem and how to fix it.

Interpreting the logs

Now that we have some way of viewing the logs, we can start to figure out what went wrong.

When you open up the logs, they’ll look something like this:

Because that’s nearly impossible to read as a screenshot, I’ve taken the log and organized it into a nice, pretty table and highlighted the important parts.

Setuperr.log:

From looking at setuperr.log, we can see that we got a few error messages that all point to an error within DISM. DISM messages mean that we should take a look at cbs_unattend.log:

Again, a picture of the log is nearly impossible to read, so here’s the important part in table form:

When you’re scanning for errors, you’ll likely to see the first 2 error messages (shown in the above surrounded by <Ignore these messages> in the cbs_unattend.log. These can be safely ignored.

As you can see, the first real “Error” that’s reported is that the WinEmb-IE-Core.cab file was not found. Looking one message above the error, we can see that DISM is trying to install the file (it’s the “Internet Explorer 8 Engine and Display” package, which I included in my configuration).

For the purposes of this demo, I deleted this package from my Distribution Share, so this error message makes perfect sense. The package isn’t there, DISM needed to install the package, so the DISM operation failed, and thus the entire setup failed.

Now, we can go back and look at the original error message popup that we saw, “Windows Setup failed to install packages or apply component settings while offline servicing the image.” Now that we’ve gone through the logs, this error message makes sense. Setup failed to install a package. The logs say that the WinEmb-IE-Core.cab package is missing, so I should try and figure out why it’s not there, and make sure it is there in the future so that my installation will work.

Other Examples

Now that we’ve solved one mystery failure, let’s take a look at a few other common problems to give you an idea of what to look for:

Shown below, the error message “STATUS_SXS_FILE_HASH_MISMATCH” typically means that the setup media is corrupted. Recreating the IBW media (either re-burning the DVD or re-copying files to a USB drive) generally solves the problem. If that doesn’t fix the problem, your original download could be corrupted, so re-downloading and recreating the setup media may help.

“ERROR_CRC” is another typical file corruption message. The same steps suggested above may help.

“E_OUTOFMEMORY” means that your device has run out of RAM when running setup. This may occur more often on devices that have both low disk space and low RAM capacities or installations to removable media such as USB drives. The reason for this is that IBW attempts to automatically create a pagefile during setup to act as extra memory. Devices with low disk space may not have enough room for both the installation and the pagefile. Pagefiles cannot be created on removable media, so it is possible that your installation will use up all available RAM and then fail.

If you run into this situation, you can use the steps in Punit’s “Offline Build” blog article to build your image on a device with higher hardware specifications.

Additional Help

The errors that we just examined were actually fairly easy to diagnose. Over the lifetime of our product, you may run into errors where you can’t quite figure out what’s going wrong. In such a case, there are several avenues you can look to for support.

1. The Windows Embedded MSDN forums are a great source of support. Not only can you get help from your peers, embedded experts, and Microsoft MVPs, but the Standard 7 product team also directly monitors these forums and helps out as much as possible. For questions related to IBW and ICE, the “Standard 7: Tools” sub-forum is the best place to ask. You can also use the “Community -> Ask a Question” menu item in ICE to access these forums.
2. Use the “Community -> Send Feedback” menu item in ICE. This menu item will open up a website that allows you to submit bug reports directly to Microsoft. Our product team also directly monitors these bugs and will help out as much as possible while Standard 7 is still in “Release Candidate” mode. After Standard 7 has officially released, please work with your distributer for official support.

Note: Now that you know how to find and copy the logs, attaching the entire Panther folder to any forum post or bug report you create is a very good idea! The logs are critical in helping our team to diagnose IBW issues. If you forget to attach them, usually the first response you’ll receive from us is, “Can you send us the logs please?”

If you have any common error messages that you’re having trouble figuring out or any suggestions for us on how to better handle error conditions, you can also feel free to post a Comment to this blog article.

Thanks for reading!

- Robert

Introduction

This is the third and final blog in a series of articles which discusses the troubleshooting and diagnosis of driver installation issues in Windows Embedded Standard 7. Previously we presented the format of the SetupAPI.dev.log file and an example driver installation scenario. Now we will begin by enumerating some common driver installation issues you may encounter in Windows Embedded Standard 7.

Common driver installation issues

Most driver installation issues fall into the below categories.

1. No compatible driver available
2. Missing device class installer
3. Missing dependencies
4. Undiscoverable devices

No compatible driver available

This can arise either because there is:

1. An in-box driver is available for a device but it wasn’t discovered.
2. No in-box driver is available for a device.
3. No driver update for device is available via Windows Update (WU).

Let’s start by looking at the first issue, which could be caused by a device not being connected to the target machine during setup. Below is an example from the SetupAPI.dev.log where we encounter this issue.

>>> [Setup Root Device Servicing]
>>> Section start 2010/02/23 12:29:53.078
set: This is an INSTALL.
set: Iterating through 1 <rootDevice> elements.
set: Processing device ROOT\COMPOSITEBUS\0000
set: Entering install for device ROOT\COMPOSITEBUS\0000
set: Could not open the device information element for device ROOT\COMPOSITEBUS\0000. Trying to create one. GLE = 0x00000000
set: Processing 1 <properties> elements.
set: Processing 1 <property> elements.
dvi: {DIF_REGISTERDEVICE} 12:29:53.078
dvi: No class installer for 'System devices'
dvi: Using exported function 'CriticalDeviceCoInstaller' in module 'C:\Windows\system32\SysClass.Dll'.
dvi: CoInstaller 1 == SysClass.Dll,CriticalDeviceCoInstaller
dvi: CoInstaller 1: Enter 12:29:53.078
dvi: CoInstaller 1: Exit
dvi: Default installer: Enter 12:29:53.078
dvi: Registered: ROOT\COMPOSITEBUS\0000
dvi: Default installer: Exit
dvi: {DIF_REGISTERDEVICE - exit(0x00000000)} 12:29:53.078
ndv: {DiInstallDevice(ROOT\COMPOSITEBUS\0000)}
dvi: Set selected driver complete.
dvi: Set selected driver complete.
dvi: {Build Driver List} 12:29:53.078
dvi: Searching for hardware ID(s):
dvi: root\compositebus
cpy: Policy is set to make all digital signatures equal.
dvi: Enumerating INFs from path list 'C:\Windows\inf'
inf: Searched 0 potential matches in published INF directory
inf: Searched 32 INFs in directory: 'C:\Windows\inf'
dvi: {Build Driver List - exit(0x00000000)} 12:29:53.156
dvi: {DIF_SELECTBESTCOMPATDRV} 12:29:53.156
dvi: No class installer for 'System devices'
dvi: CoInstaller 1: Enter 12:29:53.156
dvi: CoInstaller 1: Exit
dvi: Default installer: Enter 12:29:53.156
dvi: {Select Best Driver}
! dvi: Selecting driver failed(0xe0000228)
dvi: {Select Best Driver - exit(0xe0000228)}
! dvi: Default installer: failed!
! dvi: Error 0xe0000228: There are no compatible drivers for this device.

In looking through the log we notice that there were no compatible drivers for this device. However, we want to verify if we have an in-box driver for this device before searching for one externally. The device ID is specified in the log, observe the below entry from the above text log section.

set: Processing device ROOT\COMPOSITEBUS\0000

Using the ICE search functionality, we can search by device ID for a package. We need to click the “Distribution share”, “Search driver hardware ids” and “Search file names in packages” checkboxes then enter “root\compositebus” in the “Find what” textbox (Note: we can enter a partial string).

We have found an in-box driver package for this device “Composite Bus Enumerator Driver” which can be added to our image to fix this problem.

Below is a snippet from a SetupAPI.dev.log which illustrates the second and third issues. In this case, we have verified that there isn’t an in-box driver for this PCI device and there aren’t any driver updates available via WU. Our only recourse is to search for a driver externally from the manufacturer.

>>> [Setup online Device Install (Hardware initiated) - pci\ven_110a&dev_4036&subsys_00010001&rev_09\4&4b78d08&0&50f0]
>>> Section start 2010/03/04 14:36:42.013
ump: Creating Install Process: DrvInst.exe 14:36:42.028
ndv: Retrieving device info...
ndv: Setting device parameters...
ndv: Searching Driver Store and Device Path...
dvi: {Build Driver List} 14:36:42.044
dvi: Searching for hardware ID(s):
dvi: pci\ven_110a&dev_4036&subsys_00010001&rev_09
dvi: pci\ven_110a&dev_4036&subsys_00010001
dvi: pci\ven_110a&dev_4036&cc_020000
dvi: pci\ven_110a&dev_4036&cc_0200
dvi: Searching for compatible ID(s):
dvi: pci\ven_110a&dev_4036&rev_09
dvi: pci\ven_110a&dev_4036
dvi: pci\ven_110a&cc_020000
dvi: pci\ven_110a&cc_0200
dvi: pci\ven_110a
dvi: pci\cc_020000
dvi: pci\cc_0200
cpy: Policy is set to make all digital signatures equal.
dvi: Enumerating INFs from path list 'C:\Windows\inf'
inf: Searched 0 potential matches in published INF directory
inf: Searched 35 INFs in directory: 'C:\Windows\inf'
dvi: {Build Driver List - exit(0x00000000)} 14:36:42.293
ndv: Selecting best match from Driver Store (including Device Path)...
dvi: {DIF_SELECTBESTCOMPATDRV} 14:36:42.293
dvi: No class installer for 'Ethernet Controller'
dvi: No CoInstallers found
dvi: Default installer: Enter 14:36:42.293
dvi: {Select Best Driver}
! dvi: Selecting driver failed(0xe0000228)
dvi: {Select Best Driver - exit(0xe0000228)}
! dvi: Default installer: failed!
! dvi: Error 0xe0000228: There are no compatible drivers for this device.

Once we have the driver and have verified that it’s functional, we can add this driver to our image as an out-of-box driver. Below are several examples of how to implement this in Standard 7. The first two examples assume that the driver is distributed with raw driver payload (e.g. .INF, .SYS files etc.). The third example is where the driver is installed via a setup application (e.g. .EXE, .MSI etc.).

1. If using the Image Based Wizard (IBW) tool for installation, you can choose to add additional drivers by selecting the “Browse” button on the “Confirm drivers to install” screen. After pressing the “Browse” button, you can select the directories where the payload for each driver resides. You can have multiple drivers in a single directory.

2. If building an Answer File (AF) using the Image configuration Editor (ICE), you can add the folder containing the driver payload to the “Out-Of-Box Drivers” folder in the Distribution Share (DS). Then in ICE right click on the driver path choosing “Insert Driver Path Pass 2 offlineServicing” to add this setting to the AF. Note: choose “Insert Driver Path Pass 1 windowsPE” for boot critical drivers. As in IBW, you can have multiple drivers in one directory.

3. If the out-of-box driver in installed via a setup application (e.g. .EXE, .MSI etc.), you can run the setup application after booting into the image then run the Sysprep tool.

Missing device class installer

In this scenario the driver is present for the device; however upon installation a required device class installer is missing therefore the driver installation fails. For specific device setup classes, there is a required device class installer which is responsible for setup operations specific to this device setup class. Below is an example.

>>> Section start 2010/01/28 16:05:57.100
ump: Creating Install Process: DrvInst.exe 16:05:57.100
ndv: Retrieving device info...
ndv: Setting device parameters...
ndv: Searching just Driver Store...
dvi: {Build Driver List} 16:05:57.115
dvi: Searching for hardware ID(s):
dvi: scfilter\cid_417374726964
cpy: Policy is set to make all digital signatures equal.
dvi: Enumerating INFs from path list 'C:\Windows\INF'
inf: Searched 0 potential matches in published INF directory
inf: Searched 31 INFs in directory: 'C:\Windows\INF'
dvi: {Build Driver List - exit(0x00000000)} 16:05:57.193
ndv: Selecting best match from just Driver Store...
dvi: {DIF_SELECTBESTCOMPATDRV} 16:05:57.193
dvi: No class installer for 'Smart Card'

Device class installers are located in Windows components within non-driver Standard 7 packages. A Windows component is the smallest unit of installation for a Windows feature. Below is a list of all of the device class installer components for Standard 7 and what package they are contained in. Note: most are in the “Windows Embedded Edition” foundation package, so they are installed by default. However some of these components are contained in separate packages. In this case the class installer we are missing is in the “Microsoft.Windows.Hardware.Devices.ClassInstaller.SMARTCARDFILTER-DriverClass” component which is in the “Credentials and Certificate Management” package. Therefore we need to add this package to our image to fix the issue.

Missing dependencies

Device driver installation can fail because there are missing dependencies, which can be for any of the following:

• Device driver dependencies
• Device class installer dependencies
• Device co-installer dependences

A device co-installer is a .DLL that assists in device installation. Device co-installers are called by setup as “helpers” for device class installers.

In the below snippet from the SetupAPI.dev.log we notice that we failed to load the device class installer “WindowsSideShowClassInstaller” (in AuxiliaryDisplayClassInstaller.dll).

set: Calling DIF_FIRSTTIMESETUP for class {997b5d8d-c442-4f2e-baf3-9c8e671e9e21} (Windows SideShow)
dvi: {DIF_FIRSTTIMESETUP} 15:02:08.171
dvi: Using exported function 'WindowsSideShowClassInstaller' in module 'C:\Windows\system32\AuxiliaryDisplayClassInstaller.dll'.
dvi: Class installer == AuxiliaryDisplayClassInstaller.dll,WindowsSideShowClassInstaller
!!! dvi: Loading module 'C:\Windows\system32\wpd_ci.dll' failed.
!!! dvi: Error 126: The specified module could not be found.
!!! dvi: Error 126 loading CoInstaller(wpd_ci.dll,CoDeviceInstall)
!!! dvi: Error 126: The specified module could not be found.

However we have confirmed that we have this .DLL in our image. We can verify this by searching for this .DLL using the ICE search functionality.

The .DLL “AuxiliaryDisplayClassInstaller.dll” for this device class installer is present in the “Windows Embedded Edition” foundation package. The actual issue is that we are missing dependencies for this .DLL. If we use the ICE search option again searching for “sideshow” we come up with a list of results.

We notice that we don’t have the package “Mobility Center and SideShow” in our image. This package contains needed functionality for sideshow and it brings in a device driver for sideshow (Windows Sideshow Enhanced Driver), so we try adding this package to our image and discover that it fixes our issue.

Undiscoverable devices

There are cases where a device will not be discovered within setup and/or required driver .INFs will not be included:

• Within the Windows Preinstallation Environment Phase (WinPE) of setup certain devices cannot be discovered because there is no support for them. In Standard 7, there is no support to install from a previous operating system (downlevel phase) which can mitigate this (setup in Standard 7 always initiates from WinPE).
• Certain driver .INF files are included by other .INF files because they contain common data for several drivers. These .INF files may not contain device IDs, so they aren’t discoverable.

To mitigate this, the following solution is suggested.

1. Install Windows 7 Ultimate on the target machine you will install Standard 7 on, making sure that all the necessary device drivers are installed and that all of the devices are functional.
2. Run TAP.EXE (available from the Standard 7 tools) to generate a devices.PMQ file by running “TAP.EXE /q /o” on the target machine.
3. You can now import the generated devices.PMQ file from within IBW or ICE to add all the required driver packages to the Standard 7 image.

Conclusion

You can build on the techniques outlined here to solve more difficult Driver installation issues. There are more ideas which I will share in future articles.

For background and insight into why and how the Standard 7 in-box drivers have been componentized and packaged, look out for the whitepaper “Componentization of Device Drivers in Windows Embedded Standard 7”.

Best of luck!

- Mark

Many of you must be wondering what SMI settings are and how these settings could be used to configure Windows Embedded Standard 7 image. Let me explain…

What is an SMI Setting?

Settings Management Infrastructure (SMI) is a schema that is used to define mutable operating system settings. A mutable setting is a variable setting in which the value of the setting can be changed, either by other components or by the user or administrator. For example, user-preferred fonts and font colors are mutable settings.

Mutable settings can reside in any settings store in the operating system, such as the registry, .ini files, or some other public store, such as the IIS Metabase or the WMI repository. These settings are exposed to OEMs and Corporations to enable customization and make deployment of the OS easier.

In Windows Embedded Standard 7, these settings are included with each component in a Feature Package. In ICE, once you select a feature package to be included in your answer file, you will be presented with a list of settings that correspond to every component in the package you selected.

What is a ‘Pass’ and what effect does it have on settings?

A “pass” is a certain phase during an automated unattend setup in which unattend settings are applied. A setting could apply to one or more passes. There are 2 types of unattend passes: online and offline passes. Offline passes are staged with an OS image that is not currently running. Offline Servicing is an offline pass. Online passes occur on an actively running OS and are used to apply settings and packages during Windows Setup. The following passes are online passes: Generalize, Specialize, Audit System, Audit User and OOBE System.

• Generalize: All machine-specific information is removed from the image
• Specialize: Machine-specific information for the image is created
• Audit System: Allows OEMs and corporations to add additional device drivers and applications to the image
• Audit User: Similar to the Audit System pass but these settings are processed after users log in, not before they have logged in
• OOBE System: Includes pre-OOBE settings, as well as settings from winbom:OOBE and oobeinfo.ini. This pass defines the first boot experience for end users

How are SMI settings changed?

You will only be able to edit settings for the packages that have been added to your image. Note that edit mode is enabled only for a pass that the setting value is applicable to. On the top right corner of the settings pane, first select the pass that you want your setting value to apply to. For example, the setting “EnablePrefetcher” applies to all 7 passes (P1, …., P7). Now select “6 Audit User” from the “Filter view by:” dropdown. This should show you all the settings that apply to the selected pass. Now, click on the value field of “EnablePrefetcher” which provides a text field in which to enter your value.

The screenshot below shows the list of all settings in the foundation core of Windows Embedded Standard 7. Note that since the Filter by (on top right corner) is selected as “All Settings”, the settings displayed in the pane below are not editable. To be able to edit a setting, you will need to select the pass you want the change to apply to.

In this screenshot, the Offline Servicing pass is selected for the setting “EnablePrefetcher”. Now the value of this setting is editable.

I’ve now changed the value of the setting to 1 which will now be applied to the Offline Servicing pass during an unattended install.

Special settings in WES7

Settings whose default values are different from those in Win7

Most of the settings have a default value already provided. For example, setting “FavoritesOnTop” in the Internet Explorer 8 Browser package has a default value of “false”. This means that new favorites are not added to the top of the favorites menu.

The Windows Embedded Standard 7 team identified some settings that needed to have a different default setting that what it is in Win7. For example, in Win7, the aero theme is not enabled by default since the associated service is not started. For certain embedded scenarios, OEMs would like to build an image with Aero theme enabled by default. In order to accomplish this, the theme service needs to be auto-started (apart from adding the necessary packages to the image – Shell Foundation, System Control Panel and Windows Explorer). Thus the setting value for “Start” in Windows Shell package is by default set to 2 (which translates to auto-start).

Settings unique to WES7

Based on feedback that we received from our customers, we realized the need for certain embedded specific settings that are not available in the desktop Windows operating system. Some examples include “PagingFiles” in Windows Embedded Edition package (to enable Page File), “HibernateEnabled” in Power Management package (to enable Hiber File), “EnableLUA” in Windows Embedded Edition package (to enable UAC).

Settings linked by two or more packages in WES7

We also realized that some feature package settings had to be set to a particular value if a certain Embedded Enabling Feature was added to the answer file. Otherwise it would result conflicting behavior. For example, imagine that a user selects a paging file to be generated. The user also adds File Based Write Filter (FBWF) to the image. Now there is a functionality conflict because the first setting forces a page file to be generated. However, the presence of FBWF prevents the writing of any file on the drive. To help remedy this situation, we implemented the concept of linked settings. The idea behind this is that when packages with linked settings are added to the answer file, the user is informed of this and prompted to take an action to sett an appropriate value for the setting in question.

For example: Here I have created an answer file with the Windows Embedded Foundation and the File Based Write Filter packages only. Notice that I have selected to view settings in the Offline Servicing pass. You will see a setting for PagingFiles in the Windows Embedded Edition package.

Now, I change the value of this setting and modify it to be “C:\”. This should allow the system to create a paging file in the C:\ drive of the device.

Once I make the changes, I validate the answer file. An error message is displayed in the Messages pane of ICE. This error message recommends that user change the value of pagingfiles to “” (set it to empty). Once you change this value to the recommended one and validate the answer file again, the error message disappears.

- Hema

[Today’s post is provided by guest blogger, Levi Stevens]

In a default installation of Configuration Manager 2007, you cannot use a query to return devices running Windows Embedded operating systems prior to Windows Embedded Standard 2009. You can, however, extend the hardware inventory in Configuration Manager 2007 to collect further information about the operating product suite which can be used to build queries that return all Windows Embedded computers.

Use the following procedure to extend Configuration Manager 2007 hardware inventory to collect information that can be used in queries to identify all Windows Embedded computers:

1. On the Configuration Manager 2007 site server, edit the file sms_def.mof using Notepad, or another text editor.
2. Locate the class Win32_OperatingSystem.
3. In this class, locate the field OS ProductSuite and change its SMS_Report value from FALSE to TRUE.

You can then use a query such as the following to return all Configuration Manager 2007 clients running a Windows Embedded operating system:

If you want to build queries that identify specific Windows Embedded operating systems, you must extend the Configuration Manager 2007 hardware inventory to add the following classes:

Append the following text to the file CONFIGURATION.MOF on the Configuration Manager 2007 site server:

Append the following text to the file SMS_DEF.MOF on the Configuration Manager 2007 site server:

You can then use a query such as the following to return all Configuration Manager 2007 clients running a specific Windows Embedded operating system:

For more information about extending hardware inventory in Configuration Manager 2007, see How to Extend Hardware Inventory.

-- Levi Stevens

This posting is provided "AS IS" with no warranties and confers no rights.

Crash Dump Configuration

Crash dumps can be configured via the control panel or by editing the relevant registry entries as shown below. Additional details can be found in KB article 307973.

Via Control Panel

Via Registry

Crash dump generation

Crash dumps (the .dmp files) are not created at the time of the crash. Instead, the dump data is written to the page file. Later on the next reboot, this page file is truncated, renamed and moved to its final destination (as configured by the user). By default, the paging file on the boot volume is used. If having a paging file on the boot volume is not feasible, a separate paging file can be dedicated for generating crash dumps, as outlined in the next section.

At the time of the crash, dump data is written directly to the sectors occupied by the page file. This bypasses the file system filters and storage volume filters such as EWF.

At the next reboot, SMSS looks for a valid crash dump header in the page file. Then it checks if the final destination for the dump file is on the same volume. If yes, the paging file is renamed to the appropriate location. If no, it renames the paging file to a temporary file (DumpXXX.tmp). Later WerFault.exe will move this temporary file to its final destination on a different volume. Note that WerFault.exe resides in the “Problem Reports and Solutions” feature package (“FeaturePack” => “Diagnostics” =>“Problem Reports and Solutions”). If this package is not present in the image, the .tmp files will not be renamed to .dmp files, but they will still be valid dump files.

Using dedicated paging files for crash dumps

To configure a custom paging file for use with crash dumps refer to the instructions in KB article 969028. The relevant section is titled “New behavior in Windows Vista and Windows Server 2008”.

After following the instructions in the KB article, verify the new paging file was indeed created. For example, if you specified D:\MyDedicatedDumpFile.sys as your custom paging file, verify this file actually exists on D:

Our testing shows this dedicated paging file will be created only when at least one regular page file has been configured. To work around this you can configure another regular page file of minimum size (16 MB) whose sole purpose is to trigger the creation of the dedicated paging file.

Crash dumps on EWF protected systems

EWF in its current implementation blocks using any protected volume for crash dumps. To generate crash dumps use a dedicated paging file on a unprotected volume.

Recommendation

Use a dedicated paging file as outlined in the section above. This paging file and the final destination for the crash dump should be located on an unprotected volume.

Test this setup by manually initiating a crash. Details can be found in KB article 972110. Relevant section is titled “Generate a manual memory dump using Keyboard”.

Further reading

Windows® Internals: Including Windows Server 2008 and Windows Vista, Fifth Edition – by Mark Russinovich, David A. Solomon and David A. Solomon (Author). Refer to the section on “Crash Dump Generation” in Chapter 14.

- Srikanth

Many of the folks from the team are gearing up to head down to San Jose next week for the Embedded System Conference (April 26-29, 2010).  If you are attending the conference please make sure to stop by one of our sessions or at our booths (#916 & #1432) and say hi – don’t forget to bring your questions about Windows Embedded Standard 7!

Don’t miss the Industry Address that will be given by Kevin Dallas, General Manager for Windows Embedded, on Tuesday, April 27^th at 10:30am.  All attendees will be entered into a drawing for a chance to win a custom home theater media center device based on Windows Embedded Standard 7:

How do you bring to market devices that stand out? What is a compelling user experience? Where is the embedded industry headed? As we move out of the economic reset, taking advantage of the new competitive landscape becomes key to your success. Please join Kevin Dallas, General Manager for Windows Embedded at Microsoft, for the launch of Windows Embedded Standard 7 where he will detail how you can build rich user experiences on Windows 7 based devices. In addition, Mr. Dallas will be demonstrating a number of new and compelling consumer and enterprise devices built on the latest Windows Embedded platforms and outline a refreshed product roadmap designed to provide the latest Microsoft technologies for the embedded market.

In addition to the Industry Address you can also find information about Windows Embedded Standard 7 in the sessions that are a part of the Developing for Windows Embedded track, several Sponsored Sessions, and the Build Your Own Embedded System. For specific session details and links go here.

- Shayna

The launch of the product officially occurred at the Embedded Systems Conference today when our General Manager, Kevin Dallas, announced the product in the conference keynote address. This product demonstrates Microsoft’s further commitment to the embedded business and Windows 7 technologies in specialized consumer and enterprise devices.

If you’ve never installed the Standard 7 product before during the many months it was available as a public download, you may be interested in checking out the Standard 7 FAQ.

Before I head off to uncork the champagne, here’s a video showcasing some close partners and their devices running Windows Embedded Standard 7.

HORM imposes the following restriction on volumes –

• All volumes must be protected by EWF.

          [OR]

• All unprotected volumes must be dismounted before capturing the HORM state.

Note 1: Volumes residing on removable devices are excluded from this restriction.

Note 2: Boot and System volumes should not be dismounted. Hence they must always be protected by EWF when using HORM.

In this article we will describe how HORM can be safely used with unprotected volumes. We shall also describe how these unprotected volumes can be used to store event logs and paging files.

Case 1:

If all volumes are protected by EWF, the steps to use HORM are straightforward –

• Enable hibernation.
  • Powercfg.exe /h ON
• Enable EWF on all volumes.
  • Ewfmgr.exe /all /enable
• Activate HORM.
  • Ewfmgr.exe X: /activatehorm -where X: is any protected volume. Note that HORM is not a per volume feature. It applies to the entire OS.
• Modify the system to reach the desired state.
• Capture the HORM state by hibernating the system once.
  • Shutdown.exe /h
• Resume the machine. Beyond this point , each restart would cause the system to resume from the state captured in previous step.
• To deactivate HORM
  • Ewfmgr.exe X: /deactivatehorm -where X: is any protected volume
• To disable EWF on all volumes.
  • Ewfmgr.exe /all /disable

In RAM REG mode an additional step is required

• Ewfmgr.exe C: /commit -where C: is the volume containing the OS

Case 2:

If you wish to leave one or more volumes unprotected, additional steps are required

• Enable hibernation
  • Powercfg.exe /h ON
• Enable EWF on all protected volumes
  • Ewfmgr.exe /all /enable
• Activate HORM
  • Ewfmgr.exe X: /activatehorm -where X: is any protected volume. Note that HORM is not a per volume feature. It applies to the entire OS.
• Modify the system to reach the desired state
• Deal with unprotected volumes
  • a. Stop applications and / or services that have open handles to the unprotected volumes.
  • b. Dismount unprotected volumes. (Details below)
• Capture the HORM state by hibernating the system
  • Shutdown.exe /h 
• Resume the machine. Beyond this point, each restart would cause the system to resume from the state captured in previous step.
• Deal with unprotected volumes
  • a. Mount unprotected volumes (Details below)
  • b. Start applications and / or services that need these unprotected volumes.
• To deactivate HORM
  • Ewfmgr.exe X: /deactivatehorm -where X: is any protected volume
• To disable EWF
  • Ewfmgr.exe /all /disable

In RAM REG mode an additional step is required

• Ewfmgr.exe C: /commit -where C: is the volume containing the OS

Registering for power transitions

Applications can receive notification when specific power events occur. This is documented in MSDN. Specifically , PBT_APMRESUMESUSPEND indicates the system has resumed from a lower power state. This can be used to automatically trigger the actions needed post resume.

Mounting and dismounting unprotected volumes

• Writing your own code - You can write your own application that makes use of the following FSCTLs to lock / unlock and mount / dismount volumes
• FSCTL_LOCK_VOLUME and FSCTL_UNLOCK_VOLUME
• FSCTL_DISMOUNT_VOLUME and FSCTL_MOUNT_VOLUME

A detailed MSDN article dealing with this topic is available here.

• Using Mountvol.exe – In WES 7, this utility can be found in the “Core File systems” package. It is a simple utility that lets you mount / dismount volumes.

To lock and dismount a volume use the “/P” option. In the above example, we can lock and dismount F: by issuing

Mountvol.exe F: /P

To mount back a volume use the volume GUID identifier listed for each volume. In above example, we re-mount F: by issuing

Mountvol.exe F: \\?\Volume{fe0f21b6-e0c6-11de-be33-001aa0ebe436}\

Dealing with applications that use unprotected volumes

General Guideline: Before dismounting a volume it is necessary to close all applications and/or services that may have open handles to files in this volume. You should start them again after the volume is mounted back.

As an example, we will show how to deal with Windows Event Log service configured to store logs in an unprotected volume.

Windows Event Log Service manages the event logging in Windows. It can be configured to store logs in any desired location by modifying the “Log Path”.

If you have configured Event Logs to be stored in an unprotected volume, it is necessary to stop the Event Log service before dismounting the volume.

Take a look at the properties of Event Log service; it has other services that depend on it. Specifically, the “Task Scheduler” service cannot be stopped by usual means. This prevents the Event Log service from being stopped on the fly.

You will have to turn Task Scheduler service off by editing the registry. The” Task Scheduler” service is named “schedule”. Change the following value

Key: HKLM\System\CurrentControlSet\Services\Schedule

Value: Start Value Type: REG_DWORD

Existing value: 2 (AUTO). Change it to 4 (DISABLED). Restart the system for the change to take effect. Note that if you have applications that rely on task scheduler they will not work until it is re-enabled.

Now you can cleanly turn off the Windows Event Log service. You can turn it back ON post resume after the unprotected volume has been mounted back.

Using Page Files with HORM

When using with EWF, paging Files must reside on unprotected volumes. This will avoid the problem of writes to paging files filling up the overlay. You can modify paging file location and size as shown below.

However, having a paging file on an unprotected volume will not allow the volume to be dismounted. To work around this, enable paging files post resume. This must be done after mounting back the unprotected volumes. Note that on Windows 7, enabling a paging file takes effect immediately; it is not required to restart the system. Paging can also be enabled programmatically using the WMI class Win32_PageFileSetting. See below for a sample VB script that creates and enables a page file of size 2048 MB using this WMI class.

- Srikanth

The April 2010 Security Updates are now available on the ECE site for Windows® Embedded Standard 2009 and/or Microsoft® Windows® XP Embedded with Service Pack 2, Feature Pack 2007, Update Rollup 1.0 and Service Pack 3.

These security updates can be applied to the component database.

The April Security Updates include:

• KB 979306 February 2010 cumulative time zone update for Windows operating systems
• KB 975561 Vulnerability in Windows Movie Maker Could Allow Remote Code Execution
• KB 980182 Cumulative Security Update for Internet Explorer
• KB 981210 Vulnerabilities in Windows Could Allow Remote Code Execution. This KB solution is comprised of the following KB Update packages: 978601 and 979309
• KB 980232 Vulnerabilities in SMB Client Could Allow Remote Code Execution
• KB 979683 Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege
• KB 981169 Vulnerability in VBScript Could Allow Remote Code Execution. This KB solution is comprised of the following KB Update packages: 981332 for Standard 2009, 981349 for XPe UPR1, SP3 and Standard 2009, and 981350 for XPe SP2 and FP2007.
• KB 981832 Vulnerabilities in Microsoft Exchange and Windows SMTP Service Could Allow Denial of Service. This KB solution is comprised of the following KB Update packages: 976323
• KB 977816 Vulnerability in Microsoft MPEG Layer-3 Codecs Could Allow Remote Code Execution
• KB 978338 Vulnerabilities in Windows ISATAP Component Could Allow Spoofing
• KB 979402 Vulnerability in Windows Media Player Could Allow Remote Code Execution

This update also includes a revised release of KB 968816 for MS09-047 (Master KB 973812) to correct an issue with DRM content and missing CAT file.

If you have questions on accessing the ECE, please email MS Mobile & Embedded Communications Feedback & Support, ECE@microsoft.com.

Thanks,

- Lynda

Technorati Tags: XPe,Standard 2009

As mentioned in the blog articles “Image Builder Wizard – Quick and Easy Embedded OS Creation – Part 1” written by Robert and “BitLocker in Windows Embedded Standard 2011” written by Hema – the BitLocker feature requires two partitions. The first partition is a system partition contains the BCD (Boot Configuration Data) store and remains unencrypted. The second partition is the partition that contains Windows, programs, etc and can be encrypted. IBW does a good job in ensuring that the user is required to partition with a separate system partition if the user has added the BitLocker feature. It is able to do that because it has an awareness of whether the feature is added by the user.

What’s the “Gotcha” you may ask? Well, during Mass Deployment scenarios, such as using WDS or IBW to deploy a custom WIM, the disk partitioning dialog has no awareness of whether the BitLocker feature is in the image. That means that it is possible under these circumstances to create a system with the BitLocker feature and only have one partition. This is not a supported setup for BitLocker and the feature will not enable or allow the Windows partition to become encrypted.

So please, if you’re going to be mass-deploying an image with the BitLocker feature, ensure that the Unattend file (or the technician if it’s a manual process) creates a system partition.

- Nick

Multiple calls to ExecNotificationQuery at startup

If the ExecNotificationQuery function is called by more than one thread during OS startup, the svchost.exe process might crash.  For example, call the WMI IWbemServices::ExecNotificationQuery function in 2 threads.

This may be the result of a race condition caused when one thread tries to free the heap while another thread tries to realloc (extend) the heap. This issue is in WMI code inherited from XP Pro SP3.

To avoid this condition, insert a sleep function between the ExecNotificationQuery calls- the crash should not occur if the sleep Tick Count is greater than 2min. You can also call multiple IWbemServices::ExecNotificationQuery functions  in same thread, as that will not result in a race condition.

After installation of MS09-041, KB971657

Stopping wkssvc may cause an AV and svchost to crash on Embedded runtimes built with the MS09-041 security update applied. This can occur both in runtimes with the DQI runtime update installed, or on a runtime built from a component database with the database update containing MS09-041 applied. This issue is inherited from XP Pro.

This crash only occurs during workstation service shutdown. The crash happens toward the end of the service shutting down, and should have no adverse impact. The workstation service can be restarted without error.

To mitigate impact on other services using svchost, isolate the lanmanworkstation service into a separate instance of svchost.exe:

     Sc config lanmanworkstation type=own

Another potential solution is to install the DQI runtime update on Embedded runtimes using the GDR branch rather than the default QFE branch of the update package. For information on how to extract the contents of the update package, in order to install from the GDR branch, see this KB article.

- Gina and Lynda

With all of the excitement around the Windows Embedded Standard 7 launch last week, we didn’t get to post about the launch of the Windows Embedded News Channel (WENC).  This site will be the news hub for all information on the Windows Embedded business, people, products and partners.  Being a part of the corporate Microsoft News Channel will give us exposure to over 2 million people that visit that site every month.

On WENC you will see news articles, video clips, images and social media tools such as Twitter and blog feeds (including a feed from our blog here!) that we hope will keep visitors engaged and coming back for more.  Take a look now to see the story about Standard 7, our demo video and lots of other cool and exciting things.

- Shayna

For the past several months we have received several mass deployment related queries for EWF. Many customers had skipped or were unaware of the Sysprep requirement. To help customers we have compiled a checklist for use during mass deployment of images containing EWF. Hope it helps!

1. Install and fine tune the master image. Disable HORM and EWF. Restart the machine.

2. Sysprep (available in %WINDIR%\System32\Sysprep directory) the image by running <sysprep.exe /generalize /oobe /shutdown>. This will generalize the image and render all system components (including write filters) and settings suitable for mass deployment. Upon completion the machine will be shutdown.

3. Boot the machine into WinPE and use ImageX to capture the image -

a) If C: contains the installed operating system image, run <imagex.exe /capture C: os.wim "C drive">

b) If your active partition (also called BCD partition) is different from OS partition, then you need to capture the active partition as well. This is necessary since the active partition contains the HORM configuration file and the BCD store among other files. Write filters, during installation, update the BCD store with a modified boot status policy. This prevents Windows from incorrectly displaying "Launch Startup Repair" / "Start Windows normally" messages at each reboot when Write Filters are enabled.  If you do not capture and apply the active partition you will see this error message on the target. (PS: Using BCDBOOT.EXE will create a default BCD store which will not contain any customizations from master image. It is NOT an alternative to this step)

c) If D: is your active partition,  <imagex.exe /capture D: active.wim "D drive">

4. Store the wim files at a convenient location such that it is accessible from target machines.

5. On each target machine, create a disk layout identical to the master machine (Ex. number of partitions). If you are using RAM mode, please make sure to leave un-partitioned space necessary to recreate the EWF partition.

a.  Apply the wims to their respective partitions. Mark the appropriate partition as active if necessary.

     <imagex /apply os.wim 1 C:>

     <imagex /apply active.wim 1 D:>

b.  Reboot the target machine. It will go through specialize phase and upon completion all EWF settings from the master image will be available on the target machine.

c. Enable EWF and HORM as applicable to your scenario.

6. If you have followed all the steps above and yet see discrepancies, share all the logs in the following locations with your bug report.

%windir%\Panther\

%windir%\system32\sysprep\Panther\

7. Additional information including overview of mass deployment for write filters is available in a previous blog article.

- Srikanth

Technorati Tags: Embedded Standard

Last week at the Screenmedia Expo Europe 2010 in London, Intel® and Microsoft announced the commercial availability of their joint platform for Digital Signage media players, and the availability of the Digital Signage Evaluation Kit (DSEK-10). The DSEK is a reference platform that is designed to help digital signage developers quickly prototype and develop digital signage solutions. The DSEK is based on an Intel® Core i5-based reference design and Windows Embedded Standard 7 OS.

The device itself is made up of:

• Intel® Core™ i5 Processor (520-M) with Intel® Active Management Technology
• - 3MB Cache, 2.40 GHz
• - 2 processor cores, 4 software threads
• - Integrated Graphics Engine
• - Hardware Accelerated HD Video Decoder
• - Mobile Intel® QM57 Express Chipset
• 2GB SODIMM DDR3 1333MT/s memory x2 (total of 4GB)
• SATA 2.5” Hard Disk
• IEEE802.11a/b/g/n Intel Wireless PCI Express* Half Mini Card (6200)
• Small form factor (185mm x 125mm x 55mm) with an aluminum chassis and an EPIC based mainboard
• Gigabit Ethernet interface (Intel® 82577 Gigabit Ethernet PHY)

As you can see, it’s quite a bit of power tucked into a small form factor device. What this gives you is the power to drive extremely rich user experiences (like this one) while also delivering a small enough size and high reliability to be practical for Digital Signs.

From the Windows Embedded side, the device comes pre-installed with a Standard 7 OS that simply boots up into an application that talks a bit about the DSEK device. We also include an evaluation copy of the Standard 7 OS toolkit so that you can immediately start building your own OS customized for your digital signage applications.

Some features that Standard 7 brings to the table that are especially helpful for digital signage include:

• Microsoft .NET 3.5, Windows Presentation Framework, and Windows Touch support for building rich user interfaces
• Internet Explorer 8 and Windows Media Player 12 (plus MPEG and H.264 codecs) for delivering internet and video content
• Embedded-enabling features such as Dialog Box Filter and Application Locker for ensuring your digital sign only displays the content you want it to display

The DSEK-10 kit is available for order now from Winmate by visiting this address: http://www.winmate.com.tw/DigitalSignage/DSEK-10.htm

Go forth and build your digital signage solutions on this great hardware from Intel® and OS from the Windows Embedded team!

- Robert

Technorati Tags: Embedded Standard

Now that Window Embedded Standard 7 has been shipped, it’s time to start showing off and releasing some of the cool stuff that we have been doing around application templates. We’re providing templates to make development of Standard 7 images quicker and easier. These templates provide the set of dependencies needed for an application to install and run. To learn more about templates, take some time to check out the Compatible Applications website or take a look at this earlier blog article.

New Templates
We’ve recently added 17 new applications & templates to the Compatible Applications website, expanding the scope beyond Microsoft applications to include third-party applications as well as some important anti-virus, security, and thin client applications. Below is the full list of 17 applications for which we recently released templates:

• Adobe Flash 10
• Adobe Reader 9
• CA eTrust Antivirus 7.1
• Citrix Offline App Plugin 6
• Citrix XenApp Plugin for Hosted Apps 11
• Java Runtime Environment 1.5
• Microsoft Hyper-V Drivers
• McAfee VirusScan Enterprise 8.7i
• Microsoft Forefront Endpoint Protection 2010
• Microsoft Security Essentials
• Microsoft Silverlight 4
• Microsoft SQL Express 2008 R2
• Microsoft System Center Configuration Manager 2007
• Microsoft System Center Operations Manager 2007
• Microsoft Visual C++ 2008 Redistributable Package
• Microsoft XNA 3.1
• Symantec Endpoint Protection 11

Package Mapper
On May 7^th, Package Mapper was published on MSDN Code Gallery. Package Mapper is a PowerToy we released publicly because we found it to be quite useful as we created templates. The purpose of Package Mapper is to take a list of Windows binaries (exes, dlls, etc.) and map them to the packages within Standard 7 in which the binaries are contained. The packages are output in the easy-to-use format of an answer file, which can then be fed right into ICE. To learn more about Package Mapper and to begin using it, visit the download page: http://code.msdn.microsoft.com/packagemapper.

Package Mapper’s Interface

On the Horizon
We’re excited about the two recent updates and releases, but the best is yet to come in the world of application templates! In the next few months some major updates and changes will be happening to the website and templates, including:

• A complete re-design of the website to include searching, sorting, and improved usability.
• A documentation & help section that will include whitepapers, blog articles, screencasts, and links to aid in learning and using application templates or doing dependency analysis.
• Several more third-party templates and updates to existing templates.
• Another PowerToy to aid in the comparison of answer files & templates.
• Per-template documentation with information on each application, usage scenarios, and optional dependencies or additional downloads & binaries.

With the work that’s already been done and the introduction of the items mentioned above, application templates will really allow developers to speed up the development process and increase the quality of images when preparing them to work for specific applications.

- JT

Now that Window Embedded Standard 7 has been shipped, it’s time to start showing off and releasing some of the cool stuff that we have been doing around application templates. We’re providing templates to make development of Standard 7 images quicker and easier. These templates provide the set of dependencies needed for an application to install and run. To learn more about templates, take some time to check out the Compatible Applications website or take a look at this earlier blog article.

New Templates
We’ve recently added 17 new applications & templates to the Compatible Applications website, expanding the scope beyond Microsoft applications to include third-party applications as well as some important anti-virus, security, and thin client applications. Below is the full list of 17 applications for which we recently released templates:

• Adobe Flash 10
• Adobe Reader 9
• CA eTrust Antivirus 7.1
• Citrix Offline App Plugin 6
• Citrix XenApp Plugin for Hosted Apps 11
• Java Runtime Environment 1.5
• Microsoft Hyper-V Drivers
• McAfee VirusScan Enterprise 8.7i
• Microsoft Forefront Endpoint Protection 2010
• Microsoft Security Essentials
• Microsoft Silverlight 4
• Microsoft SQL Express 2008 R2
• Microsoft System Center Configuration Manager 2007
• Microsoft System Center Operations Manager 2007
• Microsoft Visual C++ 2008 Redistributable Package
• Microsoft XNA 3.1
• Symantec Endpoint Protection 11

Package Mapper
On May 7^th, Package Mapper was published on MSDN Code Gallery. Package Mapper is a PowerToy we released publicly because we found it to be quite useful as we created templates. The purpose of Package Mapper is to take a list of Windows binaries (exes, dlls, etc.) and map them to the packages within Standard 7 in which the binaries are contained. The packages are output in the easy-to-use format of an answer file, which can then be fed right into ICE. To learn more about Package Mapper and to begin using it, visit the download page: http://code.msdn.microsoft.com/packagemapper.

 
Package Mapper’s Interface

On the Horizon
We’re excited about the two recent updates and releases, but the best is yet to come in the world of application templates! In the next few months some major updates and changes will be happening to the website and templates, including:

• A complete re-design of the website to include searching, sorting, and improved usability.
• A documentation & help section that will include whitepapers, blog articles, screencasts, and links to aid in learning and using application templates or doing dependency analysis.
• Several more third-party templates and updates to existing templates.
• Another PowerToy to aid in the comparison of answer files & templates.
• Per-template documentation with information on each application, usage scenarios, and optional dependencies or additional downloads & binaries.

With the work that’s already been done and the introduction of the items mentioned above, application templates will really allow developers to speed up the development process and increase the quality of images when preparing them to work for specific applications.

- JT

You may have noticed that the blog site has been going through a few changes in the last few days-we have certainly tried out some new and not-so-cool looks since Sunday, mostly because a lot of our data did not get migrated from our old site to the new one! You might also have noticed that we have not posted blog articles for a while.

This is all due to a migration to a new server platform and set of tools that will hopefully make the blogs easier to use, manage, read and provide some cool new features to improve the overall experience. It would appear that all the "teething problems" have now  been addressed and there should be no further drastic changes in the short term. We also aim to get back to "regular programming", namely getting some blogs out there.

Welcome to our new look!

Lynda

Technorati Tags: Embedded Standard

Here’s your chance to check out what our “sister team” has been up to!  The Windows Embedded Compact 7 (next generation of Windows CE) public Community Technology Preview was announced and released at Computex this week.  This version has a lot of new features to help create rich, connected devices and has the next version of Silverlight Embedded development environment for CE.  I won’t spend more time explaining it because other folks have already done a great job:

• Official Press Release
• Windows Embedded Newsroom
• Mike Hall’s blog post
• Windows Embedded site (includes directions on how to sign up for the CTP on Connect)

- Shayna

An engineering guidance whitepaper for Windows 7 may be interesting reading for many of our customers who are creating touch-based devices using Windows Embedded Standard 7. The paper covers topics such as:

• Touch investments in Windows 7, Windows Live, and Internet Explorer 8
• Fundamentals
• Design Principles
• Touch Application Design Recommendations
• Additional Logo Considerations

This is the link where the paper can be downloaded from.

Enjoy!

Lynda

Technorati Tags: Embedded Standard