Creates or opens a named or unnamed file mapping object for a specified file.
To specify the NUMA node for the physical memory, see CreateFileMappingNuma.
Syntax
|
HANDLE WINAPI CreateFileMapping(
__in HANDLE hFile,
__in_opt LPSECURITY_ATTRIBUTES lpAttributes,
__in DWORD flProtect,
__in DWORD dwMaximumSizeHigh,
__in DWORD dwMaximumSizeLow,
__in_opt LPCTSTR lpName
);
|
Parameters
- hFile [in]
-
A handle to the file from which to create a file mapping object.
The file must be opened with access rights
that are compatible with the protection flags that the flProtect parameter specifies. It is not required, but it is
recommended that files you intend to map be opened for exclusive access. For more
information, see File Security and Access
Rights.
If hFile is INVALID_HANDLE_VALUE, the calling process must
also specify a size for the file mapping object in the dwMaximumSizeHigh and
dwMaximumSizeLow parameters. In this scenario,
CreateFileMapping creates a file mapping object
of a specified size that is backed by the system paging file instead of by a file in the file
system.
- lpAttributes [in, optional]
-
A pointer to a SECURITY_ATTRIBUTES structure
that determines whether a returned handle can be inherited by child processes.
If
lpAttributes is NULL, the handle cannot be inherited.
The lpSecurityDescriptor member of this structure specifies a security descriptor
for a new file mapping object. If lpAttributes is NULL, the file mapping object
gets a default security descriptor. The access control lists (ACL) in the default security descriptor for a file mapping object come
from the primary or impersonation token of the creator. For more information, see File Mapping Security and Access Rights.
- flProtect [in]
-
Specifies the page protection of the file mapping object. All mapped views of the object must be compatible with this protection.
This parameter can be one of the following values.
| Value | Meaning |
|
PAGE_READONLY
| Allows views to be mapped for read-only or copy-on-write access.
The file handle that the hFile parameter
specifies must be created with the GENERIC_READ access right.
|
|
PAGE_READWRITE
| Allows views to be mapped for read-only, copy-on-write, or read/write access.
The file handle that the hFile parameter specifies must be created with the GENERIC_READ and
GENERIC_WRITE access rights.
|
|
PAGE_WRITECOPY
| Allows views to be mapped for read-only or copy-on-write access. This value is equivalent to PAGE_READONLY.
The file handle that the
hFile parameter specifies must be created with the
GENERIC_READ access right.
|
|
PAGE_EXECUTE_READ
| Allows views to be mapped for read-only, copy-on-write, or execute access.
The file handle specified by the hFile parameter must be created with the GENERIC_READ and GENERIC_EXECUTE access rights.
Windows Server 2003 and Windows XP: This value is not available until Windows XP SP2 and Windows Server 2003 SP1.
Windows 2000: This value is not supported.
|
|
PAGE_EXECUTE_READWRITE
| Allows views to be mapped for read-only, copy-on-write, read/write, or execute access.
The file handle that the hFile parameter specifies must be created with the GENERIC_READ, GENERIC_WRITE, and GENERIC_EXECUTE access rights.
Windows Server 2003 and Windows XP: This value is not available until Windows XP SP2 and Windows Server 2003 SP1.
Windows 2000: This value is not supported.
|
|
PAGE_EXECUTE_WRITECOPY
| Allows views to be mapped for read-only, copy-on-write, or execute access. This value is equivalent to PAGE_EXECUTE_READ.
The file handle that the hFile parameter specifies must be created with the GENERIC_READ and GENERIC_EXECUTE access rights.
Windows Server 2003 and Windows XP/2000: This value is not supported.
Windows Vista: This value is not available until Windows Vista SP1.
|
An application can specify one or more of the following attributes for the file mapping object by combining them with one of the preceding page protection values.
| Value | Meaning |
|
SEC_COMMIT
| If the file mapping object is backed by the operating system paging file (the hfile parameter is INVALID_HANDLE_VALUE), specifies that when a view of the file is mapped into a process address space, the entire range of pages is committed rather than reserved. The system must have enough committable pages to hold the entire mapping. Otherwise, CreateFileMapping fails.
This attribute has no effect for file mapping objects that are backed by executable image files or data files (the hfile parameter is a handle to a file).
SEC_COMMIT cannot be combined with SEC_RESERVE.
If no attribute is specified, SEC_COMMIT is assumed.
|
|
SEC_IMAGE
| Specifies that the file that the hFile parameter specifies is an executable image file.
Because the mapping information
and file protection are taken from the image file, no other attributes are valid with
SEC_IMAGE.
|
|
SEC_LARGE_PAGES
| Enables large pages to be used for file mapping objects that are backed by the operating system paging file (the hfile parameter is INVALID_HANDLE_VALUE). This attribute is not supported for file mapping objects that are backed by executable image files or data files (the hFile parameter is a handle to an executable image or data file).
The maximum size of the file mapping object must be a multiple of the minimum size of a large page returned by the GetLargePageMinimum function. If it is not, CreateFileMapping fails. When mapping a view of a file mapping object created with SEC_LARGE_PAGES, the base address and view size must also be multiples of the minimum large page size.
SEC_LARGE_PAGES requires the SeLockMemoryPrivilege privilege to be enabled in the caller's token.
If SEC_LARGE_PAGES is specified, SEC_COMMIT must also be specified.
Windows Server 2003: This value is not supported until Windows Server 2003 SP1.
Windows XP/2000: This value is not supported.
|
|
SEC_NOCACHE
| Sets all pages to be non-cachable.
Applications should not use this attribute except when
explicitly required for a device. Using the interlocked functions with memory that is mapped with
SEC_NOCACHE can result in an
EXCEPTION_ILLEGAL_INSTRUCTION exception.
SEC_NOCACHE requires either the SEC_RESERVE or
SEC_COMMIT attribute to be set.
|
|
SEC_RESERVE
|
If the file mapping object is backed by the operating system paging file (the hfile parameter is INVALID_HANDLE_VALUE), specifies that when a view of the file is mapped into a process address space, the entire range of pages is reserved for later use by the process rather than committed.
Reserved pages can be committed in subsequent
calls to the VirtualAlloc function. After the pages are committed, they cannot be freed or decommitted with the VirtualFree function.
This attribute has no effect for file mapping objects that are backed by executable image files or data files (the hfile parameter is a handle to a file).
SEC_RESERVE cannot be combined with SEC_COMMIT.
|
|
SEC_WRITECOMBINE
| Sets all pages to be write-combined.
Applications should not use this attribute except when
explicitly required for a device. Using the interlocked functions with memory that is mapped with
SEC_WRITECOMBINE can result in an
EXCEPTION_ILLEGAL_INSTRUCTION exception.
SEC_WRITECOMBINE requires either the SEC_RESERVE or
SEC_COMMIT attribute to be set.
|
- dwMaximumSizeHigh [in]
-
The high-order DWORD of the maximum size of the file mapping object.
- dwMaximumSizeLow [in]
-
The low-order DWORD of the maximum size of the file mapping object.
If this parameter
and dwMaximumSizeHigh are 0 (zero), the maximum size of the file mapping object is equal
to the current size of the file that hFile identifies.
An attempt to map a file with a length of 0 (zero) fails with an error code of
ERROR_FILE_INVALID. Applications should test for files with a length of 0 (zero) and
reject those files.
- lpName [in, optional]
-
The name of the file mapping object.
If this parameter matches the name of an existing mapping object, the function requests access to the
object with the protection that flProtect specifies.
If this parameter is NULL, the file mapping object is created without a name.
If lpName matches the name of an existing event, semaphore, mutex, waitable timer, or
job object, the function fails, and the GetLastError
function returns ERROR_INVALID_HANDLE. This occurs because these objects share the
same namespace.
Terminal Services:
The name can have a "Global\" or "Local\" prefix to explicitly create the object in the global or session
namespace. The remainder of the name can contain any character except the backslash character (\). Creating a file mapping object in the global namespace from a session other than session zero requires the
SeCreateGlobalPrivilege
privilege. For more
information, see
Kernel Object Namespaces.
Windows XP:
Fast user switching is implemented by using Terminal Services sessions. The first user to log on uses session
0 (zero), the next user to log on uses session 1 (one), and so on. Kernel object names must follow the guidelines that are outlined
for Terminal Services so that applications can support multiple users.
Windows 2000:
If Terminal Services is not running, the "Global\" and "Local\" prefixes are ignored. The remainder of the
name can contain any character except the backslash character.
Return Value
If the function succeeds, the return value is a handle to the newly created file mapping object.
If the object exists
before the function call, the function returns a handle to the existing object (with its current size, not the
specified size), and GetLastError
returns ERROR_ALREADY_EXISTS.
If the function fails, the return value is NULL. To get extended error information, call
GetLastError.
Remarks
After a file mapping object is created, the size of the file must not exceed the size of the file mapping
object; if it does, not all of the file contents are available for sharing.
If an application specifies a size for the file mapping object that is larger than the size of the actual named
file on disk and if the page protection allows write access (that is, the flProtect parameter specifies PAGE_READWRITE or PAGE_EXECUTE_READWRITE), then the file on disk is increased to match the specified size of the file mapping object. If the file is extended, the contents of the file between the old end of the file and the new end of the file are not guaranteed to be zero; the behavior is defined by the file system. If the file
on disk cannot be increased, CreateFileMapping fails and
GetLastError returns
ERROR_DISK_FULL.
The
initial contents of the pages in a file mapping object backed by the operating system paging file are 0 (zero).
The handle that CreateFileMapping returns has full
access to a new file mapping object, and can be used with any function that requires a handle to a file mapping
object.
Multiple processes can share a view of the same file by either using a single shared file mapping object or creating separate file mapping objects backed by the same file. A single file mapping object can be shared by multiple processes through inheriting the handle at process creation, duplicating the handle, or opening the file mapping object by name. For more information, see the CreateProcess,
DuplicateHandle and OpenFileMapping functions.
Creating a file mapping object does not actually map the view into a process address space.
The MapViewOfFile and
MapViewOfFileEx functions map a view of a file into a
process address space.
With one important exception, file views derived from any file mapping object that is backed by the same file are coherent or identical
at a specific time. Coherency is guaranteed for views within a process and for views that are mapped by different processes.
The exception is related to remote files. Although CreateFileMapping works with
remote files, it does not keep them coherent. For example, if two computers both map a file as writable, and both
change the same page, each computer only sees its own writes to the page. When the data gets updated on the
disk, it is not merged.
A mapped file and a file that is accessed by using the input and output (I/O) functions
(ReadFile and
WriteFile) are not necessarily coherent.
Mapped views of
a file mapping object maintain internal references to the object, and a file mapping object does not close
until all references to it are released. Therefore, to fully close a file mapping object, an application must unmap all mapped views of the file mapping object by
calling UnmapViewOfFile and close the file mapping
object handle by calling CloseHandle. These functions can be called in any order.
Creating a file mapping object in the global namespace from a session other than
session zero requires the SeCreateGlobalPrivilege
privilege. Note that this privilege check is limited to the
creation of file mapping objects and does not apply to opening existing ones. For example, if a service or the
system creates a file mapping object in the global namespace, any process running in any session can access that file mapping object
provided that the caller has the required access rights.
Windows XP/2000: The requirement described in the previous paragraph was introduced with Windows Server 2003, Windows XP SP2 and
Windows 2000 Server Service Pack 4 (SP4)
Use structured exception handling to protect any code that writes to or
reads from a file view. For more information, see
Reading and Writing From a File View.
To have a mapping with executable permissions, an application must call
CreateFileMapping with either PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_READ,
and then call MapViewOfFile with FILE_MAP_EXECUTE | FILE_MAP_WRITE or FILE_MAP_EXECUTE | FILE_MAP_READ.
Examples
For an example, see Creating Named Shared Memory or Creating a File Mapping Using Large Pages.
Requirements
| Client | Requires Windows Vista, Windows XP, or Windows 2000 Professional. |
| Server | Requires Windows Server 2008, Windows Server 2003, or Windows 2000 Server. |
|---|
| Header | Declared in Winbase.h; include Windows.h. |
| Library | Use Kernel32.lib. |
| DLL | Requires Kernel32.dll. |
| Unicode/ANSI | Implemented as CreateFileMappingW (Unicode) and CreateFileMappingA (ANSI). |
See Also
CloseHandle
CreateFileMappingNuma
Creating a File Mapping Object
DuplicateHandle
File Mapping Functions
MapViewOfFile
MapViewOfFileEx
OpenFileMapping
ReadFile
SECURITY_ATTRIBUTES
UnmapViewOfFile
VirtualAlloc
WriteFile
Send comments about this topic to Microsoft
Build date: 10/9/2008