none
[CE 6] hive registry access failure after remount RRS feed

  • Question

  • Hi,

    This is for Windows Embedded CE 6.0 R3.

    I have an OSDesign where the hive-based registry lays on Part00 partition of the main storage device (a CompactFlash actually).

    If, using the Storage Manager Control Panel applet, I dismount Part00 then remount it and then launch Bruce Eitman's RegEdit program (here), I experiment a lot of Registry access failures:

    91092 PID:16c0102 TID:16f014a OSAXST1: >>> Loading Module 'coredll.dll' (0x9FFF878C) at address 0x40010000-0x400D5000 in Process 'REGEDIT.EXE' (0x8BE9E000) 91101 PID:16c0102 TID:16f014a OSAXST1: >>> Loading Module 'REGEDIT.EXE' (0x8BE9E000) at address 0x00010000-0x0001C000 in Process 'REGEDIT.EXE' (0x8BE9E000) PB Debugger Loaded 'REGEDIT.EXE', no matching symbolic information found. 91390 PID:400002 TID:16f014a OSAXST1: >>> Loading Module 'mscoree.dll' (0x8BE9E530) at address 0x41C50000-0x41C60000 in Process 'NK.EXE' (0x82E99C80) PB Debugger Loaded 'C:\WINCE600\OSDESIGNS\SPEC1\RELDIR\AIBED_X86_DEBUG\MSCOREE.DLL', no matching symbolic information found. 91411 PID:16c0102 TID:16f014a OSAXST1: >>> Loading Module 'mscoree.dll' (0x8BE9E530) at address 0x41C50000-0x41C60000 in Process 'REGEDIT.EXE' (0x8BE9E000) 91420 PID:16c0102 TID:16f014a OSAXST1: >>> Loading Module 'ole32.dll' (0x8AF1D000) at address 0x40570000-0x40627000 in Process 'REGEDIT.EXE' (0x8BE9E000) 91428 PID:16c0102 TID:16f014a OSAXST1: >>> Loading Module 'rpcrt4.dll' (0x8AF1D1A4) at address 0x406A0000-0x40714000 in Process 'REGEDIT.EXE' (0x8BE9E000) 91437 PID:16c0102 TID:16f014a OSAXST1: >>> Loading Module 'lpcrt.dll' (0x8AF1D2DC) at address 0x40450000-0x40456000 in Process 'REGEDIT.EXE' (0x8BE9E000) 91588 PID:400002 TID:16f014a OSAXST1: >>> Loading Module 'mscoree3_5.dll' (0x8BE65000) at address 0x41C70000-0x41D20000 in Process 'NK.EXE' (0x82E99C80) PB Debugger Loaded 'C:\WINCE600\OSDESIGNS\SPEC1\RELDIR\AIBED_X86_DEBUG\MSCOREE3_5.DLL', no matching symbolic information found. 91600 PID:16c0102 TID:16f014a OSAXST1: >>> Loading Module 'mscoree3_5.dll' (0x8BE65000) at address 0x41C70000-0x41D20000 in Process 'REGEDIT.EXE' (0x8BE9E000) 91609 PID:16c0102 TID:16f014a OSAXST1: >>> Loading Module 'ws2.dll' (0x8BB89540) at address 0x40300000-0x4030F000 in Process 'REGEDIT.EXE' (0x8BE9E000) 91887 PID:16c0102 TID:16f014a OSAXST1: >>> Loading Module 'oleaut32.dll' (0x8BBE78DC) at address 0x40630000-0x4066D000 in Process 'REGEDIT.EXE' (0x8BE9E000) 91907 PID:16c0102 TID:16f014a OSAXST1: >>> Loading Module 'toolhelp.dll' (0x9FE81D1C) at address 0x40130000-0x40135000 in Process 'REGEDIT.EXE' (0x8BE9E000) 91919 PID:400002 TID:16f014a OSAXST1: >>> Loading Module 'netcfagl3_5.dll' (0x8BEDC21C) at address 0x41D30000-0x41D60000 in Process 'NK.EXE' (0x82E99C80) PB Debugger Loaded 'C:\WINCE600\OSDESIGNS\SPEC1\RELDIR\AIBED_X86_DEBUG\NETCFAGL3_5.DLL', no matching symbolic information found. 91935 PID:16c0102 TID:16f014a OSAXST1: >>> Loading Module 'netcfagl3_5.dll' (0x8BEDC21C) at address 0x41D30000-0x41D60000 in Process 'REGEDIT.EXE' (0x8BE9E000) 91947 PID:16c0102 TID:16f014a OSAXST1: >>> Loading Module 'commctrl.dll' (0x8BC09CD4) at address 0x40170000-0x4021B000 in Process 'REGEDIT.EXE' (0x8BE9E000) 91959 PID:400002 TID:16f014a AddToProcessInputLocaleTable: Added process to ProcessInputLocale table, hProcess = 0x016C0102 92241 PID:16c0102 TID:16f014a OSAXST1: >>> Loading Module 'aygshell.dll' (0x8BCD2864) at address 0x41510000-0x41526000 in Process 'REGEDIT.EXE' (0x8BE9E000) 92511 PID:16c0102 TID:16f014a OSAXST1: <<< Unloading Module 'aygshell.dll' (0x8BCD2864) at address 0x41510000-0x41526000 in Process 'REGEDIT.EXE' (0x8BE9E000) 92599 PID:400002 TID:16f014a FATFS!FAT_DeviceIoControl returned LRESULT 0x57 92760 PID:16c0102 TID:16f014a OSAXST1: >>> Loading Module 'aygshell.dll' (0x8BCD2864) at address 0x41510000-0x41526000 in Process 'REGEDIT.EXE' (0x8BE9E000) 93284 PID:400002 TID:4f0002 NK Kernel: DEBUGCHK failed in file d:\yzkiqfe\private\winceos\COREOS\nk\MapFile\.\mapflush.c at line 404 93315 PID:400002 TID:4f0002 NK Kernel: DEBUGCHK failed in file d:\yzkiqfe\private\winceos\COREOS\nk\MapFile\.\mapflush.c at line 404 93338 PID:400002 TID:4f0002 NK Kernel: DEBUGCHK failed in file d:\yzkiqfe\private\winceos\COREOS\nk\MapFile\.\mapflush.c at line 404 93394 PID:400002 TID:16f014a Exception 'Access Violation' (14): Thread-Id=016f014a(pth=8be688b0), Proc-Id=00400002(pprc=82e99c80) 'NK.EXE', VM-active=016c0102(pprc=8be9e000) 'REGEDIT.EXE' 93394 PID:400002 TID:16f014a PC=c01939ec(filesys.dll+0x000239ec) RA=c019ba96(filesys.dll+0x0002ba96) SP=d519f620, BVA=d04f1000 93430 PID:400002 TID:16f014a ERROR: d:\yzkiqfe\private\winceos\COREOS\filesys\reg\reghive\..\regapi.c line 2070: 93430 PID:400002 TID:16f014a FS: Hive Exception Handler

    It appears that running any .NET program after remounting the partition breaks the hive-based Registry.

    Does anyone have an explanation?

    TIA


    Remi



    • Edited by rdg77 Thursday, January 7, 2016 2:52 PM
    Thursday, January 7, 2016 2:38 PM

