Multilingual User Interface Pack - Microsoft Windows Embedded Standard 2009 Developer Resource Kit Componentizing...

This section provides troubleshooting tips for Multilingual User Interface Packs (MUI).
You get an error when you import a MUI SLD and you cannot import it
These MUI .sld files contain a common repository object called Console Repository. If this object had already been imported, the import may not work because you do not have permission to perform actions such as deleting or re-importing with this repository object in the repository share. Be sure that your account has full control access (including delete permission) to the repository root to which you are copying repository files.
Some Start menu items will always appear in English in the runtime.
You cannot switch between MUI and English in the runtime
If you add multiple language support components that have corresponding MUI resources imported into the database, you can use Regional and Language Options in Control Panel at run time to switch the users default UI language.
However, you must add the following registry key before you can switch to the English language:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Nls\MUILanguages
Name: 0409
Type: (REG_SZ) 1
All user accounts have the same icon on the Friendly Logon UI in your Multilingual User Interface Pack runtimes
Not all Multilingual User Interface Packs (MUIs) exhibit this behavior, but if this behavior occurs in your runtime, use the following workaround:
Add the Images and Media component.
In Target Designer, add the English Language Support component and the International Control Panel component to your configuration.
Using the Extra Registry Data node in Target Designer, add the following registry resource to your configuration:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Nls\MUILanguages
Name: 0409
Type: REG_SZ
Data: 1
Use the Settings node in the Regional and Language Options component in Target Designer to set default UI language to English.
Run a dependency check, and then build your runtime.
Reboot your runtime, and then perform First Boot Agent (FBA) in English.
At run time, use the International Control Panel to switch to the original UI language of your choice.
Japanese font in command window is too small or appears corrupted
If the command window is reduced in size, the Japanese font may be shrunken to the point where the Kanji characters appear corrupted.
To resolve this problem:
Add the "Full screen video driver for console" component.
On the runtime, use the "Add/Remove hardware" wizard manually to add "Full screen video driver for console" as a system device in order to enable the full screen command console to work correctly with codepage 932.
Maximize the window (Alt+Enter), or manually increase the size of the window.
This behavior is not a problem on systems that use the command prompt (Cmd.exe) as the shell because by default the command prompt window is in full screen mode.
Enabling high contrast
In non-English languages, if you use the Accessibility item in Control Panel to enable high contrast, it does not work. Use the Accessibility Wizard to enable high contrast instead.
Miscellaneous
Inbound network connections limit
Since Standard 2009 is a derivative of XP Professional, Standard 2009 inherits the 10 incoming connections limit as in XP Pro.
Inbound connections limit in Windows XP
If working with HTTP connections, a workaround is to develop your own HTTP server.
HTTP Server Sample Application
Using Cygwin hosted service
If using the Cygwin hosted service, include the Null Device Driver component, as it is required by cygwin1.dll, for services to start.
Cygwin is used by OpenSSH and Postgresql. If using OpenSSH, also include the following component:
Primitive: Cacls.exe
Boot time performance
The purpose of this article is to describe the general boot process of Standard 2009, and describe boot time features as well as troubleshooting tips, techniques and tools.
Tips for optimizing boot performance
1. Leave the Prefetching feature enabled, which is the default. Prefetching is an XP feature that pre-loads commonly used modules into RAM when the system starts which should speed up boot. The Prefetching feature has dramatic effect on reducing the boot time.
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters
Name: EnablePrefetcher
Type: REG_DWORD
Value: 3
0 = Disabled
1 = Application launch prefetching enabled
2 = Boot prefetching enabled
3 = Applaunch & Boot enabled
In order to have prefetching work in XP embedded, need to have the ‘Task Scheduler’ component in the build. This might increase the image footprint but it'll likely reduce the boot time.
For more information, search for EnableAutoLayout in Chapter 4. Embedded Enabling Features.
After booting the same image several times, future boots and application loading will occur much faster.
2. Leave both disk defragmentation and auto-layout features enabled. Both features reduce the boot time. They're enabled by default unless you include the "Background Disk Defragmentation Disable" component or modify the corresponding registry entries to disable them. See Disabling Disk Defragmentation for more info.
3. Check this white paper: Fast System Startup for PCs Running Windows XP
4. Check this white paper: Windows XP Performance
5. Disable all startup items and third party services. You can use msconfig.exe for this purpose. Also disable 3rd party drivers. A misbehaving service or driver can dramatically increase the boot time.
6. You could use the Hibernate-once-resume-many (HORM) to enable the system to always resume from hibernation after a shutdown instead of going through full normal boot. Hibernation and EWF
7. Look at this following section of the XPe SP2 doc on improving the boot performance:
How to Improve the Boot Performance of a Run-Time Image
This link includes tips and tricks such as removing unnecessary hardware components, optimizing the BIOS for faster boot, footprint minimization, etc.
A walk-through of the windows boot process
The following is an outline of the Windows XP boot process which Standard 2009 inherits.
BIOS performs its Power On Self Test (POST).
BIOS loads the Master Boot Record (MBR) into memory, and launches the code contained within (in real mode)
The MBR boot code effectively results in the loading and launching of NTDETECT.COM and NTLDR. NTLDR loads and executes all of the critical boot devices. During this time the screen is blank.
During the boot, Windows mounts and assigns drive letters according to following order:
First it uses letters for volumes that have reserved positions saved within entries in HKLM\System\MountedDevices\\DosDevices
Then it tries to find new volumes that don't have matching ID in both Volume, and DosDevice key groups. If the volume that matches this criteria is found, Standard 2009 assigns the first available letter and creates both Volume and DosDevice keys for it.
Next, Windows XP loads the rest of the operating system while the progress bar appears. Note that if you add the /NOGUIBOOT option to the boot.ini file, you will get a black screen instead of the Windows Embedded GUI with progress bar, until the shell loads, or until the user logon prompt appears.
Example: In your boot.ini your ARC path would look something like this-
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="Windows XP Embedded" /fastdetect /noguiboot
See also the /bootlogo option discussed here:
How to replace the boot screen with one of your own
The order of deployment of kernel mode and user mode objects frequently depends on the Plug and Play boot order and hence the exact load order varies.
You can inspect the setupapi.log found in the windows folder, for more information about Plug & Play activity.
During this window of time, the Windows XP Prefetcher can improve the overall boot time loading.
The prefetcher uses adaptive algorithms which progressively improve boot time performance. For a Standard 2009 runtime, it is recommended that you boot the runtime, run the applications associated with the runtime, and then shutdown the system. Repeat this several times, until the boot time has stabilized to a minimum. Then mass deploy the runtime.
The Windows XP prefetcher self optimizes based on idle time delays and other events such as:
has an optimization ever happened,
is there anything to do,
has it been done in the past 3 days.
If you clean install a machine, never let it idle and time the first or second boot, it will seem slow. However, if you take that same machine and let it sit idle after a couple boots, it will self optimize based on idle time timeouts. The optimize feature in bootvis simply triggers the same idle time events to happen without waiting for the timeout so that in a lab environment a solid repro can be built of a fully optimized system. There is nothing special about the optimization triggered by bootvis vs. what happens based on idle time. Further it is important to note that Windows XP is always self optimizing, it is not a onetime event to do based on a utility.
If you are using the Enhanced Write Filter (EWF) RAM-based overlay to protect your system volume, be sure EWF is disabled throughout this procedure, otherwise your reboots will have no effect on the prefetcher’s progressive performance because all information is lost each time the system is shut down.
Once all of the above has completed, the shell is launched.
Minlogon: a minimum command shell is launched, along with LSASS and the Service Control Manager (SCM).
Windows Logon: the Windows shell is launched which is a superset of Minlogon.
Custom: a developer-specified customer shell is launched.
EWF and boot optimization
If you are protecting your system drive with EWF, do not immediately enable EWF. Boot the system a number of times, until the boot time becomes optimally reduced by the Prefetch feature of Windows XP. Then enable EWF.
Debugging Your application or driver does not work in Standard 2009 but works in XP Professional
Make sure you are testing in the same identical hardware to rule out hardware malfunction.
Make sure your design is of the same service pack level (e.g. SP2 or later).
Compare updates and hotfixes installed.
The design is missing files or registry entries that are needed for your application to run. See the Filemon and Regmon information elsewhere in this document, to discover what is missing in the design.
Since the design is a lighter footprint, it could be exposing timing issues that were not visible with the full version of XP Pro.
If necessary, hook up the kernel mode debugger, especially if it is a driver issue.
To have a memory dump file saved when the system crashes, you need to have a paging file on the boot volume. Without a paging file on the boot volume, the system cannot save a dump file. Because EWF is protecting the boot volume from writes, the dump file feature will not work properly. A work around is to disable EWF, reboot, and then configure a page file. For general information about paging files, see the following article in the Microsoft Knowledge Base:
How to configure paging files for optimization and recovery in Windows XP
Post mortem debugging does not work when using the .NET Framework 2.0 component
In order to post mortem debug .NET Framework applications, cut and paste the following registry entries into a .REG file and then import it into the device using RegEdit. The example below assumes the target debugger is columbo.exe.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]
"Auto"="1"
"Debugger"="\"C:\\WINDOWS\\system32\\columbo.exe\" -p %ld -e %ld"
@="mnmsrvc"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
"DbgManagedDebugger"="\"C:\\WINDOWS\\system32\\columbo.exe\" -p %ld -e %ld"
"DbgJITDebugLaunchSetting"=dword:00000002
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\Standards]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\Standards\Standard CLI 2002]
"v2.0.50727"=dword:00004095
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\Standards\Standard CLI 2005]
"v2.0.50727"=dword:00004095
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\Standards\v1.0.0]
"v2.0.50727"=dword:00050727
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\Upgrades]
"2.0.50727"="1.0.0-2.0.50727"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\v2.0]
"50727"="50727-50727"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\NGenService]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\NGenService\ListenedState]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\NGenService\Roots
User environment debugging logging
In order to generate the user environment debug log (userenv.log) in a Standard 2009 device, you may need to manually create the required folder first (e.g. C:\windows\debug\UserMode).
You can also create this automatically in your build by adding a File resource. In the "Extra Files" global setting in your Target Design, choose Add. Check the "Folder only" box, and set Destination to: %10%\Debug\UserMode.
General information about debugging the user environment:
How to enable user environment debug logging in retail builds of Windows
General XP Debugging Tips, Tools and Techniques
Since Standard 2009 is based on the exact same binaries and architecture as XP Professional, you use the same debugging tools.
MSDN Visual Studio: Debugging in Visual Studio
MSDN Visual Studio: Remote Debugging Setup
Kernel debugging: Debugging Tools for Windows - Overview
Kernel debugging: Huge list of links to KB Articles on Driver Development and Debugging
For a list of debugging related components, Data->Sort the "Windows Embedded Standard 2009 Components.xls" spreadsheet by the column named Debug / Development Tools.
Creating Dump Files in Standard 2009
Consider including the following components to facilitate debugging:
Disk Dump Drivers (contains diskdump.sys, used for SCSI or SATA storage devices)
Dr. Watson Debugger
Save Dump (for writing minidumps on a system crash, not need for a kernel or complete memory dump).
Safe Mode Support (adds F8 functionality when system boots).
Kernel mode debugging overview Varieties of Kernel-Mode Dump Files
Complete Memory Dump
This file contains all the physical memory for the machine at the time of the fault.
Kernel Memory Dump
This file contains all the memory in use by the kernel at the time of the crash.
Small Memory Dump (“Minidump”)
This file contains bug check information, list of loaded drivers, the PRCB, EPROCESS, ETHREAD, and kernel-mode stack for the process and thread that failed.
This is sent to Microsoft if you allow it (Online Crash Analysis).
To enable Kernel-Mode Dump File Creation:
Control Panel | System | Advanced | Startup and Recovery
The paging file on the boot partition must be large enough to hold a temporary copy of the dump file.
Forcing the Creation of a Kernel-Mode Dump File
Creating a Kernel-Mode Dump File from the Debugger
.crash (Force system crash)
.dump (Generate dump file with more options than .crash; also does not crash system)
Forcing a Kernel-Mode Dump File creation from the Keyboard
This approach does not work with USB keyboards; only PS/2 style keyboards can be used.
1. Use Regedit to set:
HKLM\Sys\CurrentCS\Services\i8042prt\Parameters Value: CrashOnCtrlScroll equal to REG_DWORD 0x1
2. To engage crash, use this sequence on the keyboard:
++
Opening a Kernel-Mode Dump File
Start WinDbg
Open the dump file
Resolve any symbol problems
Use !analyze -v
Automatically interprets bug check code and parameters
For more details on a bug check, see the debugger documentation under “Bug Checks (Blue Screens)” ® “Bug Check Code Reference”
You can inspect the stack trace given in the !analyze -v output for clues in module names and routine names.
Collecting Information from a Kernel Mode Dump
.bugcheck displays bug check code and parameters
!process 0 0 lists all processes with their image names
!process displays information about a specified (or current) process
!thread displays information about a specified (or current) thread
!drivers displays list of each driver loaded
!locks displays kernel eresource locks
!vm displays a summary of memory use on the target computer
!pool displays information about suspected pool address
!timer displays the system timer list
!errlog displays the contents of any pending error log entries
For more information, refer to the debugger documentation.
|