The development team at Microsoft has made a number of changes to the architecture of Windows CE in version 6.0. One of these is a new model for loading device drivers that can provide for increased security, robustness or performance.
Prior to CE6, device drivers primarily resided in the device.exe process.
The new kernel architecture provides more flexibility by providing two different driver models. The old device.exe functionality has been moved into the kernel, and a new user device process (udevice.exe) has been introduced. This change results in two different driver models, kernel mode drivers and user mode drivers. BSP developers must choose how each of their drivers will be implemented on a particular platform.
Kernel Mode Drivers
Kernel mode drivers are loaded by device.dll inside of the kernel. This is the default behavior, and most closely resembles the old device.exe model. The big win here is performance – the expensive interprocess calls (thunks) have been eliminated. There is no need for the user mode process initiating a driver access to be switched out, because the user mode process coexists with the kernel. The kernel includes the file system and device drivers so everything is resident in memory at the same time.
This new performance benefit comes at a price. Kernel mode drivers are now a part of the kernel, and they have full privileges for the entire kernel address space. A driver failure that results in memory corruption could easily bring down the kernel and with it the entire system. Therefore it’s critical that kernel mode drivers be robust.
User Mode Drivers
CE6 provides a new mechanism to load drivers into individual user mode processes (called udevice.exe) instead of into the kernel. A driver that loads in this fashion is called a user mode driver, and it gives up a level of performance in return for increased system robustness and security. In addition, since user mode drivers run inside a user mode process they are restricted in their use of certain APIs . This security feature restricts drivers loading in user mode from arbitrarily accessing any hardware resource in the system.
Microsoft has designed the user mode driver model to have a very high level of compatibility with kernel mode drivers. There are very few differences between the two models, and a driver written for user mode can be loaded into kernel mode with no changes. A new kernel component called the user mode driver reflector handles the interface between user mode applications and the user mode driver. This means that applications do not need to be aware of how a particular driver was loaded.
It’s a simple matter to load a driver into user mode instead of the default kernel mode. There is a new bit defined in the Flags registry key that if set tells the kernel to load the corresponding driver into user mode. That’s it – nothing more to it. The user mode driver will run in its own process isolated from the kernel and the rest of the system. If the driver fails for some reason only its copy of udevice.exe is affected, the rest of the system should remain intact.
BSP developers now have the option of choosing between a high performance kernel mode driver and a more protected user mode driver. Untrusted third party drivers can be loaded into user mode to increase system security and robustness. Unstable or otherwise questionable drivers can start life in user mode and then be moved to kernel mode as they become proven.
參考來源：http://www.bsquare.com/blog/default-aug_21.asp
