Windows Embedded Standard (NT4e, XPe and beyond)

Happy Thanksgiving…for those in the USA!

For those customers based in the USA the Embedded team wishes you a Happy Thanksgiving and we hope you have a chance to relax over the weekend.

A note to customers elsewhere - most of the Embedded team will be on vacation from this evening (Pacific Standard Time) until Monday, November 30th and so there may be some delay in our response if you contact us during this time. There are still some hearty souls in the team who may be monitoring newsgroups, forums and mail accounts over these few days.

For those who are not familiar with the history of the Thanksgiving here's the link to an article on Wikipedia.

Enjoy!

- Lynda

November 2009 Runtime Security Updates for XPe and Standard 2009 are Now Available

The November2009 Security Updates  are now available on the ECE 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.

This month’s security updates can be applied directly to runtime images.This download is a cumulative update which incorporates all updates from prior months. Therefore you do not need to download and install previous monthly updates from ECE.

The November Security updates include:

• 969947 Vulnerabilities in Windows Kernel-Mode Drivers Could Allow Remote Code Execution

Additional Details:

In Odd numbered months, the Security Supplement Update CD contains the Security DQI updates for just that current month, and cumulative Component Database updates in the \Windows folder for each supported Embedded version (SP2, Feature Pack 2007 or Update Rollup 1.0) through the previous even numbered month. In Even numbered months, the Security Supplement Update CD contains the Security DQI updates for just that current month, and the cumulative Component Database updates for each supported Embedded version, which are updated to include the previous odd numbered month, and the current even numbered month updates.

If you are servicing your existing development environment:

On the Embedded Security Supplement Update CD in the \Windows folder, there is a Component Database Update available for each supported Embedded product version (SP2, FP2007, UPR1). If you install the Component Database update applicable to the product version you are using, your database will be current with security updates up to and including the most current even month’s security updates.

If you are servicing deployed images:

Assuming you had the cumulative Component Database updates applied to your development environment  on your image creation date, you need only deliver the DQI updates for each month following your release date and have them applied directly to the image ­or you can update your development environment as described above, and deliver a new image for re-deployment. There may be other methods you employ for servicing your images, these are the two most basic approaches you can take with the updates we provide.

If you are a new developer installing XP Embedded for the first time:

Install XP Embedded up to the product version you wish to use (SP2, Feature Pack 2007 or Update Rollup 1.0). Then install the cumulative Database Component updates provided for that version from the latest Security Supplement Update CD to bring your database up to date with all security updates up to the most recent even numbered month.

Miscellaneous Optional updates:

You will also see other updates available on the ECE which are Optional Updates. These may or may not be applicable to your image and you can review the release notes for applicability to determine if you wish to implement them. These may be provided in DQI format, Component Database update format, or both.

Note:

The Security Supplement Updates were called just Supplement Updates through October 2007, when the name changed to Security Supplement Updates.

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

Dialog Box Filter- a New Feature in Windows Embedded Standard 2011

Dialog Box Filter is a new feature in Windows Embedded Standard 2011. Dialog Box Filter can be used to prevent dialogs or windows from appearing on your embedded system. In order to use Dialog Box Filter properly it is important that you understand how it performs this task. This article will explain how Dialog Box Filter works and its limitations, as well as how to troubleshoot issues.

The Dialog Box Filter feature has 4 main components:

1. Dialog Box Service
2. Dialog Box Filter
3. Dialog Filter Editor
4. ConfigurationList.xml

Dialog Box Service

The Dialog Box Service works with the Dialog Box Filter code to capture windows and decide whether they should be filtered. The service is always active and works in the context of the logged on user.

Dialog Box Filter

The filter code is responsible for blocking windows. The filter code can be replaced with a custom filter using an SDK supplied in the Windows Embedded Standard 2011 toolkit. The rest of this section refers to the default filter supplied and supported by Microsoft.

The default filter reads its configuration from the ConfigurationList.XML data file. In order to prevent the windows appearance, windows are relocated to an off screen coordinate before the window is displayed. The filter then waits for the window to be drawn (off screen) and then interrogates the windows information. The information used to identify a window is a combination of:

• The process name
• The window Title
• The window class
• The buttons on the window (names)

