ExceptionRecord = pointers->ExceptionRecord;
Context = pointers->ContextRecord;
// a) The “ExceptionCode” field is set to
STATUS_GUARD_PAGE_VIOLATION 0x80000001.
// b) The “NumberParameters” field is greater than or equal to 2.
// c) The “ExceptionInformation[0]” field is set to 8.
// d) The “ExceptionInformation[1]” field is set to Address of the
page that caused the fault
ASSERT( ExceptionRecord->ExceptionCode ==
STATUS_GUARD_PAGE_VIOLATION );
ASSERT( ExceptionRecord->NumberParameters >= 2 );
ASSERT( ExceptionRecord->ExceptionInformation[0] == 8 );
PVOID pFaulty = reinterpret_cast( ExceptionRecord->ExceptionInformation[1] );
return EXCEPTION_EXECUTE_HANDLER;
} else { return EXCEPTION_CONTINUE_SEARCH; }
}
but the debugger output is not what the comments assume they should be:
this is coming from a simple test program. the test program uses virtual
alloc to create a 4096 byte guard page and sends the address of that page
down to the kernel via an ioctl. so the same thread, which is now blocked
in kernel and in th kernel I callMmProbeAndLock on the MDL created. and get
he exception
very simple scenario, as I said it is for educational purpose non
commercial.
> I am trying to write a debugger and implement break on access on memory. > (this is non-commercial, just experimental stuff ). > > what i intend to do i catch the exception,and put the guard back with > Virtualprotect, as part of the handler logic. > > > > -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com > Sent: Thursday, March 24, 2016 6:40 AM > To: Windows System Software Devs Interest List > Subject: RE:[ntdev] STATUS_GUARD_PAGE_VIOLATION > > > > You SHOULD NOT TRY TO HANDLE THIS EXCEPTION. > > Why do you do that? > > > > — > > NTDEV is sponsored by OSR > > > > Visit the list online at: < > http://www.osronline.com/showlists.cfm?list=ntdev> > > > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > > Details at http: > > > > To unsubscribe, visit the List Server section of OSR Online at < > http://www.osronline.com/page.cfm?name=ListServer> > > On Wed, Mar 23, 2016 at 11:47 PM, A P wrote: > >> I am trying to handle this exception. >> >> My dummy code is as follows: >> >> ULONG BackgroundExceptionFilter( ULONG Code, PEXCEPTION_POINTERS pointers >> ) >> { >> PAGED_CODE(); >> >> if( Code == STATUS_ACCESS_VIOLATION ) >> { >> return EXCEPTION_EXECUTE_HANDLER; >> } >> else if ( Code == STATUS_GUARD_PAGE_VIOLATION ) >> { >> PEXCEPTION_RECORD ExceptionRecord; >> PCONTEXT Context; >> >> ExceptionRecord = pointers->ExceptionRecord; >> Context = pointers->ContextRecord; >> // a) The “ExceptionCode” field is set to >> STATUS_GUARD_PAGE_VIOLATION 0x80000001. >> // b) The “NumberParameters” field is greater than or equal to 2. >> // c) The “ExceptionInformation[0]” field is set to 8. >> // d) The “ExceptionInformation[1]” field is set to Address of >> the page that caused the fault >> ASSERT( ExceptionRecord->ExceptionCode == >> STATUS_GUARD_PAGE_VIOLATION ); >> ASSERT( ExceptionRecord->NumberParameters >= 2 ); >> ASSERT( ExceptionRecord->ExceptionInformation[0] == 8 ); >> PVOID pFaulty = reinterpret_cast( >> ExceptionRecord->ExceptionInformation[1] ); >> >> return EXCEPTION_EXECUTE_HANDLER; >> >> } >> else >> { >> return EXCEPTION_CONTINUE_SEARCH; >> } >> >> >> >> } >> >> but the debugger output is not what the comments assume they should be: >> >> kd> dv >> ExceptionRecord = 0x9a713524 >> Context = 0x9a713254 >> Code = 0x80000001 >> pointers = 0x9a713150 >> kd> dx -r1 (((MyDrv!_EXCEPTION_RECORD )0xffffffff9a713524)) >> (((MyDrv!_EXCEPTION_RECORD )0xffffffff9a713524)) [Type: >> _EXCEPTION_RECORD] >> [+0x000] ExceptionCode : -2147483647 >> [+0x004] ExceptionFlags : 0x1 >> [+0x008] ExceptionRecord : 0x0 [Type: _EXCEPTION_RECORD ] >> [+0x00c] ExceptionAddress : 0xffffffff826ab8fd [Type: void ] >> [+0x010] NumberParameters : 0x0 >> [+0x014] ExceptionInformation [Type: unsigned long [15]] >> kd> dx -r1 (((MyDrv!unsigned long ()[15])0xffffffff9a713538)) >> (((SRTSP!unsigned long ()[15])0xffffffff9a713538)) >> [Type: unsigned long [15]] >> [0] : 0x0 >> [1] : 0x0 >> [2] : 0x23 >> [3] : 0x23 >> [4] : 0x0 >> [5] : 0x8b2c0fd4 >> [6] : 0x0 >> [7] : 0x3 >> [8] : 0x9a71361c >> [9] : 0x30 >> [10] : 0xd0000 >> [11] : 0xa1315a90 >> [12] : 0x7ffff8 >> [13] : 0x9a71362c >> [14] : 0x0 >> >> what am I missing here? >> >> AP >> > ></http:></http:></http:>
yes, that is exactly what my sample is based on…
doesnt tell any thing about the exception and how it should be handled at
all, and why my debugger is not getting the exception record the way it
should…
-----Original Message-----
From: xxxxx@lists.osr.com [mailto: xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Thursday, March 24, 2016 2:33 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] STATUS_GUARD_PAGE_VIOLATION
> this is coming from a simple test program. the test program uses virtual > alloc to create a 4096 byte guard page and sends the address of that page > down to the kernel via an ioctl. so the same thread, which is now blocked > in kernel and in th kernel I callMmProbeAndLock on the MDL created. and get > he exception > > very simple scenario, as I said it is for educational purpose non > commercial. > > -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com > Sent: Thursday, March 24, 2016 1:00 PM > To: Windows System Software Devs Interest List > Subject: RE:[ntdev] STATUS_GUARD_PAGE_VIOLATION > > > > Did you map the page yourself, or it’s a stack page? Is this page next to > the mapped stack page? > > > > — > > NTDEV is sponsored by OSR > > > > Visit the list online at: < > http://www.osronline.com/showlists.cfm?list=ntdev>ia an ioctl in the > function itself. so the same thread. which is now blocked in the kernel > > > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > > Details at http: > > > > To unsubscribe, visit the List Server section of OSR Online at < > http://www.osronline.com/page.cfm?name=ListServer> > > On Thu, Mar 24, 2016 at 12:32 PM, A P wrote: > >> I am trying to write a debugger and implement break on access on memory. >> (this is non-commercial, just experimental stuff ). >> >> what i intend to do i catch the exception,and put the guard back with >> Virtualprotect, as part of the handler logic. >> >> >> >> -----Original Message----- >> From: xxxxx@lists.osr.com >> [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com >> Sent: Thursday, March 24, 2016 6:40 AM >> To: Windows System Software Devs Interest List >> Subject: RE:[ntdev] STATUS_GUARD_PAGE_VIOLATION >> >> >> >> You SHOULD NOT TRY TO HANDLE THIS EXCEPTION. >> >> Why do you do that? >> >> >> >> — >> >> NTDEV is sponsored by OSR >> >> >> >> Visit the list online at: < >> http://www.osronline.com/showlists.cfm?list=ntdev> >> >> >> >> MONTHLY seminars on crash dump analysis, WDF, Windows internals and >> software drivers! >> >> Details at http: >> >> >> >> To unsubscribe, visit the List Server section of OSR Online at < >> http://www.osronline.com/page.cfm?name=ListServer> >> >> On Wed, Mar 23, 2016 at 11:47 PM, A P wrote: >> >>> I am trying to handle this exception. >>> >>> My dummy code is as follows: >>> >>> ULONG BackgroundExceptionFilter( ULONG Code, PEXCEPTION_POINTERS >>> pointers ) >>> { >>> PAGED_CODE(); >>> >>> if( Code == STATUS_ACCESS_VIOLATION ) >>> { >>> return EXCEPTION_EXECUTE_HANDLER; >>> } >>> else if ( Code == STATUS_GUARD_PAGE_VIOLATION ) >>> { >>> PEXCEPTION_RECORD ExceptionRecord; >>> PCONTEXT Context; >>> >>> ExceptionRecord = pointers->ExceptionRecord; >>> Context = pointers->ContextRecord; >>> // a) The “ExceptionCode” field is set to >>> STATUS_GUARD_PAGE_VIOLATION 0x80000001. >>> // b) The “NumberParameters” field is greater than or equal to >>> 2. >>> // c) The “ExceptionInformation[0]” field is set to 8. >>> // d) The “ExceptionInformation[1]” field is set to Address of >>> the page that caused the fault >>> ASSERT( ExceptionRecord->ExceptionCode == >>> STATUS_GUARD_PAGE_VIOLATION ); >>> ASSERT( ExceptionRecord->NumberParameters >= 2 ); >>> ASSERT( ExceptionRecord->ExceptionInformation[0] == 8 ); >>> PVOID pFaulty = reinterpret_cast( >>> ExceptionRecord->ExceptionInformation[1] ); >>> >>> return EXCEPTION_EXECUTE_HANDLER; >>> >>> } >>> else >>> { >>> return EXCEPTION_CONTINUE_SEARCH; >>> } >>> >>> >>> >>> } >>> >>> but the debugger output is not what the comments assume they should be: >>> >>> kd> dv >>> ExceptionRecord = 0x9a713524 >>> Context = 0x9a713254 >>> Code = 0x80000001 >>> pointers = 0x9a713150 >>> kd> dx -r1 (((MyDrv!_EXCEPTION_RECORD )0xffffffff9a713524)) >>> (((MyDrv!_EXCEPTION_RECORD )0xffffffff9a713524)) >>> [Type: _EXCEPTION_RECORD] >>> [+0x000] ExceptionCode : -2147483647 >>> [+0x004] ExceptionFlags : 0x1 >>> [+0x008] ExceptionRecord : 0x0 [Type: _EXCEPTION_RECORD ] >>> [+0x00c] ExceptionAddress : 0xffffffff826ab8fd [Type: void ] >>> [+0x010] NumberParameters : 0x0 >>> [+0x014] ExceptionInformation [Type: unsigned long [15]] >>> kd> dx -r1 (((MyDrv!unsigned long ()[15])0xffffffff9a713538)) >>> (((SRTSP!unsigned long ()[15])0xffffffff9a713538)) >>> [Type: unsigned long [15]] >>> [0] : 0x0 >>> [1] : 0x0 >>> [2] : 0x23 >>> [3] : 0x23 >>> [4] : 0x0 >>> [5] : 0x8b2c0fd4 >>> [6] : 0x0 >>> [7] : 0x3 >>> [8] : 0x9a71361c >>> [9] : 0x30 >>> [10] : 0xd0000 >>> [11] : 0xa1315a90 >>> [12] : 0x7ffff8 >>> [13] : 0x9a71362c >>> [14] : 0x0 >>> >>> what am I missing here? >>> >>> AP >>> >> >> ></http:></http:>