Answers

  • Hi Remi,

    Maybe take a look at how ScanVolume() & DWORD DisableAutoScan interact for some ideas.

    Sincerely,

    IoTGirl

    • Marked as answer by rdg77 Monday, January 11, 2016 5:58 PM
    Thursday, January 7, 2016 6:38 PM
    Moderator

All replies

  • Remi:

    First, please explain why you would dismount and the remount the disk. That is something that you simply must not do because you have open files that expect the disk to remain mounted.

    This has nothing to do with my registry editor or .NET applications.



    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman
    I work for Eurotech

    Thursday, January 7, 2016 3:06 PM
    Moderator
  • Hi Bruce,

    I know your program is certainly not the culprit in this affair: it is simply the quickest way to cause/show the problem. Sorry for the inconvenience.

    The reason why I want to dismount and remount the disk is that I would like to scan it for errors before I launch the application. I actually wrote a utility that performs this scan and fixes FAT errors if any. The program does its job but I discovered that running a .NET program after running it introduced some trouble in the system. Then I simply used the Storage Manager applet to create the problem.

    As I mentioned before, everything seems to go fine while I don't launch any .NET program.

    So I can imagine I have "open files that expect the disk to remain mounted" (Registry memory-mapped files?) but I can't see why running a C# program messes my Registry.

    Thanks for your answer.


    Remi

    Thursday, January 7, 2016 3:32 PM
  • Hi Remi,

    The Compact Framework Runtime likely has such links to memory. You will note that the desktop OS waits for a reboot before running such a scan and fix.  I recommend you follow the same scenario on your device and run such a scan prior to launching the OS & Runtimes.

    Sincerely,

    IoTGirl

    Thursday, January 7, 2016 5:36 PM
    Moderator
  • Hi IoTGirl,

    Thanks for your answer.

    The point here is that I need an OS to perform the scan, and the only OS I have here is CE. Furthermore, as the Registry is hive-based, the disk has to be mounted pretty early and I am not sure I can make a driver of my scanning code... This is perhaps something I can try anyway.

    Best regards.


    Remi

    Thursday, January 7, 2016 6:07 PM
  • Hi Remi,

    Maybe take a look at how ScanVolume() & DWORD DisableAutoScan interact for some ideas.

    Sincerely,

    IoTGirl

    • Marked as answer by rdg77 Monday, January 11, 2016 5:58 PM
    Thursday, January 7, 2016 6:38 PM
    Moderator
  • Hi IoTGirl,

    Thanks for pointing me DisableAutoScan.

    My scanning utility of course uses fatutil.dll to do its job (DismountPartition, ScanVolumeEx and MountPartition) but it also saves the result of the scan to a file in the Object Store (in RAM), and this allows the application to know when something has been fixed. I would appreciate to have the same level of control but if the only way to do a clean scan of the disk is to clear DisableAutoScan in the Registry, I can fix myself (is this correct English?).

    My problem with DisableAutoScan is that I don't have the sources for exFAT and that I don't know what it actually does. I did not find valuable information in Microsoft documentation nor on the Net. If someone has this kind of information or can send me a source abstract, I'll be grateful ;-)

    Best Regards.


    Remi

    Friday, January 8, 2016 2:37 PM
  • Hi Remi,

    I think I would start your search at C:\WINCE600\PUBLIC\COMMON\OAK\DRIVERS\FSD\FATUTIL\MAIN of your Windows CE 6 install.  This location has the public source for the FAT Utilities.

    If you do not have this, then you are not the OEM of the device and will need to reach out to them for these sources as they apply to CE 6.

    Note that Compact 2013 (CE 8) does still have this directory and can be installed against VS 2013 should you want to review the latest versions of this code but they may have changed between versions.

    Sincerely,

    IoTGirl

    Friday, January 8, 2016 5:36 PM
    Moderator
  • Hi IoTGirl,

    I of course had a deep look at the fatutil.dll code before writing my scan utility. This is particularly needed when one wants to fix the FAT errors instead of only detecting them, as the documentation is very poor in this respect.

    I am the OEM of the device and I have access to both the public and the 'regular' private sources that came with Platform Builder (a few years ago, my company failed to obtain the 'super' sources for a few licences not solded).

    What I would like to know is "What does exfat.dll do when DisableAutoScan is 0?" Does it simply call ScanVolumeEx? If yes, does it the scan before mounting the disk (it would be clever)? What happens when errors are detected? Is there a mean to know that errors were fixed? Etc.

    Regards.


    Remi

    Friday, January 8, 2016 5:57 PM
  • Remi:

    No worries, just wanted to make sure that you were focused on where the problem really lies.  I was more concerned that you seemed to think that it was .NET CF related.  you seem to be on track now.



    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman
    I work for Eurotech

    Friday, January 8, 2016 6:43 PM
    Moderator
  • Hi Remi,

    DisableAutoScan is available on all FAT types so my suspicion is that it handled by the FSD manager and that calls utilities based on the GetVolumeType of the volume in question but I am not able to confirm the exact code path.

    Do you have any premium access to code at C:\WINCE600\PRIVATE\WINCEOS\COREOS\FSD\?  Mine does not seem to be complete.

    NOTE: The code I see for exfat looks pretty similar to C:\WINCE600\PLATFORM\CEPC\SRC\BOOTLOADER\BIOSLOADER\LOADER\fat.c so I suspect if you trace what happens for FAT it will be similar to what happens for exFAT.

    Sincerely,

    IoTGirl


    Friday, January 8, 2016 7:10 PM
    Moderator
  • Hi IoTGirl,

    For me, there is only one DLL that can handle both FAT and exFAT formats (as well as TFAT) and this DLL is exfat.dll. In the Registry, you can see that the only difference between FATFS and EXFAT configuration is the "FormatExfat" flag (and the FriendlyName) :

    [HKEY_LOCAL_MACHINE\System\StorageManager\FATFS]
        "FriendlyName"="FAT FileSystem"
        "Dll"="exfat.dll"
        "DisableAutoFormat"=dword:1
        "DisableAutoScan"=dword:1
        "Paging"=dword:1
        "EnableCache"=dword:1
        "CacheSize"=dword:0
        "Util"="fatutil.dll"
        "CacheDll"="diskcache.dll"

    [HKEY_LOCAL_MACHINE\System\StorageManager\EXFAT]
        "FriendlyName"="exFAT FileSystem"
        "Dll"="exfat.dll"
        "DisableAutoFormat"=dword:1
        "DisableAutoScan"=dword:1
        "Paging"=dword:1
        "EnableCache"=dword:1
        "CacheSize"=dword:0
        "Util"="fatutil.dll"
        "CacheDll"="diskcache.dll"
        "FormatExfat"=dword:1

    As far as I could search without doing too much reverse engeenering, the "DisableAutoScan" flag is retrieved by exfat.dll along with the other flags, in a routine that makes an intensive usage of the FSDMGR_GetRegistryFlag function.
    Thus I think the key code lays in exfat.dll. Of course, I may be wrong and the overall usage of all this may be trickier.

    I don't have premium (what I previously misnamed 'super') access to the FSD code. The only sources I have here are for BINFS, CACHEFILT, CDFS, RELFSD and UDF.

    The bootloader code in fat.c is very minimalistic and there no support for any kind of scanning there.

    Best Regards.

    Remi

    Saturday, January 9, 2016 4:21 PM
  • Hi Bruce,

    There are some facts that bother me however:

    • Under CE 6.0, if I don't run any .NET program after having dismounted/remounted the main partition, everything seems to be OK. I can launch any program I want, including another Registry editor, without visible trouble.
    • In the same conditions, under CE 4.2, I can run a program using .NET CF 2.0 without apparent trouble.
    • As far as I could have tested, I can also run your RegEdit.exe under WEC 7 without apparent trouble, even after having dismounted/remounted the disk.

    So I can imagine that both CE 4.2 and WEC 7 run 'by chance' because of different contexts compared with CE 6.0 but I stay unsatisfied because I don't understand what really happens at least for CE 6.0.

    Best Regards.


    Remi

    Monday, January 11, 2016 9:00 AM
  • OK. I reply to myself after a few experiments.

    I first built a CE 6.0 image with DisableAutoScan cleared:

    ; HIVE BOOT SECTION
    [HKEY_LOCAL_MACHINE\System\StorageManager\FATFS]
        "DisableAutoScan"=dword:0 ; enable autoscan
    ; END HIVE BOOT SECTION

    After having checked that this did not break anything, on my CompactFlash, I created a cross-link error on it by creating 2 dummy files (F1 and F2) in the root directory and making them point to the same cluster.

    Then I booted CE again and obtained this trace:

    4294770076 PID:400002 TID:1520002 FSDMGR!StoreDisk_t::MountPartition: mounting partition "Part00" on store "DSK1:"
    4294770076 PID:400002 TID:1520002 FSDMGR!ParitionDisk::Mount: Partition Type 0x06 --> "FATFS"
    4294770076 PID:400002 TID:1520002 FSDMGR!ParitionDisk::Mount: "FATFS" --> exfat.dll
    4294770077 PID:400002 TID:1520002 OSAXST1: >>> Loading Module 'exfat.dll' (0x9FF3C868) at address 0xC0410000-0xC043D000 in Process 'NK.EXE' (0x82E99C80)
    PB Debugger Loaded symbols for 'C:\WINCE600\OSDESIGNS\SPEC1\RELDIR\AIBED_X86_DEBUG\EXFAT.DLL'
    4294770113 PID:400002 TID:1520002 FSD_MountDisk: Mounting volume for hDsk=D006C3E0
    4294770114 PID:400002 TID:1520002 FATFS!ReadRegistryValues: Registry flags = 0x40
    4294770114 PID:400002 TID:1520002 FATFS!ReadRegistryValues: Force write through disabled
    4294770114 PID:400002 TID:1520002 FATFS!ReadRegistryValues: Automatic formatting disabled
    4294770114 PID:400002 TID:1520002 FATFS!ReadRegistryValues: Transact data disabled
    4294770114 PID:400002 TID:1520002 FATFS!ReadRegistryValues: Security Support disabled
    4294770114 PID:400002 TID:1520002 FATFS!ScanVolume: Beginning Scan
    4294770115 PID:400002 TID:1520002 OSAXST1: >>> Loading Module 'k.fatutil.dll' (0x9FF3CE20) at address 0xC0450000-0xC0468000 in Process 'NK.EXE' (0x82E99C80)
    PB Debugger Loaded symbols for 'C:\WINCE600\OSDESIGNS\SPEC1\RELDIR\AIBED_X86_DEBUG\K.FATUTIL.DLL'
    4294771244 PID:400002 TID:1520002 OSAXST1: <<< Unloading Module 'k.fatutil.dll' (0x9FF3CE20) at address 0xC0450000-0xC0468000 in Process 'NK.EXE' (0x82E99C80)
    PB Debugger Unloaded symbols for 'C:\WINCE600\OSDESIGNS\SPEC1\RELDIR\AIBED_X86_DEBUG\K.FATUTIL.DLL'
    4294771255 PID:400002 TID:1520002 OSAXST1: >>> Loading Module 'diskcache.dll' (0x9FF255B8) at address 0xC0440000-0xC0447000 in Process 'NK.EXE' (0x82E99C80)
    PB Debugger Loaded symbols for 'C:\WINCE600\OSDESIGNS\SPEC1\RELDIR\AIBED_X86_DEBUG\DISKCACHE.DLL'
    4294771296 PID:400002 TID:1520002 CreateCache: Successful.  Cache Size: 122 KB, Start: 1, End: 490, CreateFlags: 0.
    4294771297 PID:400002 TID:1520002 CreateCache: Successful.  Cache Size: 245 KB, Start: 491, End: 2001824, CreateFlags: 0.
    

    Finally, I checked my root directory and saw there a FILE0001.CHK file that contained the initial data cluster of the F2 file I previously messed, along with F1 and a new F2 being a copy of F1.

    So it seems that DisableAutoScan=0 does its job, which is a good thing. The bad thing is that there is no mean to see whether an error has been fixed or not, except by searching for .CHK files.

    Regards.


    Remi

    Monday, January 11, 2016 10:42 AM
  • Hi Remi,

    1. So it seems that DisableAutoScan=0 does its job, which is a good thing.

    2. The bad thing is that there is no mean to see whether an error has been fixed or not, except by searching for .CHK files.

    Why is #2 a bad thing?  If you care you can check, if you don't then there is no extra overhead.

    Sincerely,

    IoTGirl

    Monday, January 11, 2016 5:35 PM
    Moderator
  • Hi IoTGirl,

    IMHO, #2 is at least 'not such a good thing' because:

      a. We don't have any control on what was actually fixed.

      b. Detailed results of the ScanVolumeEx are lost.

      c. I am not completely sure but I think some errors will not generate .chk files.

    So OK: this is mostly a matter of control (and I am a control freak ;-) and the overall DisableAutoScan=0 looks quite efficient, so I will mark this thread as done.

    Best Regards.


    Remi

    Monday, January 11, 2016 5:57 PM
  • Hi Remi,

    I totally understand the wish to control everything. I am a Software Developer / Device Builder as well.

    Sincerely,

    IoTGirl 

    Monday, January 11, 2016 6:13 PM
    Moderator