Any of the buttons can be used as an action to be taken to dismiss the window. It is the OEM’s responsibility to verify that the action closes the window. If a windows is not closed by the action taken, then the windows will remain off screen and the system’s stability could be compromised.

Dialog Filter Editor

The Dialog Filter Editor is a GUI tool that can be used to configure the default Dialog Box Filter. It can be used on any Windows Embedded Standard 2011 runtime that includes Dialog Box Filter or any Windows 7 machine. The Dialog Filter Editor is installed with the Windows Embedded Standard 2011 tools.

The editor allows you to choose any window currently shown. After adding a new filter you can choose an action from a pull down menu. The file created by the Dialog Filter Editor can be added to a runtime through Image Configuration Editor (ICE) or by placing it in the correct directory on an existing runtime.

ConfigurationList.xml

This is the data file used by the default Dialog Box Filter implementation. The file must reside on the Windows Embedded Standard 2011 runtime in the directory: ProgramData\Microsoft\DialogFilter\. The file should not be edited manually (see troubleshooting issues below for an exception).

Troubleshooting

Below is some important information required to use Dialog Box Filter correctly.

Data from the Dialog Filter Editor and the Dialog Box Filter are not the same:

The Dialog Filter Editor and the Dialog Filter Service may see different data (Process name, Window Title, Class Id, Button names) due to the fact that they interrogate windows at different times in the window life cycle. The Dialog Filter Service interrogates the window immediately after it is drawn whilst the editor interrogates a window long after that stage. This may cause the data from the editor to be incorrect because there are cases where the window changes one or more of the filter criteria (Process name, Window Title, Class Id, Button names) after the window is initially drawn. One such family of windows that has this issue is document applications. These applications use the title bar to show the document currently being operated on. In these applications, the title is updated after the window is initially drawn- therefore the data the Dialog Filter Editor sees (with the document title) will not work with the Dialog Filter Service.

If a configured window is not closed as expected you should use the Dialog Box Filter logging option to verify what the correct xml filter data should be. To do this:

1. Run the event viewer (eventvwr.exe)
2. Go to Applications and Services Log/Microsoft/Windows/Dialog Filter/Operational
3. Enable the log (either in the right window pane or by using the right mouse button on the Operational directory).
4. From this point on the Dialog Filter will log all windows it finds to the operational log. The information for a window will include an XML snippet that can be copied to the configuration file.

The log entries will include the XML snippet that the Dialog Filter Service sees when interrogating a window. The log file XML data should be used to replace the data from the Dialog Filter Editor. This can be done using the Dialog Filter Editor (manually changing entries) or by editing the xml file manually (which is necessary only if the button titles are different). Please use care while editing the xml file and be sure to save the file in a unicode format (This can be done using notepad if you choose the save as option and choose utf-8).

Dialog Filter Service does not log a window that has appeared (and does not block it)

There are certain windows that are not caught by the Dialog Box Filter. These include applications with elevated permissions (UAC) and special applications (such as Magnifier) which do not create a regular window. There are also special button types (e.g. Split Buttons) which are not captured.

Custom Dialog Box filters

The feature includes the ability to create a custom Dialog Box Filter implantation. This can be used to implement a solution not supported by our default implementation (e.g blocking all windows not from a specific process or adding wildcard support). An example implementation is supplied with the feature.

- Adam

Windows Embedded Standard 2011 CTP2 is now available!

Over the last several months, the Windows Embedded team has been hard at work to get this CTP2 release out the door.  A big “Thank You!” to all the customers who have provided feedback on the product.  Since the release of CTP1 we have had fantastic community participation with more than 2700+ downloads, 100+ bugs reported and more than 56 different forum threads asking questions and providing feedback.   Keep them coming!

Please take some time and download the newest CTP2 build and tell us what you think by providing your feedback.  You can register and download from Microsoft Connect: https://connect.microsoft.com/windowsembedded.

The second Standard 2011 Community Technology Preview (CTP2) includes many updates and bug fixes as well as some new features. A few to highlight are:

• Static Dependency Analyzer (SDA)
• New Packages:
  • Anti-malware
  • DVD Maker
  • Parental Control
  • Backup/Restore
  • IMAPI
  • PhotoViewer
  • Fax and Scan
• Updated and more detailed product documentation

