Line 317 is :
if (m[i] > ’ ’ && m[i] <= ‘~’)
I had posted the entire function in the earlier post, but do so once
again…
Does this mean the size being passed is beyond the size of the pointer and
it crashes because we are walking off the page allocation?
// Dumps a memory region to debug output
void MyDumpMemory (void *pMem, int nSize)
{
unsigned char str[20];
unsigned char *m = (unsigned char *)pMem;
int i, j;
char buff[128];
#define CHARS_PER_LINE (16)
if(pMem == NULL)
{
return;
}
for (j = 0; j < nSize / CHARS_PER_LINE; j++)
{
RtlZeroMemory(str , sizeof str);
RtlZeroMemory(buff, sizeof buff);
for (i = 0; i < CHARS_PER_LINE; i++)
{
if (m[i] > ’ ’ && m[i] <= ‘~’)
str[i]=m[i];
else
str[i]=‘.’;
}
MyTrace(TRACELEVEL_LOW, (“0x%08p %02x %02x %02x %02x %02x %02x
%02x %02x - %02x %02x %02x %02x %02x %02x %02x %02x %s\n”, m, m[0], m[1],
m[2], m[3], m[4], m[5], m[6], m[7], m[8], m[9], m[10], m[11], m[12], m[13],
m[14], m[15], str));
m+=CHARS_PER_LINE;
}
}
On Wed, Feb 12, 2014 at 8:54 PM, Doron Holan wrote:
> It is 50 because you are adding 0x50 to null and then dereferencing it.
> You can see that in the instruction where the bugcheck occurred. You can
> map the offset of the function to a line of source, what is line 317?
>
>
> d
>
> Dent from my phone
> ------------------------------
> From: Ami Awbadhho
> Sent: 2/12/2014 7:09 AM
>
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] How to debug an illegal pointer based crash
>
> Hi Doron,
>
> if it is a null pointer deref, then why is the address 0x50 and not 0x0?
>
> And in the code for the function we do check for null, then why would
> that check fail.
>
> // Dumps a memory region to debug output
> void MyDumpMemory (void *pMem, int nSize)
> {
> unsigned char str[20];
> unsigned char *m = (unsigned char *)pMem;
> int i, j;
> char buff[128];
>
> #define CHARS_PER_LINE (16)
>
> if(pMem == NULL)
> {
>
> return;
> }
>
>
> for (j = 0; j < nSize / CHARS_PER_LINE; j++)
> {
> RtlZeroMemory(str , sizeof str);
> RtlZeroMemory(buff, sizeof buff);
>
> for (i = 0; i < CHARS_PER_LINE; i++)
> {
> if (m[i] > ’ ’ && m[i] <= ‘~’)
> str[i]=m[i];
> else
> str[i]=‘.’;
> }
>
> MyTrace(TRACELEVEL_LOW, (“0x%08p %02x %02x %02x %02x %02x %02x
> %02x %02x - %02x %02x %02x %02x %02x %02x %02x %02x %s\n”, m, m[0], m[1],
> m[2], m[3], m[4], m[5], m[6], m[7], m[8], m[9], m[10], m[11], m[12], m[13],
> m[14], m[15], str));
>
> m+=CHARS_PER_LINE;
> }
> }
>
>
> On Wed, Feb 12, 2014 at 8:29 PM, Doron Holan wrote:
>
>> It is a null pointer deref,
>> movzx eax,byte ptr [rax+rcx]
>>
>>
>> kd> r
>> rax=0000000000000000
>> rbx=000c36ee00000000
>> rcx=0000000000000050
>>
>> Rax+rac=0x50
>>
>> The only bad memory you can detect is null or a user mode pointer through
>> Mm probe and lock. Please don’t tell.me you have SEH blocks trying to
>> catch or prevent bad memory references
>>
>> d
>>
>> Dent from my phone
>> ------------------------------
>> From: Ami Awbadhho
>> Sent: 2/12/2014 5:09 AM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] How to debug an illegal pointer based crash
>>
>> All,
>>
>> I am chasing a crash in our driver for which we only have a minidump.
>>
>> The crash is straight forward, PAGE_FAULT_IN_NONPAGED_AREA,
>> unfortunately the crash stack dump shows:
>>
>> FAULTING_IP:
>> MyDriver!MyDumpMemory+e3 [d:\Codebase\MyDriver\MyDriverlogs.cpp @ 317]
>> fffff800013c5773 0fb60408 movzx eax,byte ptr [rax+rcx]<br>>><br>>> MM_INTERNAL_CODE: 0<br>>><br>>> CUSTOMER_CRASH_COUNT: 1<br>>><br>>> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT<br>>><br>>> BUGCHECK_STR: 0x50<br>>><br>>> PROCESS_NAME: System<br>>><br>>> CURRENT_IRQL: 0<br>>><br>>> LAST_CONTROL_TRANSFER: from fffff800a2dea462 to fffff800a2dd10a0<br>>><br>>> STACK_TEXT:<br>>> ffffd00022abe658 fffff800a2dea462 : 0000000000000050 ffffe00003fa0000<br>>> 0000000000000000 ffffd00022abe840 : nt!KeBugCheckEx<br>>> ffffd00022abe660 fffff800a2ce9ffd : 0000000000000000 ffffe000025c4880<br>>> ffffd00022abe840 ffffd00022abe9b0 : nt! ?? ::FNODOBFM::string’+0x8ed2
>> ffffd00022abe700 0000000000000000 : 0000000000000000 0000000000000000
>> 0000000000000000 0000000000000000 : nt!MmAccessFault+0x7ed
>>
>>
>>
>> This is also expected, since the page we tried to access was perhaps
>> invalid or paged out.
>>
>> Dumping registers show:
>> kd> r
>> rax=0000000000000000 rbx=000c36ee00000000 rcx=0000000000000050
>> rdx=ffffe00003fa0000 rsi=ffffd00022abe7f8 rdi=ffffe000025c4ba0
>> rip=fffff800a2dd10a0 rsp=ffffd00022abe658 rbp=0000000000000000
>> r8=0000000000000000 r9=ffffd00022abe840 r10=ffffd00022abe840
>> r11=ffffe000025c4880 r12=0000000000000000 r13=0000000000000000
>> r14=fffff800a2fc9f80 r15=ffffe00003fa0000
>> iopl=0 nv up ei ng nz ac po cy
>> cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
>> efl=00000297
>>
>> This tells me that we passed an invalid address 0x50 to the movzx
>> instruction.
>>
>> Infortunately for us, since it is a mini dump, we are unable to trace
>> where the function MyDriver!MyDumpMemory is getting the invalid address
>> from.
>>
>> There are many places where it is called from, and code review of all
>> places have not come up with any clues as to how an invalid pointer might
>> get passed to the function. The said function hasa null check for the
>> pointer, but ofcourse it cannot handle an illegal pointer.
>>
>> We tried to reconstruct the call stack, and get the return address of
>> the function for the crash, but unfortunately, that doesnt work, since the
>> caller turns out to be nt!KiPageFault+0x12f. Again this is expected, as our
>> original stack is not present any more.
>>
>> The IRQL is
>>
>> kd> !irql
>> Debugger saved IRQL for processor 0x0 – 0 (LOW_LEVEL)
>>
>> So it is not a problem at eveleted IRQLs.
>>
>>
>> Any suggestions on how we can proceed with such little information
>> would help.
>>
>> BTW, we have already gone through
>> http://msdn.microsoft.com/en-us/library/windows/hardware/ff539004(v=vs.85).aspx
>>
>> which suggests that there is no one way of catching illegal memory.
>>
>> Thanks
>>
>> Awbadhho
>> — NTDEV is sponsored by OSR Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>