BOOLEAN MmIsAddressValid( _In_ PVOID VirtualAddress );
Parameters
- VirtualAddress [in]
- A pointer to the nonpaged virtual address to check. The caller must ensure that this
- address cannot be paged out or deleted for the duration of this call. Even after the return from the call, you must not page out or delete this address. If you do page out or delete this address, the return value might be unreliable. Paging out or deleting this address might cause the computer to stop responding (that is, crash).
Return value
If no page fault would occur from reading or writing at the given virtual address, MmIsAddressValid returns TRUE.
Remarks
Even if MmIsAddressValid returns TRUE, accessing the address can cause page faults unless the memory has been locked down or the address is a valid nonpaged pool address.
—————————————————————————————–
R3:
—————————————————————————————–
BOOL WINAPI IsBadReadPtr( _In_ const VOID *lp, _In_ UINT_PTR ucb );
Parameters
- lp [in]
- A pointer to the first byte of the memory block.
- ucb [in]
- The size of the memory block, in bytes. If this parameter is zero, the return value is zero.
Return value
If the calling process has read access to all bytes in the specified memory range, the return value is zero.
If the calling process does not have read access to all bytes in the specified memory range, the return value is nonzero.
If the application is compiled as a debugging version, and the process does not have read access to all bytes in the specified memory range, the function causes an assertion and breaks into the debugger. Leaving the debugger, the function continues as usual, and returns a nonzero value. This behavior is by design, as a debugging aid.
Remarks
This function is typically used when working with pointers returned from third-party libraries, where you cannot determine the memory management behavior in the third-party DLL.
Threads in a process are expected to cooperate in such a way that one will not free memory that the other needs. Use of this function does not negate the need to do this. If this is not done, the application may fail in an unpredictable manner.
Dereferencing potentially invalid pointers can disable stack expansion in other threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information.
If the calling process has read access to some, but not all, of the bytes in the specified memory range, the return value is nonzero.
In a preemptive multitasking environment, it is possible for some other thread to change the process’s access to the memory being tested. Even when the function indicates that the process has read access to the specified memory, you should use structured exception handling when attempting to access the memory. Use of structured exception handling enables the system to notify the process if an access violation exception occurs, giving the process an opportunity to handle the exception.
—————————————————————————————–
IsBadWritePtr function
Verifies that the calling process has write access to the specified range of memory.
Important This function is obsolete and should not be used. Despite its name, it does not guarantee that the pointer is valid or that the memory pointed to is safe to use. For more information, see Remarks on this page.
Syntax
BOOL WINAPI IsBadWritePtr( _In_ LPVOID lp, _In_ UINT_PTR ucb );
Parameters
- lp [in]
- A pointer to the first byte of the memory block.
- ucb [in]
- The size of the memory block, in bytes. If this parameter is zero, the return value is zero.
Return value
If the calling process has write access to all bytes in the specified memory range, the return value is zero.
If the calling process does not have write access to all bytes in the specified memory range, the return value is nonzero.
If the application is run under a debugger and the process does not have write access to all bytes in the specified memory range, the function causes a first chance STATUS_ACCESS_VIOLATION exception. The debugger can be configured to break for this condition. After resuming process execution in the debugger, the function continues as usual and returns a nonzero value This behavior is by design and serves as a debugging aid.
Remarks
This function is typically used when working with pointers returned from third-party libraries, where you cannot determine the memory management behavior in the third-party DLL.
Threads in a process are expected to cooperate in such a way that one will not free memory that the other needs. Use of this function does not negate the need to do this. If this is not done, the application may fail in an unpredictable manner.
Dereferencing potentially invalid pointers can disable stack expansion in other threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information.
If the calling process has write access to some, but not all, of the bytes in the specified memory range, the return value is nonzero.
In a preemptive multitasking environment, it is possible for some other thread to change the process’s access to the memory being tested. Even when the function indicates that the process has write access to the specified memory, you should use structured exception handling when attempting to access the memory. Use of structured exception handling enables the system to notify the process if an access violation exception occurs, giving the process an opportunity to handle the exception.
IsBadWritePtr is not multithread safe. To use it properly on a pointer shared by multiple threads, call it inside a critical region of code that allows only one thread to access the memory being checked. Use operating system–level objects such as critical sections or mutexes or the interlocked functions to create the critical region of code.