Additionally, CTP2 includes new templates that make it easy to ensure that all of your favorite and most important applications will run on Windows Embedded Standard 2011. Preview the first templates available at CTP2 launch!

We look forward to your on-going participation and feedback as we continue to the final release of Windows Embedded Standard 2011.

- Lesley

Customizing Windows Embedded Standard 2011

Introduction

During the planning phases of Windows Embedded Standard 2011, we invested considerable effort to make Windows Embedded Standard 2011 customizable to the point where our customers will be able to create a custom experience – from the moment the machine boots up until it shuts down. To reach this goal we introduced several new packages and features.

• Unbranded Startup Screens
• Custom Logon Desktop Background Images
• Message Box Auto Reply (also in Windows Embedded Standard 2009)
• Dialog Filter
• Shell Launcher
• Credential provider samples that show how to customize the logon experience
• Hide Boot Screens package
• Dialog Filter configuration utility – A friendly GUI tool to configure dialog filter

Unbranded Startup Screens

When this package is added to a runtime, Windows will no longer show the Windows logo on any of the startup screens. This feature is non-functional when using an evaluation runtime.

Custom Logon Desktop Background Images

This package allows you to replace the logon desktop background images. Using this package with the Unbranded Startup Screens package allows the full customization of the normal boot process.

Figure 1- Windows 7 Branding

Figure 2- Windows Embedded Standard 2011 Branding

Message Box Auto Reply

This package is identical to the Windows Embedded Standard 2009 version. Once activated it will block all dialogs created with the messagebox APIs from appearing and automatically implement their default action. Please note this does not work for 64 bit implementations.

Dialog Box Filter

Dialog Box Filter is a new package that allows you to filter any dialog that you predefine in a configuration file. Any button can be chosen for an action as long as it is guaranteed to close the dialog. If an action fails to close the dialog, the window will remain off screen and system stability may be affected. Dialog Box Filter can be configured using the Dialog Filter Editor, which is installed on the machine that the Windows Embedded Standard 2011 tools are installed on. The editor allows you to choose any displayed window and gives you a choice of actions that can be configured for the window. A separate blog article will follow explaining in greater detail how Dialog Box Filter can be configured and used.

Dialog Box Filter has an advanced feature that allows you to create a custom filter to supply specific functionality not supported by our default implementation.

Figure 3- Dialog Filter Editor main menu

Figure 4- Dialog Filter Editor filter option menu

Shell Launcher

Shell Launcher allows you to seamlessly replace the Windows shell with your own custom shell. It does this while keeping the expected behavior of Windows vis-à-vis the run and runonce registry key processing.

Hide Boot Screens

When added, this package will eliminate the kernel screens shown when booting up and resuming from hibernation.

Credential Provider Samples

Windows 7 no longer supports custom GINAs (Graphical Identification and Authentication). To help our customers we have created several sample credential providers that are installed on the machine as the Windows Embedded Standard 2011 tools. These samples can be used to create a custom logon experience. A detailed whitepaper is included explaining how this can be done and what you have to consider when planning a credential provider.

- Adam

EWF Overlay Limits on Windows Embedded Standard 2009 and 2011

Introduction

When using Enhanced Write Filter (EWF) in RAM or RAMREG mode several customers might assume the EWF overlay is limited solely by the availability of physical memory. Consequently, many assume they will be able to achieve an overlay twice as big on a system with 2 GB RAM than on a system with 1 GB RAM. This is not true by any means. This article explains the factors that limit the overlay size and the significant improvements seen on Windows Embedded Standard 2011.

If you are interested more in the conclusion than the internals, skip the following sections and jump directly to the “Results and Conclusion” section.

EWF memory allocation internals

EWF maintains a list of memory descriptor lists (MDLs) that describe the entire overlay. Using MDLs is the preferred memory allocation technique for kernel mode drivers that have huge memory needs that exceed the Paged Pool or Non Paged Pool limits. The overlay size is increased on a "need to" basis and not pre-allocated in DriverEntry. Whenever a new write arrives and it cannot be accommodated in the overlay, we allocate a new MDL that describes 64 KB, increasing the overlay size by 64 KB. No more allocations are needed until we run out of this 64 KB chunk. This continues until the system cannot allocate any more MDLs. Next, I will explain why this happens much before we actually run out of physical memory on the system.

