none
Windows CE6 USB Mass Storage Device in RAM-based registry configuration RRS feed

  • Question

  • I'm developing a Windows CE6r3-based device, and we're exposing the internal NAND flash on the device as a USB mass storage device when you connect it to a host PC.  This works fine in our current configuration which uses a hive-based registry, but we're looking to switch to a RAM-based registry for bootup performance reasons.  One problem that I'm running into is that when I switch a device to the RAM-based registry the USB MS stops working.  The host PC recognizes it as a mass storage device but does not mount it as a drive.

    From the research that I've done so far I'm assuming that this is because in hive configuration the kernel loads the NAND driver and FATFS driver from the boot registry, but in RAM configuration the FATFS driver may not be loaded when the USBFN driver executes, so the disk may not be initialized.  Does this sound correct?  Is there any way to guarantee that the NAND is loaded and mounted as a disk before the USB driver loads?  The NAND_flash and USBFN drivers are correctly ordered in HKLM\Drivers\Builtin, but my understanding is that the FATFS driver is loaded by a separate process, correct?

    Thursday, August 2, 2012 3:25 PM

All replies

  • Very strange to hear that when you store your hive on your NAND drive and you expose that same NAND drive as USBFn MS that your kernel still works. It should not. The first time the system wants to write the registry it should crash/hang/dead because the NAND drive is dismounted as soon as it is exposed through USBFn MS. Are you sure the hive was stored on the same drive as you were exposing?

    To answer your other question; FATFS is loaded by the storage manager so you need to set the orders for all good, or delay load the USBFn MS driver. You could also clone the USBFn MS driver and add some checking for availability of the store before continuing the initialization.


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.

    Thursday, August 2, 2012 11:40 PM
    Moderator
  • Michel,

    Thanks for the response. It would make sense that having the hive on the NAND drive exposed by the USBMS driver would be problematic; I think we manage to get away with it because when our device is in mass storage mode we shut down our application and all other activity.  So there shouldn't be any registry writes at that point.  Moving away from the hive registry should remove any conflicts for good.

    I'm not clear on how to ensure that the storage manager loads the FATFS driver before the device manager loads the USBFn driver.  I know the "Order" registry subkey controls driver loading by the Device Manager, but my searching hasn't managed to turn up anything similar for the Storage Manager.  Are you aware of any documentation on how to order drivers within Storage Manager, or force Storage Manager to run before Device Manager?  Thanks.

      --Seth

    Tuesday, August 7, 2012 5:10 PM
  • Well, if you keep hive based registry you could put the storage manager in boot phase 0 (in HIVE BOOT SECTION tags) and load USB in phase 1. If you want to start with a clean hive every time then implement IOCTL_HAL_GET_HIVE_CLEAN_FLAG and always set the flag to TRUE.

    You also need to set up the Flags value in HKLM\Init so that storage manager loads in boot phase 0.

    You'd have to try if this trick works with RAM based registry as well.

    It's strange though, I've never had this problem so I'm wondering what is different on your system. Can't you just wait for the store notification in the USB MS driver (after cloning it)?


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.


    Tuesday, August 7, 2012 9:50 PM
    Moderator