Skip to content

Latest commit

 

History

History
85 lines (64 loc) · 3.04 KB

nf-winbase-isbadcodeptr.md

File metadata and controls

85 lines (64 loc) · 3.04 KB
UID title description helpviewer_keywords old-location tech.root ms.assetid ms.date ms.keywords req.header req.include-header req.target-type req.target-min-winverclnt req.target-min-winversvr req.kmdf-ver req.umdf-ver req.ddi-compliance req.unicode-ansi req.idl req.max-support req.namespace req.assembly req.type-library req.lib req.dll req.irql targetos req.typenames req.redist ms.custom f1_keywords dev_langs topic_type api_type api_location api_name
NF:winbase.IsBadCodePtr
IsBadCodePtr function (winbase.h)
Determines whether the calling process has read access to the memory at the specified address.
IsBadCodePtr
IsBadCodePtr function
_win32_isbadcodeptr
base.isbadcodeptr
winbase/IsBadCodePtr
base\isbadcodeptr.htm
base
001b8972-6a7f-4964-af8d-a6f31ea3a525
12/05/2018
IsBadCodePtr, IsBadCodePtr function, _win32_isbadcodeptr, base.isbadcodeptr, winbase/IsBadCodePtr
winbase.h
Windows.h
Windows
Windows XP [desktop apps only]
Windows Server 2003 [desktop apps only]
Kernel32.lib
Kernel32.dll
Windows
19H1
IsBadCodePtr
winbase/IsBadCodePtr
c++
APIRef
kbSyntax
DllExport
Kernel32.dll
IsBadCodePtr

IsBadCodePtr function

-description

Determines whether the calling process has read access to the memory at the specified address.

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.
 

-parameters

-param lpfn [in]

A pointer to a memory address.

-returns

If the calling process has read access to the specified memory, the return value is zero.

If the calling process does not have read access to the specified memory, the return value is nonzero. To get extended error information, call GetLastError.

If the application is compiled as a debugging version, and the process does not have read access to the specified memory location, 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

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.

-see-also

IsBadReadPtr

IsBadStringPtr

IsBadWritePtr