Wednesday, March 17, 2004
Designing and Optimizing Microsoft Windows CE .NET for Real-Time Performance
See this link:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncenet/html/rtnetdesigning.asp
Tuesday, March 16, 2004
Windows CE 3.0 Kernel Features
Tuesday, March 09, 2004
How to persistent the slider position in Storage/Program Memory setting dialog on WinCE.NET
1. Create a Registry key to holding the slider postion. For instance:
[HKEY_LOCAL_MACHINE\System\StorageMemory]
"SliderPostion"=dword:20
2. When saving system Registry, using GetSystemMemoryDivision () function to retreive current slider postion and save returned value in above Registry key.
This will be part of the function of Registry saving utility.
3. Write a startup application. This application should startup right after system startup. The startup application will read the slider position from the Registry then call SetSystemMemoryDivision() function to set the slider psotion as last time when we save the Registry.
[HKEY_LOCAL_MACHINE\System\StorageMemory]
"SliderPostion"=dword:20
2. When saving system Registry, using GetSystemMemoryDivision () function to retreive current slider postion and save returned value in above Registry key.
This will be part of the function of Registry saving utility.
3. Write a startup application. This application should startup right after system startup. The startup application will read the slider position from the Registry then call SetSystemMemoryDivision() function to set the slider psotion as last time when we save the Registry.
Sunday, March 07, 2004
What is the difference between OHCI and UHCI controllers?
Answer One:
What is the difference between OHCI and UHCI controllers?
In brief:
OHCI is made by Microsoft and emphasizes the fact that hardware should be smart to facilitate the software's task.
UHCI is made by Intel and stupid, in order to facilitate a low gate count.
Bottom line, OHCI has some brains and is actually able to transfer 8kb transfers in one go. UHCI needs to be told every single thing about a transfer: transfer descriptors, size of transfers, but also the sequence in which iso, interrupt, bulk and control transfers need to be done. It also means that the amount of overhead on the PCI bus on OHCI should be lower, allthough I have not measured that yet. OHCI is being used in firewire as well I believe. UHCI is simply to slow for that.
Answer Two:
OHCI: Open Host Controller Interface.
UHCI: Universal Host Controller Interface
UHCI and OHCI are types of USB host controller. According to our understanding, the difference between these two controller types is in the bus traffic scheduling timing. OHCI has stricter requirements regarding the timing at which devices are accessed.
Macintosh computers use OHCI, but there are some Windows PCs that use OHCI as well. Microsoft prepares drivers for both OHCI and UHCI for use with Windows.
What is the difference between OHCI and UHCI controllers?
In brief:
OHCI is made by Microsoft and emphasizes the fact that hardware should be smart to facilitate the software's task.
UHCI is made by Intel and stupid, in order to facilitate a low gate count.
Bottom line, OHCI has some brains and is actually able to transfer 8kb transfers in one go. UHCI needs to be told every single thing about a transfer: transfer descriptors, size of transfers, but also the sequence in which iso, interrupt, bulk and control transfers need to be done. It also means that the amount of overhead on the PCI bus on OHCI should be lower, allthough I have not measured that yet. OHCI is being used in firewire as well I believe. UHCI is simply to slow for that.
Answer Two:
OHCI: Open Host Controller Interface.
UHCI: Universal Host Controller Interface
UHCI and OHCI are types of USB host controller. According to our understanding, the difference between these two controller types is in the bus traffic scheduling timing. OHCI has stricter requirements regarding the timing at which devices are accessed.
Macintosh computers use OHCI, but there are some Windows PCs that use OHCI as well. Microsoft prepares drivers for both OHCI and UHCI for use with Windows.
Saturday, March 06, 2004
RAS Server registry settings
consist of 3 groups:
1. Global server settings
2. Per-line settings
3. User credential information
1 -- Global Server settings
---------------------------
Global RAS Server Registry settings are found under the key
HKLM\Comm\ppp\Server\Parms.
They specify settings that will be common to all connections.
Server IP Address Configuration
-------------------------------
The manner in which the RAS server allocates IP addresses for client connections can be configured by setting the following registry entries:
"UseDhcpAddresses" DWORD (default:0)
Set to 1 to have the RAS Server lease IP addresses from a DHCP server. Setting this to 1 will preclude the use of AutoIP or Static addressing described below.
"UseAutoIPAddresses" DWORD (default:1)
Note: Not supported in CE 4.0, added in 4.1.
Set to 1 to have the RAS server generate "random" IP addresses from the AutoIp pool.
"AutoIPSubnet" DWORD (default: 0xC0A80000 = 192.168.x.x)
"AutoIPSubnetMask" DWORD (default: 0xFFFF0000 = 255.255.0.0)
These 2 parameters define the subnet that "random" IP addresses will be generated from if UseAutoIPAddresses is enabled.
"StaticIpAddrStart" DWORD (default: 0xC0A8FE01 = 192.168.254.1)
"StaticIpAddrCount" DWORD (default: 254)
If neither Dhcp nor AutoIP is enabled, then the RAS server will use addresses from this pool, allocating the lowest address not currently in use by the RAS server when it needs to allocate an IP address
Server Misc Configuration
-------------------------
"AuthenticationMethods" DWORD (default: PAP, MD5-CHAP, MS-CHAP, MS-CHAPv2 allowed, EAP prohibited)
This value specifies which Authentication types are allowed. It is a bitmask of the following constants defined in sdk\inc\ras.h:
RASEO_ProhibitPAP
RASEO_ProhibitCHAP
RASEO_ProhibitMsCHAP
RASEO_ProhibitMsCHAP2
RASEO_ProhibitEAP
Setting it to 0 will allow all authentication types, setting it 0xFFFFFFFF will disable authentication.
Note that the WinCE EAP module does not currently support the authenticator role, so even if the RAS server is set to enable EAP clients will not be able to successfully connect using it.
"Flags" DWORD (default: 0)
This is a bitmask of the following option values:
0x01 - Requires data encryption on client connections
0x02 - Allows unauthenticated access to the server
0x04 - Prevents the use of VJ header compression
0x08 - Prevents the use of Data compression
Server Startup
--------------
"Enable" DWORD (default: 0)
This is the master server enable switch. Setting it to 1 causes the server to be enabled at system startup time.
"StartupDelaySeconds" DWORD (default: 20)
This specifies the number of seconds to wait at boot time before starting the RAS server.
This allows for other system components to complete initialization (e.g. networking adapters and DHCP)prior to initializing the RAS server.
2 -- Per-line settings
----------------------
These settings are used to specify which lines are to be used by the RAS server to listen for incoming
connections from clients, and to specify settings on an individual line basis.
These settings are found in the registry key
HKLM\Comm\ppp\Server\Line\\.
Available device names can be discovered using the RasEnumDevices API.
"Enable" DWORD (default 0)
Set this to 1 to enable incoming connections on the line
"DeviceType" SZ
This specifies the type of device, which is one of the "RASDT_xxx" values
from sdk\inc\ras.h:
"direct"
"modem"
"vpn"
"PPPoE"
"DeviceInfo" BINARY
This specifies device configuration information which is opaque to the RAS server. It is used to configure the device when it is being initialized to listen for incoming connections.
"Flags" DWORD (default: 0)
This value is identical to the Global Server Flags value. The flags in use for a particular line are determined by ORing together the global flags with the per-line flags.
3 -- User Credential Information
--------------------------------
Direct registry access to user credential information is not supported.
Use the RASCNTL_SERVER_USER_SET_CREDENTIALS and
RASCNTL_SERVER_USER_DELETE_CREDENTIALS IOCNTLs.
1. Global server settings
2. Per-line settings
3. User credential information
1 -- Global Server settings
---------------------------
Global RAS Server Registry settings are found under the key
HKLM\Comm\ppp\Server\Parms.
They specify settings that will be common to all connections.
Server IP Address Configuration
-------------------------------
The manner in which the RAS server allocates IP addresses for client connections can be configured by setting the following registry entries:
"UseDhcpAddresses" DWORD (default:0)
Set to 1 to have the RAS Server lease IP addresses from a DHCP server. Setting this to 1 will preclude the use of AutoIP or Static addressing described below.
"UseAutoIPAddresses" DWORD (default:1)
Note: Not supported in CE 4.0, added in 4.1.
Set to 1 to have the RAS server generate "random" IP addresses from the AutoIp pool.
"AutoIPSubnet" DWORD (default: 0xC0A80000 = 192.168.x.x)
"AutoIPSubnetMask" DWORD (default: 0xFFFF0000 = 255.255.0.0)
These 2 parameters define the subnet that "random" IP addresses will be generated from if UseAutoIPAddresses is enabled.
"StaticIpAddrStart" DWORD (default: 0xC0A8FE01 = 192.168.254.1)
"StaticIpAddrCount" DWORD (default: 254)
If neither Dhcp nor AutoIP is enabled, then the RAS server will use addresses from this pool, allocating the lowest address not currently in use by the RAS server when it needs to allocate an IP address
Server Misc Configuration
-------------------------
"AuthenticationMethods" DWORD (default: PAP, MD5-CHAP, MS-CHAP, MS-CHAPv2 allowed, EAP prohibited)
This value specifies which Authentication types are allowed. It is a bitmask of the following constants defined in sdk\inc\ras.h:
RASEO_ProhibitPAP
RASEO_ProhibitCHAP
RASEO_ProhibitMsCHAP
RASEO_ProhibitMsCHAP2
RASEO_ProhibitEAP
Setting it to 0 will allow all authentication types, setting it 0xFFFFFFFF will disable authentication.
Note that the WinCE EAP module does not currently support the authenticator role, so even if the RAS server is set to enable EAP clients will not be able to successfully connect using it.
"Flags" DWORD (default: 0)
This is a bitmask of the following option values:
0x01 - Requires data encryption on client connections
0x02 - Allows unauthenticated access to the server
0x04 - Prevents the use of VJ header compression
0x08 - Prevents the use of Data compression
Server Startup
--------------
"Enable" DWORD (default: 0)
This is the master server enable switch. Setting it to 1 causes the server to be enabled at system startup time.
"StartupDelaySeconds" DWORD (default: 20)
This specifies the number of seconds to wait at boot time before starting the RAS server.
This allows for other system components to complete initialization (e.g. networking adapters and DHCP)prior to initializing the RAS server.
2 -- Per-line settings
----------------------
These settings are used to specify which lines are to be used by the RAS server to listen for incoming
connections from clients, and to specify settings on an individual line basis.
These settings are found in the registry key
HKLM\Comm\ppp\Server\Line\
Available device names can be discovered using the RasEnumDevices API.
"Enable" DWORD (default 0)
Set this to 1 to enable incoming connections on the line
"DeviceType" SZ
This specifies the type of device, which is one of the "RASDT_xxx" values
from sdk\inc\ras.h:
"direct"
"modem"
"vpn"
"PPPoE"
"DeviceInfo" BINARY
This specifies device configuration information which is opaque to the RAS server. It is used to configure the device when it is being initialized to listen for incoming connections.
"Flags" DWORD (default: 0)
This value is identical to the Global Server Flags value. The flags in use for a particular line are determined by ORing together the global flags with the per-line flags.
3 -- User Credential Information
--------------------------------
Direct registry access to user credential information is not supported.
Use the RASCNTL_SERVER_USER_SET_CREDENTIALS and
RASCNTL_SERVER_USER_DELETE_CREDENTIALS IOCNTLs.
Intel IPSM driver Registry settings when use flash as the storage device for hive-based Registry files
; HIVE BOOT SECTION
[HKEY_LOCAL_MACHINE\System\StorageManager\AutoLoad\PSM]
"Dll"="PSMFSD.dll"
"Paging"=dword:1
"LoadFlags"=dword:1
"MountFlags"=dword:2
[HKEY_LOCAL_MACHINE\System\StorageManager]
"Dll"="fsdmgr.dll"
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\FlshDrv]
"FolderName"="FLASH"
; END HIVE BOOT SECTION
; HIVE BOOT SECTION
[HKEY_LOCAL_MACHINE\init\BootVars]
"SYSTEMHIVE"="Documents and Settings\\system.hv"
"PROFILEDIR"="Documents and Settings"
"Start DevMgr"=dword:1
; END HIVE BOOT SECTION
[HKEY_LOCAL_MACHINE\System\StorageManager\AutoLoad\PSM]
"Dll"="PSMFSD.dll"
"Paging"=dword:1
"LoadFlags"=dword:1
"MountFlags"=dword:2
[HKEY_LOCAL_MACHINE\System\StorageManager]
"Dll"="fsdmgr.dll"
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\FlshDrv]
"FolderName"="FLASH"
; END HIVE BOOT SECTION
; HIVE BOOT SECTION
[HKEY_LOCAL_MACHINE\init\BootVars]
"SYSTEMHIVE"="Documents and Settings\\system.hv"
"PROFILEDIR"="Documents and Settings"
"Start DevMgr"=dword:1
; END HIVE BOOT SECTION
What is the Hive-based Registry and how to use it?
The hive-based registry is our answer to the difficult problem of persisting data on a device which does not power its RAM when turned off. In previous versions of the OS, registry save/restore meant dumping the entire registry to the OEM, a process which is slow and can be difficult to implement due to the unavailability of system calls in the OAL. The hive-based registry saves parts of the registry in files (hives) that can be stored on any file system. This frees the OEM up to easily store the registry on a disk, flash chip, or any other nonvolatile storage. The registry is broken into two parts: the system hive containing all data under HKEY_LOCAL_MACHINE, HKEY_CLASSES_ROOT, and HKEY_USERS; and the user hive containing all data under HKEY_CURRENT_USER. This enables user profile support because user hives can be swapped to keep users' data separate.
SETTING UP THE HIVE-BASED REGISTRY
---------------------------------------------------
The hive-based registry is currently only available for use on top of the FAT file system. In the final Talisker release it will be available for use with any file system.
1. Add the hive-based registry component (fsreghive) to your device configuration and make sure the object store-based registry component (fsreg) is not included. Make sure to do a clean build the first time after
changing your configuration.
2. (This step is necessary in our Beta1 release but will not be necessary in Beta2 or beyond.)
Set the IMGREGHIVE environment variable to 1. This causes registry hives to be generated when the image is made.
3. Check these settings in the platform.reg file:
[HKEY_LOCAL_MACHINE\init\BootVars]
"SYSTEMHIVE"=""
"PROFILEDIR"=""
"Start DevMgr"=dword:
"NoDefaultUser"=dword:
"SYSTEMHIVE" is the location and name of the system hive file. Do not include the name of the file system the file will be stored on; it will be inferred from other settings described below. Typically this will be a simple location such as "system.hv" or "Registry\\system.hv".
"PROFILEDIR" is the location of the root directory where user profiles are stored. Each user will be given a separate directory under the PROFILEDIR. Do not include the name of the file system the file will be stored on; it will be stored on the same file system as the system hive. Typically this will be blank "" or a directory such as "Documents and Settings".
"Start DevMgr" is a boolean indicating whether the device manager (device.exe) must be started to start the drivers necessary to reach the registry hives. A value of 1 will cause device manager to be started; 0
will not. The only case in which device manager should NOT be started is if the hives are to be stored in the object store, causing them to be lost on a cold boot. Typically the hives are stored outside RAM and so device manager is necessary.
"NoDefaultUser" is a boolean indicating whether a default user should be logged in on boot. The default user is typically used on single-user devices, to contain settings that would otherwise be specific to one user. To enable a multi-user environment, set this value to 1. In that case no user will be logged in on boot. See the Platform Builder documentation on user profiles for more information on how to log in other users.
4. Make sure the boot registry contains all information necessary to start the drivers and file systems needed to reach the system hive. The boot registry is an unchanging registry containing a minimum set of information necessary to boot up to the point that the persistent system registry can be reached. In your platform.reg file, for each driver and file system needed to boot:
a. Make sure its entries are wrapped in the comments
; HIVE BOOT SECTION
; END HIVE BOOT SECTION
These tags add the entries to the boot hive.
b. Set this flag bit:
[HKEY_LOCAL_MACHINE\Drivers\...]
"Flags"=dword:1000
The flags are a bitmask to OR with any existing settings. This flag tells device manager to load your driver with the boot registry and not to load it a second time with the system registry.
5. (This step is temporary until all file systems can be used with the hive-based registry.)
Set this registry value in common.reg or platform.reg:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FATFS]
"Flags"=dword:00020024.
6. Choose a flushing mechanism and implement it. The operating system does not perform any lazy flushing; it may flush some data in the background but cannot be relied on to flush all data reliably. To ensure that data is not lost, call RegFlushKey before the device is shutdown. That will flush any unsaved changes in the hive to the persistent file. The flush can occur during a shutdown sequence, or thread can be set up to do periodic flushes.
It will not damage anything to call RegFlushKey when no data has changed; in that case the file will not be touched. RegFlushKey should be called on both the system hive (HKEY_LOCAL_MACHINE) and the user hive
(HKEY_CURRENT_USER).
TROUBLESHOOTING
---------------------------
Possible problems include:
1. The build reports that the file default.fdf is missing. In this case a clean rebuild is necessary.
2. The build reports that default.hv, boot.hv, and user.hv are missing. Make sure you did step 2 of the setup instructions.
3. The build succeeds but it hangs soon after boot. Possible causes include:
- The device manager was never started. Set "Start DevMgr" = 1; see step 3 of the setup instructions.
- The device manager was started but the necessary file system was not. Make sure all registry entries for that file system, block driver, etc. are in the boot registry; see step 4a of the setup instructions. Also make sure the file system driver has the flag set to load it in the first boot phase; see step 4b.
- The necessary file system was started but didn't register as a "boot" file system. Make sure you did step 5 of the setup instructions.
- The configuration originally did not include the hive-based registry, and a full clean build was not done. Make sure to do a clean build after including the fsreghive component in your configuration.
4. The device boots but occasionally registry data is lost when the device is powered off. This can happen if changes are not flushed out to the persistent file. See step 6 of the setup instructions.
SETTING UP THE HIVE-BASED REGISTRY
---------------------------------------------------
The hive-based registry is currently only available for use on top of the FAT file system. In the final Talisker release it will be available for use with any file system.
1. Add the hive-based registry component (fsreghive) to your device configuration and make sure the object store-based registry component (fsreg) is not included. Make sure to do a clean build the first time after
changing your configuration.
2. (This step is necessary in our Beta1 release but will not be necessary in Beta2 or beyond.)
Set the IMGREGHIVE environment variable to 1. This causes registry hives to be generated when the image is made.
3. Check these settings in the platform.reg file:
[HKEY_LOCAL_MACHINE\init\BootVars]
"SYSTEMHIVE"=""
"PROFILEDIR"=""
"Start DevMgr"=dword:
"NoDefaultUser"=dword:
"SYSTEMHIVE" is the location and name of the system hive file. Do not include the name of the file system the file will be stored on; it will be inferred from other settings described below. Typically this will be a simple location such as "system.hv" or "Registry\\system.hv".
"PROFILEDIR" is the location of the root directory where user profiles are stored. Each user will be given a separate directory under the PROFILEDIR. Do not include the name of the file system the file will be stored on; it will be stored on the same file system as the system hive. Typically this will be blank "" or a directory such as "Documents and Settings".
"Start DevMgr" is a boolean indicating whether the device manager (device.exe) must be started to start the drivers necessary to reach the registry hives. A value of 1 will cause device manager to be started; 0
will not. The only case in which device manager should NOT be started is if the hives are to be stored in the object store, causing them to be lost on a cold boot. Typically the hives are stored outside RAM and so device manager is necessary.
"NoDefaultUser" is a boolean indicating whether a default user should be logged in on boot. The default user is typically used on single-user devices, to contain settings that would otherwise be specific to one user. To enable a multi-user environment, set this value to 1. In that case no user will be logged in on boot. See the Platform Builder documentation on user profiles for more information on how to log in other users.
4. Make sure the boot registry contains all information necessary to start the drivers and file systems needed to reach the system hive. The boot registry is an unchanging registry containing a minimum set of information necessary to boot up to the point that the persistent system registry can be reached. In your platform.reg file, for each driver and file system needed to boot:
a. Make sure its entries are wrapped in the comments
; HIVE BOOT SECTION
; END HIVE BOOT SECTION
These tags add the entries to the boot hive.
b. Set this flag bit:
[HKEY_LOCAL_MACHINE\Drivers\...]
"Flags"=dword:1000
The flags are a bitmask to OR with any existing settings. This flag tells device manager to load your driver with the boot registry and not to load it a second time with the system registry.
5. (This step is temporary until all file systems can be used with the hive-based registry.)
Set this registry value in common.reg or platform.reg:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FATFS]
"Flags"=dword:00020024.
6. Choose a flushing mechanism and implement it. The operating system does not perform any lazy flushing; it may flush some data in the background but cannot be relied on to flush all data reliably. To ensure that data is not lost, call RegFlushKey before the device is shutdown. That will flush any unsaved changes in the hive to the persistent file. The flush can occur during a shutdown sequence, or thread can be set up to do periodic flushes.
It will not damage anything to call RegFlushKey when no data has changed; in that case the file will not be touched. RegFlushKey should be called on both the system hive (HKEY_LOCAL_MACHINE) and the user hive
(HKEY_CURRENT_USER).
TROUBLESHOOTING
---------------------------
Possible problems include:
1. The build reports that the file default.fdf is missing. In this case a clean rebuild is necessary.
2. The build reports that default.hv, boot.hv, and user.hv are missing. Make sure you did step 2 of the setup instructions.
3. The build succeeds but it hangs soon after boot. Possible causes include:
- The device manager was never started. Set "Start DevMgr" = 1; see step 3 of the setup instructions.
- The device manager was started but the necessary file system was not. Make sure all registry entries for that file system, block driver, etc. are in the boot registry; see step 4a of the setup instructions. Also make sure the file system driver has the flag set to load it in the first boot phase; see step 4b.
- The necessary file system was started but didn't register as a "boot" file system. Make sure you did step 5 of the setup instructions.
- The configuration originally did not include the hive-based registry, and a full clean build was not done. Make sure to do a clean build after including the fsreghive component in your configuration.
4. The device boots but occasionally registry data is lost when the device is powered off. This can happen if changes are not flushed out to the persistent file. See step 6 of the setup instructions.
What's the difference between uncached memory and cached memory?
On the StrongARM, Windows CE maps each of the memory ranges specified in the OEMAddressTable to two different virtual addresses, on between 0x80000000 and 0x9FFFFFFF and the second between 0xA0000000 and 0xBFFFFFFF. The first range is configured in the page tables with the Cacheable and Bufferable bits. Reads and writes for these ranges pass through the StrongARM's 8 Kbyte data cache. These virtual addresses are typically used for RAM read/writes and ROM reads because of the performance gained. The second range is mapped in the page tables with the Cacheable and Bufferable bits off, so accesses within this range do not use the StrongARM's dcache. These addresses are intended for use when performing I/O or other operations where caching is not appropriate.
The StrongARM's main dcache is organized as 256 lines of 8 32-bit words and is 32-way set associative. A memory read into a cached region that misses (i.e. not already stored in) the cache causes an 8-word cache line fill into the cache. Subsequent reads that hit the cache are delivered out of the cache and do not require further accesses to the physical memory and are MUCH faster. Similarly, writes that hit the cache are stored into the cache and mark the cache line as dirty. Once all 32-ways of the cache are allocated, the next cache read miss causes the first way to be replaced (copying it back to memory first if it was marked dirty).
The StrongARM's main dcache is organized as 256 lines of 8 32-bit words and is 32-way set associative. A memory read into a cached region that misses (i.e. not already stored in) the cache causes an 8-word cache line fill into the cache. Subsequent reads that hit the cache are delivered out of the cache and do not require further accesses to the physical memory and are MUCH faster. Similarly, writes that hit the cache are stored into the cache and mark the cache line as dirty. Once all 32-ways of the cache are allocated, the next cache read miss causes the first way to be replaced (copying it back to memory first if it was marked dirty).
Enable detailed debug message in Platform Builder
If you're running a debug build and you've turned on
[HKEY_CURRENT_USER\Pegasus\Zones]
"FileSys"=dword:20
in your DESKTOP registry, then you should be getting enough debug
information to figure out the basic reason for the hang. I can tell you
right now the registry is waiting for a file system to be loaded with
MountFlags=2. Either IPSM isn't getting loaded, or it isn't getting those
flags. Possible reasons include you not wrapping the registry settings
with the "HIVE BOOT SECTION" tags, so that they aren't present in the boot
hive. There are more reasons outlined in this document:
http://msdn.microsoft.com/library/en-us/wcedsn40/html/cgconTroubleshootingRegistryImplementation.asp
[HKEY_CURRENT_USER\Pegasus\Zones]
"FileSys"=dword:20
in your DESKTOP registry, then you should be getting enough debug
information to figure out the basic reason for the hang. I can tell you
right now the registry is waiting for a file system to be loaded with
MountFlags=2. Either IPSM isn't getting loaded, or it isn't getting those
flags. Possible reasons include you not wrapping the registry settings
with the "HIVE BOOT SECTION" tags, so that they aren't present in the boot
hive. There are more reasons outlined in this document:
http://msdn.microsoft.com/library/en-us/wcedsn40/html/cgconTroubleshootingRegistryImplementation.asp
