none
An annoing DEBUGCHK at boot (WEC7, ARMv6) RRS feed

  • Question

  • Just like the subject says, DEBUGCHK in FSDMGR_FindFirstFileW() on every boot due to (what looks like) BCrypt component bug calling FindFirstFile() with invalid structure or size. I wonder if everyone else getting this DEBUGCHK as well. Any ideas what could be wrong?

    The debug check happens in \WINCE700\private\winceos\COREOS\storage\fsdmgr\volumeapi.cpp

    EXTERN_C HANDLE FSDMGR_FindFirstFileW (MountedVolume_t* pVolume, HANDLE hProcess,
        const WCHAR* pPathName, WIN32_FIND_DATAW* pFindData, DWORD SizeOfFindData)
    {      
    #ifdef UNDER_CE
        if (sizeof (WIN32_FIND_DATAW) != SizeOfFindData) {
            DEBUGCHK (0); // AFS_FindFirstFileW_Trap macro was called directly w/out proper size. <<<<<<<<<<<<<<<<<<<
            SetLastError (ERROR_INVALID_PARAMETER);
            return INVALID_HANDLE_VALUE;
        }
    #endif
    ...


    Heres what the call stack looks like:


    FSDMGR!FSDMGR_FindFirstFileW(MountedVolume_t * 0xc4830e60, void * 0x00400002, const wchar_t * 0xc48349c0, _WIN32_FIND_DATAW * 0xc490ec90, unsigned long 0x00000630)  line 402 + 40 bytes
    KERNEL!MDCallKernelHAPI + 60 bytes
    KERNEL!NKHandleCall(unsigned long 0x00000001, _DHCALL_STRUCT * 0x0000049b)  line 2499 + 40 bytes
    K.COREDLL!DirectHandleCall(unsigned long 0x00000010)  line 94 + 20 bytes
    K.COREDLL!xxx_AFS_FindFirstFileW(void * 0x0108000b, void * 0x00400002, const wchar_t * 0xc48349c0, _WIN32_FIND_DATAW * 0xc490ec90, unsigned long 0x00000630)  line 182 + 60 bytes
    FSDMGR!InternalFindFirstFileW(const wchar_t * 0x00000630, void * 0xffffffff, _WIN32_FIND_DATAW * 0x0108000b, unsigned long 0x00000000)  line 766 + 28 bytes
    FSDMGR!FSINT_FindFirstFileW(const wchar_t * 0xc490e9fc, _WIN32_FIND_DATAW * 0xc490ec90, unsigned long 0x00000630)  line 781 + 20 bytes
    K.COREDLL!FindFirstDevice(DeviceSearchType DeviceSearchByLegacyName, const void * 0xc4830a62, _DevmgrDeviceInformation_tag * 0xc490ec90)  line 291 + 32 bytes
    FSDMGR!TranslateLegacyDeviceName(const wchar_t * 0xc4830a62, wchar_t * 0xc48343a0, unsigned int 0x00000104)  line 51 + 24 bytes
    FSDMGR!SafeGetCanonicalPathW(const wchar_t * 0x00000000, unsigned int * 0xc4830a60)  line 124 + 16 bytes
    FSDMGR!InternalCreateFileW(const wchar_t * 0xc490f704, void * 0x00000001, unsigned long 0x00000000, unsigned long 0xc490f5b0, _SECURITY_ATTRIBUTES * 0xc490f564, unsigned long 0xcca42f14, unsigned long 0xcca441b4, void * 0x6000011f)  line 816 + 12 bytes
    FSDMGR!FSINT_CreateFileW(const wchar_t * 0xcca22048, unsigned long 0x00000000, unsigned long 0x00000000, _SECURITY_ATTRIBUTES * 0x00000000, unsigned long 0x00000003, unsigned long 0x00000080, void * 0x00000000)  line 1044 + 52 bytes
    K.COREDLL!xxx_CreateFileW(const wchar_t * 0xcca22048, unsigned long 0x00000000, unsigned long 0x00000000, _SECURITY_ATTRIBUTES * 0x00000000, unsigned long 0x00000003, unsigned long 0x00000080, void * 0x00000000)  line 88 + 60 bytes
    BCRYPT!_IoOpenDevice()  line 3157 + 44 bytes
    BCRYPT!IoCallKernelDriver(unsigned long 0xc490f538, unsigned char * 0x00000000, unsigned long 0x00020000, unsigned char * 0x00000000, unsigned long * 0xc490f538)  line 3246 + 4 bytes
    BCRYPT!IoCallKernelDriverQueryLoop(unsigned long 0xc490f704, unsigned char * 0xc490f57c, unsigned long 0x00000000, unsigned char * * 0xc490f588, unsigned long * 0xc490f704, int * 0xc490f57c)  line 3427 + 24 bytes
    BCRYPT!BCryptResolveProviders(const wchar_t * 0x00000001, unsigned long 0x00000000, const wchar_t * 0xc490f704, const wchar_t * 0xc490f700, unsigned long 0x00000001, unsigned long 0x00000000, unsigned long * 0xc490f704, _CRYPT_PROVIDER_REFS * * 0xc490f700)  line 2561 + 32 bytes
    BCRYPT!BCryptOpenAlgorithmProvider(void * * 0xc4860830, const wchar_t * 0xefccbd0c, const wchar_t * 0x00004444, unsigned long 0xc490f964)  line 530 + 48 bytes
    FILESYS!BCryptOpenAlgorithmProvider(void * * 0xc4860844, const wchar_t * 0xefc7aa18, const wchar_t * 0x00000000, unsigned long 0x00000000)  line 29 + 80 bytes
    FILESYS!CryptCNG::CryptCNG()  line 485 + 24 bytes
    FILESYS!CryptSelector::InitCapi()  line 797 + 40 bytes
    FILESYS!CryptSelector::Select(DPAPIAlgID DPAPI_AES, DPAPIAlgID DPAPI_SHA256)  line 769
    FILESYS!CryptSelector::Select(DPAPIAlgID DPAPI_AES)  line 752 + 20 bytes
    FILESYS!CryptSelector::Select()  line 742 + 16 bytes
    FILESYS!dpapi_init()  line 1430
    FILESYS!DoGeneralInit(unsigned short * 0x00000000)  line 2147
    FILESYS!FileSysMain(HINSTANCE__ * 0x00000000)  line 2612 + 8 bytes
    K.COREDLL!ThreadBaseFunc(unsigned long (void *)* 0xefc9beb0, void * 0xc0802edc)  line 1239 + 12 bytes
    00000004()

    Friday, June 24, 2011 5:40 PM

Answers

  •  It seems, you may ignore it.

    Our customer are on WEC7 since Jan'11 and we (as a BSP developer) haven't any claims about registry' malfunction.

     

    Tuesday, June 28, 2011 10:01 AM

All replies

  • Hi!

      I've seen the same within CEPC project. It's caused by using RAM-Based Registry, although Hive-Based works fine.

    MS guys couldn't say why it happens.

    Monday, June 27, 2011 7:04 AM
  • Yep, I'm on RAM based registry. Do you think it is something dangerous or can be safely ignored? I don't use encryption anywhere, it seems to come as a dependence of Standard Grpahics Shell for whatever (?) reason.  
    Monday, June 27, 2011 3:22 PM
  •  It seems, you may ignore it.

    Our customer are on WEC7 since Jan'11 and we (as a BSP developer) haven't any claims about registry' malfunction.

     

    Tuesday, June 28, 2011 10:01 AM
  • OK, thank you.
    Tuesday, June 28, 2011 10:10 AM