Each MDL describes a set of pages – in the case of EWF, we use MDLs that describe 16 physical pages (64 KB per MDL / 4 KB per page = 16 pages per MDL). To map these 16 noncontiguous physical pages into 16 contiguous virtual pages, the operating system needs 16 Page Table Entries (PTEs). Specifically, it needs 16 system PTEs because MDLs don't use regular PTEs. So each time the overlay grows by 64 KB we have 16 fewer system PTEs.

System PTEs are not an unlimited resource and their total number does NOT increase linearly with physical memory. So the EWF overlay size will be limited by the availability of system PTEs and NOT by the availability of physical memory. Also, note that system PTEs are also used by the operating system and other kernel mode drivers (a big chunk by the video drivers)

The next question is – How many system PTEs does Windows provide? It varies and the primary factors are the version of Windows (Windows XP vs. Windows 7) and the processor architecture (x86 vs. x64). The exact numbers are not documented on MSDN, but you can easily find out for yourself using Windbg.

Using Windbg to determine the system PTE information

1. Enable kernel debugging on the target system and restart the machine. You can either debug remotely using a serial / 1394 cable OR use local kernel debugging.
2. Launch Windbg and set the symbol path to the Microsoft public symbols server
• “.sympath SRV*C:\PublicSymbols*http://msdl.microsoft.com/download/symbols”
3. Use the Windbg command “!sysptes” to get the information on system PTEs. You can use debugger help (.hh !sysptes) for details about this command.

Results and Conclusion

Windows Embedded Standard 2009 (32 bit edition) vs. Windows Embedded Standard 2011 (32 bit edition)

Note: On Windows XP, there is a memory management setting that can help increase the system PTEs (compared to default behavior on Windows XP). To use this, set the following REG_DWORD to 0xffffffff. “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management! SystemPages”. This setting is not used by the Memory Manager in Windows 7.

Here’s how you should interpret the results - On Windows Embedded Standard 2009 with 2GB of RAM, system PTEs can only describe up to 1007484 KB (~ 984MB). The EWF overlay limit will be lesser than this owing to system PTE usage by other drivers and the operating system. In my experiments, I observed this usage to be around 300MB, thus limiting the EWF overlay to about 684 MB. The improvement in Windows Embedded Standard 2011 is impressive and hard to miss. On Windows Embedded Standard 2011 with the same configuration, system PTEs can describe up to 1709952 KB (1670 MB). Assuming similar system PTE usage by other components, EWF overlay can be as large as 1370 MB. The overlay limit has roughly doubled from Windows Embedded Standard 2009 to Windows Embedded Standard 2011.

You will also notice that limits on 2GB system are smaller than that on a 1GB system. To reiterate my earlier point, system PTEs don’t increase linearly with RAM. With more physical memory, the kernel needs to maintain larger book keeping structures (such as the PFN database), hence the increasing physical memory from 1 GB to 2 GB is not beneficial if you are looking to improve overlay limit. It is however beneficial for RAM hungry user mode processes.

Windows Embedded Standard 2011 (64 bit edition)

On 64 bit edition of Windows, the kernel address space is much larger (both theoretical and supported) and system PTEs can describe up to 128 GB of RAM. However, EWF on Windows Embedded Standard 2011 has only been tested on systems up to 4 GB of RAM. If you have embedded scenarios that use more RAM, please provide feedback either on the forums or the connect website. Refer to the product documentation that will accompany Windows Embedded Standard 2011 RTM for the final word on this.

Conclusions and call for action

1. Estimate the overlay needs for your embedded scenario, compare it with the chart above and decide the correct platform (Windows Embedded Standard 2009 or Windows Embedded Standard 2011).
2. Consider using 64 bit edition of Windows Embedded Standard 2011 if you need more overlay space than what is offered by the 32 bit edition.
3. As always, provide feedback!

Further Reading

1. Mark Russinovich’s blog article - “Pushing the Limits of Windows – Virtual Memory”.
2. Memory Management advances in Windows Vista and Windows Server 2008.
3. For general reading on OS Internals - Windows® Internals: Including Windows Server 2008 and Windows Vista, Fifth Edition.

- Srikanth

Windows Embedded Standard 2011 Interview on Channel 9

