locked
VirtualAllocateEx call failing RRS feed

  • Question

  • So i'm having a hard time figuring out what is wrong with my VirtualAllocateEx call, I'm trying to map our boot address of 0, to a virtual address so we can access a nor chip directly on the pxa270 platform.

    //snippet from oemaddrtab_cfg.inc
    
    DCD     0x9A600000, 0x00000000, 64       ; AHURA: nCS0: Boot Flash (64MB).

    There's a whole layer on top of this making it easy to map out hardware ranges, but this is where our virtual alloc gets called.

    // snippet from our code
    
    	// Do the actual mapping
    	HANDLE hCaller = ::OpenProcess(PROCESS_VM_OPERATION, FALSE, dwProcessId);
    	if(0 == hCaller)
    		return false;
    	HANDLE hKernel = ::OpenProcess(PROCESS_VM_OPERATION, FALSE, GetCurrentProcessId());
    	if(0 == hKernel)
    	{
    		::CloseHandle(hCaller);
    		return NULL;
    	}
    	
    	// Allocate a range of addresses in the user's process and map our kernel
    	// range to the user range.
    	m_pVA = ::VirtualAllocCopyEx(hKernel, hCaller, pKernelMapping->m_p, 
    						pKernelMapping->m_dwSize, PAGE_NOCACHE | PAGE_READWRITE);

    when using address of 0, it returns the address thats in the .inc file 

    0x9A600000

    It fails at this debugcheck somewhere down in the depths of the kernel

    static BOOL PageInOnePage (LPDWORD pdwEntry, LPVOID pEnumData)
    {
        PPagingEnumStruct ppe = (PPagingEnumStruct) pEnumData;
        DWORD dwEntry = *pdwEntry;
        BOOL fRet = IsPageWritable (dwEntry)                     // the page is writable
               || (!ppe->fWrite && IsPageReadable (dwEntry));    // or we're requesting read, and the page is readable
    
        if (!fRet
            && !VMProcessPageFault (ppe->pprc, ppe->dwAddr, ppe->fWrite)) {
            DEBUGMSG (ZONE_VIRTMEM, (L"Paging in %8.8lx for process %8.8lx failed\r\n", ppe->dwAddr, ppe->pprc));
            return FALSE;
        }
        // is dead here??? not sure what IsPageCommitted is for
        DEBUGCHK (IsPageCommitted (*pdwEntry));
    
        ppe->dwAddr += VM_PAGE_SIZE;
    
        // update pfn array if requested
        if (ppe->pPFNs) {
            ppe->pPFNs[0] = PFNfromEntry (*pdwEntry);
            ppe->pPFNs ++;
        }
    
        return TRUE;
    }

    #define VM_PAGE_SIZE            0x1000              // page-size always 4K
    
    #define IsPageCommitted(entry)          ((DWORD) (entry) > VM_PAGE_SIZE)

    I get an access violation when I use the pointer that was returned from our Hw mapping driver, I've gotten to a point where I barely know what I'm looking at so I'm having a hard time understanding why this isn't working.

    Wednesday, April 4, 2012 1:39 PM

Answers

  • we ended up giving up, just did a second merge except instead of taking the trunk and updating the branch we pulled the branch back into trucnk and everything worked out for some reason.
    • Marked as answer by Kevin Chaves Friday, April 13, 2012 8:39 PM
    Friday, April 13, 2012 8:39 PM

All replies

  • I made a small mistake, its not returning the same value as the cached value, and it can read/write from the lower areas, so I'm not mapping out the entire area it think.

    I think the area is being mapped or cached somewhere else, I can read from the nor chip up to 

          if(!m_mBootMap.Map(AHURAPXA27X_BASE_PA_BOOT_FLASH, 0xFFFFFFFF ))// 64mb for nor... 128 for mdoc?
    
          {
    
                Close();
    
                return false;
    
          }
    
          pBootBase = m_mBootMap.GetPtr();
    
          p = (LPBYTE)pBootBase;
    
    
                while(true)
    
                {
    
                      BYTE temp = *p;
    
                      p++;
    
                }
    
                DWORD dwAddressOfDoom = p - pBootBase;
    
    
                dwAddressOfDoom = 0x00010000



    Wednesday, April 4, 2012 2:54 PM
  • Do you have debugger connected?
    If so, it should be easy to tell where is the debugchk failed.
    Assume it is the line you suspect, then you can dump the value of *pdwEntry.
    The IsPageCommitted defined in private\winceos\COREOS\nk\inc\vmarm.h
    • Marked as answer by Kevin Chaves Thursday, April 5, 2012 1:37 AM
    • Unmarked as answer by Kevin Chaves Thursday, April 5, 2012 1:37 AM
    Thursday, April 5, 2012 1:27 AM
  • I know where it hits the debugcheck, I even gave the code snippet where it fails. I don't understand why, or why the address space I'm mapping thows an access violation when I go beyond a 0x00010000 offset.
    Thursday, April 5, 2012 1:39 AM
  • So when the debugchk happend, what is the value of *pdwEntry in kernel?
    Since your mapping starts from PA zero, it may lead to corner case, as PA part is all zero in this case, even the PTE is marked as valid (lower 12 bits in PTE), the value of
    *pdwEntry can still lower than 0x1000.
    So if after examing *pdwEntry, you find it is as expected but with all zero on PA field, then this can be a false alarm.

    Thursday, April 5, 2012 5:48 PM
  • Well i think it is a false alarm, the problem I'm having is the access violation I get when I try to use an offset of 0x10000. IsPageCommitted is the only error I'm getting and its only when I'm in the debugger. Also I can access the nor chip up to 0x10000 so I know mapping zero worked.

    I'm thinking somewhere we cached 0x10000 in the OS because its the deviceinfo partition on our nor chip.

    Friday, April 6, 2012 12:58 PM
  • When you hit the AV what does error message say?
    And a callstack dump should be also handy here.
    Friday, April 6, 2012 3:58 PM
  • I'll have to get back to you on this, this is only happening after a botched merge.  Apparently active sync is broken too, so I'll go through the changes and see if I can find out what changed with memory mapping. In fact there is a lot more wrong with the platform as of right now...
    Friday, April 6, 2012 7:55 PM
  • we ended up giving up, just did a second merge except instead of taking the trunk and updating the branch we pulled the branch back into trucnk and everything worked out for some reason.
    • Marked as answer by Kevin Chaves Friday, April 13, 2012 8:39 PM
    Friday, April 13, 2012 8:39 PM