Trouble with VirtualAlloc
-
I'm using Visual C++ 6 service pack 6 on XP. According to the documentation for that version, Advanced Windows Extentions (AWE) allows users to access physical memory beyond the 2 GB boundary for a process. There is an example in the documentation: http://msdn.microsoft.com/en-us/library/aa366531(VS.85).aspx I've had trouble linking to kernel32.dll to make this work. However, the kernel32.dll(2009) in Windows/system32 has the functions so I used LoadLibrary() to explicitly link to that kernel32.dll. Unfortunately, even on a system with 2.96 GB of RAM, running ONLY the simple example, I cannot get VirtualAlloc() to successfully reserve memory over 1100 MB (it does work at 1100 MB and below). I am using the VirtualAlloc from the 2009 kernel32.dll. ***** typedef LPVOID (WINAPI *LPVIRT)(LPVOID lpAddress,SIZE_T dwSize,DWORD flAllocationType,DWORD flProtect); LPVIRT lpVirt; HMODULE hHandle = LoadLibrary("kernel32.dll"); // Reserve the virtual memory. lpVirt = (LPVIRT)GetProcAddress(hHandle, "VirtualAlloc"); lpMemReserved = (*lpVirt)( NULL,m_uMBytes*0x100000,MEM_RESERVE | MEM_PHYSICAL,PAGE_READWRITE ); if( lpMemReserved == NULL ) { TRACE("Cannot reserve memory.\n"); return; } ***** With 2.96 GB, shouldn't I be able to reserve more than 1100 MB? How can I do it?
-
I'm using Visual C++ 6 service pack 6 on XP. According to the documentation for that version, Advanced Windows Extentions (AWE) allows users to access physical memory beyond the 2 GB boundary for a process. There is an example in the documentation: http://msdn.microsoft.com/en-us/library/aa366531(VS.85).aspx I've had trouble linking to kernel32.dll to make this work. However, the kernel32.dll(2009) in Windows/system32 has the functions so I used LoadLibrary() to explicitly link to that kernel32.dll. Unfortunately, even on a system with 2.96 GB of RAM, running ONLY the simple example, I cannot get VirtualAlloc() to successfully reserve memory over 1100 MB (it does work at 1100 MB and below). I am using the VirtualAlloc from the 2009 kernel32.dll. ***** typedef LPVOID (WINAPI *LPVIRT)(LPVOID lpAddress,SIZE_T dwSize,DWORD flAllocationType,DWORD flProtect); LPVIRT lpVirt; HMODULE hHandle = LoadLibrary("kernel32.dll"); // Reserve the virtual memory. lpVirt = (LPVIRT)GetProcAddress(hHandle, "VirtualAlloc"); lpMemReserved = (*lpVirt)( NULL,m_uMBytes*0x100000,MEM_RESERVE | MEM_PHYSICAL,PAGE_READWRITE ); if( lpMemReserved == NULL ) { TRACE("Cannot reserve memory.\n"); return; } ***** With 2.96 GB, shouldn't I be able to reserve more than 1100 MB? How can I do it?
Hi, 1. please use PRE tags when showing code snippets, as it improves readability. 2. on 32-bit Windows, the user part of the virtual address space is limited to 2GB (per process). There is a way to extend that to 3GB, use Google to locate it. I have the impression you didn't do it, since you didn't mention it at all. On 64-bit Windows, the situation obviously is quite different. 3. within 2GB virtual space, I'm not very surprised you get only some 1.1GB; as your own code and data is in that same 2GB space. I don't know what the default addresses for those would be; a link map should contain all such info. Have a look at the linker switches and ask for a map; then maybe look for more switches if you want to alter the virtual addresses used by code and data. 4. I haven't used MEM_PHYSICAL yet, and haven't read up on all the doc, however I would be concerned it may also imply you are asking for contiguous physical memory (mind you, I'm not sure here). Finding such amount of contiguous memory is pretty unlikely. 5. Maybe you should tell a bit about the overall goals; just maybe there is a better approach for what you are after. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
Hi, 1. please use PRE tags when showing code snippets, as it improves readability. 2. on 32-bit Windows, the user part of the virtual address space is limited to 2GB (per process). There is a way to extend that to 3GB, use Google to locate it. I have the impression you didn't do it, since you didn't mention it at all. On 64-bit Windows, the situation obviously is quite different. 3. within 2GB virtual space, I'm not very surprised you get only some 1.1GB; as your own code and data is in that same 2GB space. I don't know what the default addresses for those would be; a link map should contain all such info. Have a look at the linker switches and ask for a map; then maybe look for more switches if you want to alter the virtual addresses used by code and data. 4. I haven't used MEM_PHYSICAL yet, and haven't read up on all the doc, however I would be concerned it may also imply you are asking for contiguous physical memory (mind you, I'm not sure here). Finding such amount of contiguous memory is pretty unlikely. 5. Maybe you should tell a bit about the overall goals; just maybe there is a better approach for what you are after. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
Thank you very much for your prompt reply. My overall goal is to be able to have my application access memory beyond the 2GB boundary so that it can allocate physical memory beyond the 2GB boundary and I am able to allocate 2 to 3 (maybe more?) GBs of memory. One solution you mentioned (the 3GB extension) is described here: http://msdn.microsoft.com/en-us/library/ms189334(SQL.100).aspx This solution however affects the allocation of memory for every application on the system, and is not something I really want to do. I just want my particular application to be able to allocate beyond the boundary. Note that the link above mentions AWE, which I am trying to use. Note that the diagram shows the that memory allocated in physical memory is not contiguous, which addresses your concern. The link posted in my first post is the code I am using to use AWE. As I mentioned, the only difference is that I'm using LoadLibrary to access the allocation and mapping functions. This link discusses AWE in more detail: http://msdn.microsoft.com/en-us/library/aa366527(VS.85).aspx Included in description for the AWE functions in the documentation is the following: "Physical pages can reside at any physical address. You should make no assumptions about the contiguity of the physical pages." So the hitch at this point to making this work is VirtualAlloc(). The previous function in the example, "AllocateUserPhysicalPages()" works fine.
-
Thank you very much for your prompt reply. My overall goal is to be able to have my application access memory beyond the 2GB boundary so that it can allocate physical memory beyond the 2GB boundary and I am able to allocate 2 to 3 (maybe more?) GBs of memory. One solution you mentioned (the 3GB extension) is described here: http://msdn.microsoft.com/en-us/library/ms189334(SQL.100).aspx This solution however affects the allocation of memory for every application on the system, and is not something I really want to do. I just want my particular application to be able to allocate beyond the boundary. Note that the link above mentions AWE, which I am trying to use. Note that the diagram shows the that memory allocated in physical memory is not contiguous, which addresses your concern. The link posted in my first post is the code I am using to use AWE. As I mentioned, the only difference is that I'm using LoadLibrary to access the allocation and mapping functions. This link discusses AWE in more detail: http://msdn.microsoft.com/en-us/library/aa366527(VS.85).aspx Included in description for the AWE functions in the documentation is the following: "Physical pages can reside at any physical address. You should make no assumptions about the contiguity of the physical pages." So the hitch at this point to making this work is VirtualAlloc(). The previous function in the example, "AllocateUserPhysicalPages()" works fine.
OK, I haven't thought this through yet, however I have one more suggestion: put your code in a loop, i.e. try allocating the largest you can get, display the size (and address), do not release it, and repeat this all over and over and over. You might be getting a number of probably decreasing chunks, and the sum of those sizes (and maybe addresses) could tell you something interesting. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
I'm using Visual C++ 6 service pack 6 on XP. According to the documentation for that version, Advanced Windows Extentions (AWE) allows users to access physical memory beyond the 2 GB boundary for a process. There is an example in the documentation: http://msdn.microsoft.com/en-us/library/aa366531(VS.85).aspx I've had trouble linking to kernel32.dll to make this work. However, the kernel32.dll(2009) in Windows/system32 has the functions so I used LoadLibrary() to explicitly link to that kernel32.dll. Unfortunately, even on a system with 2.96 GB of RAM, running ONLY the simple example, I cannot get VirtualAlloc() to successfully reserve memory over 1100 MB (it does work at 1100 MB and below). I am using the VirtualAlloc from the 2009 kernel32.dll. ***** typedef LPVOID (WINAPI *LPVIRT)(LPVOID lpAddress,SIZE_T dwSize,DWORD flAllocationType,DWORD flProtect); LPVIRT lpVirt; HMODULE hHandle = LoadLibrary("kernel32.dll"); // Reserve the virtual memory. lpVirt = (LPVIRT)GetProcAddress(hHandle, "VirtualAlloc"); lpMemReserved = (*lpVirt)( NULL,m_uMBytes*0x100000,MEM_RESERVE | MEM_PHYSICAL,PAGE_READWRITE ); if( lpMemReserved == NULL ) { TRACE("Cannot reserve memory.\n"); return; } ***** With 2.96 GB, shouldn't I be able to reserve more than 1100 MB? How can I do it?
VirtualAllocnever allocate over 2GB in 32bit windows without /3GB option. In some ordinary OS settings situation,VirtualAllocusually returns under 1.5GB space for user land memory. AndAWEis for use of physical memory over physical 2GB boundary with /pae boot option. If you want continuous virtual memory space over 2GB, you must use 64bit windows. With /pae boot option, msdn document saysVirtualAlloccan use over 4GB physical memory, but it would not so ordinary 32bit windows especially xp. Because microsoft dose not support over 4GB physical memory on 32bit xp. -
I'm using Visual C++ 6 service pack 6 on XP. According to the documentation for that version, Advanced Windows Extentions (AWE) allows users to access physical memory beyond the 2 GB boundary for a process. There is an example in the documentation: http://msdn.microsoft.com/en-us/library/aa366531(VS.85).aspx I've had trouble linking to kernel32.dll to make this work. However, the kernel32.dll(2009) in Windows/system32 has the functions so I used LoadLibrary() to explicitly link to that kernel32.dll. Unfortunately, even on a system with 2.96 GB of RAM, running ONLY the simple example, I cannot get VirtualAlloc() to successfully reserve memory over 1100 MB (it does work at 1100 MB and below). I am using the VirtualAlloc from the 2009 kernel32.dll. ***** typedef LPVOID (WINAPI *LPVIRT)(LPVOID lpAddress,SIZE_T dwSize,DWORD flAllocationType,DWORD flProtect); LPVIRT lpVirt; HMODULE hHandle = LoadLibrary("kernel32.dll"); // Reserve the virtual memory. lpVirt = (LPVIRT)GetProcAddress(hHandle, "VirtualAlloc"); lpMemReserved = (*lpVirt)( NULL,m_uMBytes*0x100000,MEM_RESERVE | MEM_PHYSICAL,PAGE_READWRITE ); if( lpMemReserved == NULL ) { TRACE("Cannot reserve memory.\n"); return; } ***** With 2.96 GB, shouldn't I be able to reserve more than 1100 MB? How can I do it?
You're not allocating memory with that call to VirtualAlloc, you're allocating address space. There's only 2Gb of that per application [1] so the fact that you can't allocate more than ~1Gb in one fell swoop isn't surprising. To be honest if you really need oodles of contiguous memory (i.e. more than 1Gb) then using a 32 bit OS is probably the wrong way to go - try a 64 bit OS and compiler then you won't have to muck around with low level stuff like this. Cheers, Ash [1] Pedants please note the following exclusions: address space available to user mode code, Win32 only without /3Gb switch in boot.ini