Charles Torre, from Microsoft Channel9, interviewed the Development Manager Oren Winter and his leads on Windows Embedded Standard 2011 that the team has been busy working on for the past couple of years. You will hear insights from those who are really hands-on the code: the developers :) !

    Windows Embedded: Past, Present and Future

Weijuan

Reminder: Webinar on Windows Embedded Standard 2011 is on Monday

This is a reminder that on Monday, Nov 16 the next in our technical webinar series on Windows Embedded Standard 2011 will be held. The details are:

Date: November 16, 2009
Event Start Time: 11:00 AM Pacific Daylight Time (UTC - 7 hours)
Duration: 1 hour

A Windows Embedded Standard 2011 image is built from a number of packages. In this session you'll learn about what constitutes a package and how multiple packages depend on each other to build a functional image. We'll look at some key functional areas such as shell and .NET so that you'll know what might be needed in your image.

You can register for this webinar here. To get a head start download the Community Technical Preview build from here.

If you cannot watch the webinar live then still register as the session will be recorded and will be available to registered attendees a few hours after the webinar ends.

Enjoy!

- Lynda

Technorati Tags: XPe,Embedded,Standard 2009,Standard 2011,CTP

Performance Monitor Console Always Prompting You to Save Changes?

Here is a quick tip for those that want to stop getting prompted to save changes to the Performance monitor console (especially when you have not made any changes). Just change the properties of the perfmon.msc file under \Windows\System32 to “Read-Only”. That way you can open the console from Run>perfmon.msc, view the details in the console and close it again with no prompt.

If you do make changes to the console settings then these changes will automatically be saved when you close the Performance console, and you will not be prompted for a choice to save or not.

- Lynda

Technorati Tags: XPe,Standard 2009

Launch command-line utility from DUA without showing a CMD.EXE window

A poster on the Windows Embedded Standard 2009 forum has a great tip for users of DUA. He gives details of how to write a DUA script that can launch a script, executable or other command line utility using the DUA EXECUTEPROCESS command, but without having to first launch a command prompt window.

His basic conclusion is to add the following parameter to the DUA script that is using the EXECUTPROCESS command:

StartupInfo=1

His testing was done on a Minlogon image which always runs in the context of Local System, rather than in a user context. He surmises that there is also some connection to the value specified in the Desktop_Name parameter that he uses in his example.

See the full post here.

- Lynda

Technorati Tags: XPe,Standard 2009

New Out-of-Band Features Available for Windows Embedded Standard 2009!

A number of new features are now available for installing on a Windows Embedded Standard 2009 database. These features are:

• .NET Framework 3.5 SP1 and .NET Framework 3.5 Client Profile for Windows Embedded Standard 2009

• System Center Operations Manager 2007 R2 Agent Prerequisites for Windows Embedded Standard 2009

  • This macro component contains the prerequisite component dependencies for installing the System Center Operations 2007 R2 Client

• Silverlight 2.0 for Windows Embedded Standard 2009

• On-Screen Logon Keyboard for Windows Embedded Standard 2009

  • The On-screen Logon Keyboard component provides a soft keyboard presented to the user of an embedded device during the logon process. The On-screen Logon Keyboard enables touch interface scenarios and removes dependence on a physical keyboard for Windows logon events.

For more information on these features you can watch these two video presentations:

• Demo of Silverlight 2.0 on Standard 2009, available with MSDE
• Demo of new MSDN Embedded Subscription and out-of-band

The ISO containing these features can be downloaded from the ECE site here.

If you want early access to more out-of-band features as they become available then sign up for an MSDN Embedded subscription, where you can test out new features for Windows Embedded Standard 2009.

Enjoy!

Lynda

October 2009 Security Database Updates are Available

The October 2009 Security Updates  are now available on the ECE 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.

The security updates can be applied to the component database.This download is a cumulative update which incorporates all updates from prior months. Therefore you do not need to download and install previous monthly updates from ECE.

The October Security updates include:

• 970653 August 2009 cumulative time zone update for Microsoft Windows operating systems
• 971961 Vulnerability in JScript Scripting Engine Could Allow Remote Code Execution
• 958869 Vulnerabilities in GDI+ Could Allow Remote Code Execution.
• 969059 Vulnerability in Indexing Service Could Allow Remote Code Execution
• 971486 Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege
• 973525 Cumulative Security Update of ActiveX Kill Bits
• 974112 Vulnerability in Windows Media Player Could Allow Remote Code Execution
• 974455 Cumulative Security Update for Internet Explorer
• 974571 Vulnerabilities in Windows CryptoAPI Could Allow Spoofing
• 975254 Vulnerabilities in FTP Service for Internet Information Services Could Allow Remote Code Execution
• 975467 Vulnerability in Local Security Authority Subsystem Service Could Allow Denial of Service
• 956844 Vulnerability in DHTML Editing Component ActiveX Control Could Allow Remote Code Execution
• 973812 Vulnerabilities in Windows Media Format Could Allow Remote Code Execution.
• 975682 Vulnerabilities in Windows Media Runtime Could Allow Remote Code Execution.
• 896358 A vulnerability in HTML Help could allow remote code execution

Additional Details:

In Odd numbered months, the Security Supplement Update CD contains the Security DQI updates for just that current month, and cumulative Component Database updates in the \Windows folder for each supported Embedded version (SP2, Feature Pack 2007 or Update Rollup 1.0) through the previous even numbered month. In Even numbered months, the Security Supplement Update CD contains the Security DQI updates for just that current month, and the cumulative Component Database updates for each supported Embedded version, which are updated to include the previous odd numbered month, and the current even numbered month updates.

If you are servicing your existing development environment:

On the Embedded Security Supplement Update CD in the \Windows folder, there is a Component Database Update available for each supported Embedded product version (SP2, FP2007, UPR1). If you install the Component Database update applicable to the product version you are using, your database will be current with security updates up to and including the most current even month’s security updates.

If you are servicing deployed images:

Assuming you had the cumulative Component Database updates applied to your development environment  on your image creation date, you need only deliver the DQI updates for each month following your release date and have them applied directly to the image ­or you can update your development environment as described above, and deliver a new image for re-deployment. There may be other methods you employ for servicing your images, these are the two most basic approaches you can take with the updates we provide.

If you are a new developer installing XP Embedded for the first time:

Install XP Embedded up to the product version you wish to use (SP2, Feature Pack 2007 or Update Rollup 1.0). Then install the cumulative Database Component updates provided for that version from the latest Security Supplement Update CD to bring your database up to date with all security updates up to the most recent even numbered month.

Miscellaneous Optional updates:

You will also see other updates available on the ECE which are Optional Updates. These may or may not be applicable to your image and you can review the release notes for applicability to determine if you wish to implement them. These may be provided in DQI format, Component Database update format, or both.

Note:

The Security Supplement Updates were called just Supplement Updates through October 2007, when the name changed to Security Supplement Updates.

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

Developing high quality test cases

I think it may surprise a lot of people in the industry that Microsoft (and most high visibility software vendors) invests a lot of time and effort into their testing. Quality assurance is so key to the success of our products that every team in the company has personnel whose lives are dedicated to just insuring that quality is in the product. We can debate the success or failure of this effort, from my perspective, even though we find bugs after the fact, and people have issues with our products, with tens of billions of lines of code and trillions of permutations of interoperability’s, that effort has largely been successful.

If you are focusing on testing your product, then you have to do some basics before you can even begin test. The first is having a test plan, followed by a schedule which includes testing, then some automation and unit tests. Each of these are so well known and talked about that entire books, specifications, standards, best practices, etc… have been devoted to them. In fact, so much that I usually go into skim mode when I just run through the list. It’s just too long and it’s hard sometimes to understand the titles or relevance. That should be an indicator of how much software has both evolved and diverged over the past 50 years. I’m pretty sure I can list 20 sub specialties within software development that can be given unique attention without much effort.

So to the topic of developing high quality test cases, where do you begin? You cannot develop test cases without a feature specification, and in fact, I claim if you are testing without a specification, your testing is largely unsuccessful. However, thinking about test cases will tell you more about your tools and automated needs than anything else. Assuming solid unit tests are implemented where do you go?

Here are some questions to ask (it is clearly not an exhaustive list, but should give you ideas):

- Am I testing a kernel mode device driver? If so, do I have specific test cases setup so that Driver Verifier is turned on? Do I define the expected results (almost invariably, bug check, but think about others)? Do I have IOCTLs that are exposed to the application layer and do I test those? Does my driver control hardware, filter, or something else? Network?

- If you are shipping hardware, are you doing internal testing of interfaces via simulation? Are you developing tests to simulate corner case environments, what are the extremes?

- Do I understand and more importantly have the hardware that we are targeting? Platform such as x86 or IA64? Do we have architectural boundaries? Do I know the memory or CPU boundaries? How does it work with other devices, is PnP involved (it probably is)

- Am I user mode testing? Do I use Application Verifier in testing? (If not, I would add test cases for Application verifier).

- Does my feature have any exposed entry points? Do I use fuzz-ing? Are my entry points public or private? LDAP? RPC? DCOM? Win32? COM? Etc…

- If it is a windows application, do I test in safe mode, is safe mode defined, is it relevant? It may be if you need UI in safe mode.

- Do I have UI and do I need to validate all of the controls? Can multiple users select UI in my feature? Do they need to be exclusive? What kind of languages or locales do I support? What globalization issues are my tests going to cover?

- Do I test for accessibility? Are there any accessibility issues with my product? Have I thought about all the dimensions of accessibility?

- Am I testing web pages? Web interfaces? Advanced HTML, Scripts? Java classes? ASP pages?

- Do I validate data? Database tables? Remove Data? How is it accessed? Is it raw, can it be accessed outside my application? Is it formatted, is there a specification for the format?

- What is my security plan? Do I have a threat model and do I validate the known potential boundaries? Am I a secure oriented tester? Have I evaluated the cost of having to release a security update? Am I testing least privileges?

- What are the specific functional items from the specification that I need to validate? Do I have to cover any government standards (an area Microsoft has historically been silent on)? Do I have to meet any other well defined standards as well? This is where your organization must make the hard decisions.

- What types of input do I need to test? Hardware, software, text, keyboard, sound, physical elements? Can I enumerate them all? Can I cover most with a few generic items? That last one is a key to minimizing your test hit.

- What environments will I operate in; do I have clear specifications for these environments? Are there customer requirements to validate?

- Do you know what the product life cycle is and do you have a plan to test updating for bug fixes? Do you test installing new updates? This area is largely untested in virtually every environment I have been exposed to outside of Microsoft. Is there a plan for servicing your feature?

- Do you know how to test versioning, private, public fixes? Have you evaluated how it can go wrong in the cases? Do you have a plan for those scenarios?

- Do you have an uninstall option after install? Do you validate that uninstall works correctly, can you reinstall? Does it work then?

I could write a book on just these questions while adding more, and indeed, there are books that ask and in a general way answer these questions. Evaluating all of these will help you define quality test cases. For each of the above areas, you have some more criteria you need to define, some tests that measure the results, and then some action to make sure that during development and even after you ship, you have clearly built test cases that will bring quality to your feature.

You can “test” your test case by answering these questions:

Do I define the results of the test?

Does the test clearly define what it is testing?

Can the test be modified to produce variations?

Can the test validate both positive and negative inputs?

Will the test always be viable?

Does the test validate the functional specification?

Will the test always report success and/or failure clearly where there is no ambiguity?

In other words, a quality test case has the following properties:

- It is well defined and has unique relevance to your feature

- Is built upon either existing proven tests or itself, will lay the foundation for other tests

- Is based on clearly defined features, functions, or requirements

- Has some property that will clearly demark it from other tests, it is mutually exclusive

- Can be understood both by the engineer and is relevant to his domain knowledge and can be executed by the simplest personnel with full confidence in understanding the results

- Can be run under all predefined architectural boundaries as well as hardware boundaries

- Clearly measures as well as reports a result. There is no ambiguity about the results or the measure.

- Most importantly, on failure, it will generate an actionable result which insures that its failure is addressed – bug, design change, schedule modification, etc...

So, building test cases really comes down to the simplest of concepts. Understanding your feature well enough and with enough detail such that when you look over your test cases, you have a high degree of confidence that you mitigated customer risk and provided your staff with a well defined set of criteria by which they can assume they have done their job. Good engineering is a team effort, the role of you or the person developing test cases is engagement and building confidence in how you test. This will go far in helping bring a high quality product to market.

Test case development by far is non-trivial, requires special knowledge about software, and also about software environments. These can range from hardware to operating system, and are not unique to Windows. It is essential that test personnel be experts in both disciplines in order to be successful. You cannot hope to succeed in testing software without strong knowledge in both software development as well as the execution environment. There are ample well documented examples whereby this was not adhered to and disastrous results ensued.

Here are some books I have read on the subject, of course, each are examples and not my final word on the subject. Also, I am not paid to advertize these and I’m sure that you can find more relevant documentation that will help you if you are struggling with test case development. Note, I mix and match between MS Press and others, so as not to appear biased, however, “How We Test Software at Microsoft” if anything, should open your eyes to the systematic and sometimes frustrating process we go through bringing quality to our products.

Essential Software Testing: A Use-Case Approach by Mike Fornier

How We Test Software at Microsoft by Alan Page, Ken Johnston

Software Test Automation: Effective Use of Test Execution Tools by Mark Fewster

Testing Computer Software by Cem Kaner Jack Falk Hung Q. Nguyen

Testing Object-Oriented Systems: Models, Patterns, and Tools by Robert V Binder

-Hazel

Technorati Tags: XPe,Standard 2009

WMI Command-line Tool is not Completely Localized in Std 2009

The Windows Management Instrumentation Command-line tool is not completely localized because the file CLIEGALI.MFL for the appropriate MUI language is not brought into the runtime when it is built in Target Designer. This is the file that defines the localized WMI namespace root\cli\MS_xxx, where xxx is the LCID for a language (e.g. 411 for Japanese). This file, for every language, does exist in the repositories but is not owned by any component.

To solve this problem copy the file (for the specific language you need) from the embedded repositories to the runtime, and place it under %Windows%\MUI\Fallback\<LCID>.

If wmic.exe has been run at least once it gets a little more complicated. When you run wmic for the first time, it compiles its MOF and MFL files (Cli.mof, Cliegaliases.mof, and Clialiases.mfl, etc), which get written into the WBEM repository (%WINDOWS%\system32\wbem\Repository) along with MOF/MFL files from other WMI providers.  To resolve the problem in this case:

1. Copy the file over to the XPe device and then

2. Compile CLIEGALI.MFL after copying it to the runtime as follows: 

Open a command window and run the following command:

mofcomp %Windows%\MUI\Fallback\<LCID>\CLIEGALI.MFL

- Lynda

Technorati Tags: XPe

Adding Custom Files And Creating an IBW Disk in Windows Embedded Standard 2011

Note: The content in this blog is for users who are familiar with using Image Configuration Editor (ICE) to create a fully resolved answer file. If you would like to learn how to create a fully resolved answer file, please refer to this blog article.

ICE provides easy ways to add custom files to your Windows Embedded Standard 2011 image and generate a bootable IBW Disk. This blog article explains how these are done in ICE.

If you’ve chosen to install the Windows Embedded Standard toolkit with Typical option, you should find the DS in <Root Drive>\Program Files\Windows Embedded Standard Windows Embedded Standard 2011\DS. In the DS, there is a folder called “$OEM$ FOLDERS”. From Windows explorer, create a folder structure MyApps\$OEM$\$1\App1 as shown below.

In the App1 folder, add the files you’d like to be in the final image.

In ICE, you will be able to see the “MyApps” folder that you’ve added in the DS pane. Right click on it and select “Insert Oem Folders Path”

The focus should jump to the Settings pane. You will see that the OEM folder has been added to the answer file as a setting, as shown below. Validate and save the answer file.

Now that you have generated an answer file that contains your OEM folder information, it’s time to create a Windows Embedded Standard 2011 image with your files in it.

One convenient feature in ICE is the ability to create a bootable installation disk that contains all of the packages and files added to the answer file. You can use this bootable disk to boot from your target device, go through a few prompts and have your Windows Embedded Standard 2011 image installed on your device!

Let’s create the IBW Disk now. From the Tools menu, select Media Creation | Create IBW Disk From Answerfile as shown.

The IBW Disk dialog box is displayed.

Select the answer file you saved and specify a folder location for the IBW Disk content to be created. When it’s finished, you will see the bootable disk content created in the folder you specified. This folder contains the custom files that were added to the answer file. Copy all of the content inside this folder to a bootable USB drive and you’re ready to begin installing the image to a target device!

- Ivan