PAGE_FAULT_IN_NONPAGED_AREA

Hi, I’m getting this bugcheck within my driver, but I can’t understand
why, here the code causing the bug check:

IdCalcCrc32((UCHAR)*ptr, dwCrc32);

where dwCrc32 is an ULONG *, and ptr is a pointer UCHAR *ptr = (UCHAR
*)String, where String is a PWCHAR pointer. Now, this PWCHAR pointer
comes from paged memory allocated with ExAllocateFromPagedLookasideList,
this memory is allocated inside IRP_MJ_CREATE path, where I also call
the IdCalcCrc32 function causing the bug check, looking at the DDK
documentation, it says that dispatch routines are always called at
PASSIVE_LEVEL for file system driver, mine is a filter driver, so it
should be the same thing, so why am I getting the bug check?
I’ve tried also using a non paged lookaside list, but nothing change.

Thanks.

Can u please provide the output of !analyze -v command.

Please provide all the parameters which are dump in the blue screen.

Just to check are u de-referencing a NULL pointer?

thanks
-Kiran

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Lorenzo
Sent: Thursday, December 02, 2004 8:42 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] PAGE_FAULT_IN_NONPAGED_AREA

Hi, I’m getting this bugcheck within my driver, but I can’t understand
why, here the code causing the bug check:

IdCalcCrc32((UCHAR)*ptr, dwCrc32);

where dwCrc32 is an ULONG *, and ptr is a pointer UCHAR *ptr = (UCHAR
*)String, where String is a PWCHAR pointer. Now, this PWCHAR pointer
comes from paged memory allocated with ExAllocateFromPagedLookasideList,
this memory is allocated inside IRP_MJ_CREATE path, where I also call
the IdCalcCrc32 function causing the bug check, looking at the DDK
documentation, it says that dispatch routines are always called at
PASSIVE_LEVEL for file system driver, mine is a filter driver, so it
should be the same thing, so why am I getting the bug check?
I’ve tried also using a non paged lookaside list, but nothing change.

Thanks.


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@calsoftinc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

No, it isn’t a null pointer, it seems like that I can’t use the memory
allocated from the paged lookaside list, but I’m not at dispatch_level
or above, I’m at passive_level, so I can’t understand why, anyway here
is the output of the analyze -v (not very useful in this case):

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by
try-except,
it must be protected by a Probe. Typically the address is just plain
bad or it
is pointing at freed memory.
Arguments:
Arg1: e1921000, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: f5d86cb6, If non-zero, the instruction address which referenced
the bad memory
address.
Arg4: 00000001, (reserved)

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

READ_ADDRESS: unable to get nt!MmPoolCodeEnd
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSpecialPoolStart
unable to get nt!MmPagedPoolStart
unable to get nt!MiSessionPoolStart
unable to get nt!MiSessionPoolEnd
unable to get nt!MmNonPagedPoolExpansionStart
unable to get nt!MmPoolCodeStart
e1921000

FAULTING_IP:
infdrv!IdStringCrc32+36 [h:\progetti\infdrv\infdrvfunc.c @ 1569]
f5d86cb6 8a02 mov al,[edx]

MM_INTERNAL_CODE: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x50

LAST_CONTROL_TRANSFER: from 8051a00c to 804fc1bb

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
f409636c 8051a00c 00000050 e1921000 00000000 nt!KeBugCheckEx+0x19
f40963b8 804d7a5b 00000000 e1921000 00000000 nt!ExRaiseStatus+0x9ddf
f40963d0 00000000 e1631550 e1ff0258 00000001 nt!Kei386EoiHelper+0x23a1

FOLLOWUP_IP:
infdrv!IdStringCrc32+36 [h:\progetti\infdrv\infdrvfunc.c @ 1569]
f5d86cb6 8a02 mov al,[edx]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: infdrv!IdStringCrc32+36

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: kb

BUCKET_ID: WRONG_SYMBOLS

MODULE_NAME: Unknown_Module

Followup: MachineOwner

can u pass (PWCHAR) instead of (PUCHAR) ?

-prokash
----- Original Message -----
From: “Lorenzo”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Thursday, December 02, 2004 7:48 AM
Subject: [ntfsd] Re: PAGE_FAULT_IN_NONPAGED_AREA

> No, it isn’t a null pointer, it seems like that I can’t use the memory
> allocated from the paged lookaside list, but I’m not at dispatch_level
> or above, I’m at passive_level, so I can’t understand why, anyway here
> is the output of the analyze -v (not very useful in this case):
>
> PAGE_FAULT_IN_NONPAGED_AREA (50)
> Invalid system memory was referenced. This cannot be protected by
> try-except,
> it must be protected by a Probe. Typically the address is just plain
> bad or it
> is pointing at freed memory.
> Arguments:
> Arg1: e1921000, memory referenced.
> Arg2: 00000000, value 0 = read operation, 1 = write operation.
> Arg3: f5d86cb6, If non-zero, the instruction address which referenced
> the bad memory
> address.
> Arg4: 00000001, (reserved)
>
> Debugging Details:
> ------------------
>
> ***** Kernel symbols are WRONG. Please fix symbols to do analysis.
>
>
> READ_ADDRESS: unable to get nt!MmPoolCodeEnd
> unable to get nt!MmSpecialPoolEnd
> unable to get nt!MmPagedPoolEnd
> unable to get nt!MmNonPagedPoolEnd
> unable to get nt!MmNonPagedPoolStart
> unable to get nt!MmSpecialPoolStart
> unable to get nt!MmPagedPoolStart
> unable to get nt!MiSessionPoolStart
> unable to get nt!MiSessionPoolEnd
> unable to get nt!MmNonPagedPoolExpansionStart
> unable to get nt!MmPoolCodeStart
> e1921000
>
> FAULTING_IP:
> infdrv!IdStringCrc32+36 [h:\progetti\infdrv\infdrvfunc.c @ 1569]
> f5d86cb6 8a02 mov al,[edx]
>
> MM_INTERNAL_CODE: 1
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x50
>
> LAST_CONTROL_TRANSFER: from 8051a00c to 804fc1bb
>
> STACK_TEXT:
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> f409636c 8051a00c 00000050 e1921000 00000000 nt!KeBugCheckEx+0x19
> f40963b8 804d7a5b 00000000 e1921000 00000000 nt!ExRaiseStatus+0x9ddf
> f40963d0 00000000 e1631550 e1ff0258 00000001 nt!Kei386EoiHelper+0x23a1
>
>
> FOLLOWUP_IP:
> infdrv!IdStringCrc32+36 [h:\progetti\infdrv\infdrvfunc.c @ 1569]
> f5d86cb6 8a02 mov al,[edx]
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: infdrv!IdStringCrc32+36
>
> IMAGE_NAME: Unknown_Image
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> STACK_COMMAND: kb
>
> BUCKET_ID: WRONG_SYMBOLS
>
> MODULE_NAME: Unknown_Module
>
> Followup: MachineOwner
> ---------
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

Also IdCalcCrc32((UCHAR)*ptr, dwCrc32) is not what u want if you typed
right. Should be (UCHAR*). But I suspect (PWCHAR) is better. The wide
strings are two bytes, and always the higher one is zero. NULL is a double
zero…

-prokash
----- Original Message -----
From: “Lorenzo”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Thursday, December 02, 2004 7:11 AM
Subject: [ntfsd] PAGE_FAULT_IN_NONPAGED_AREA

> Hi, I’m getting this bugcheck within my driver, but I can’t understand
> why, here the code causing the bug check:
>
> IdCalcCrc32((UCHAR)*ptr, dwCrc32);
>
> where dwCrc32 is an ULONG *, and ptr is a pointer UCHAR *ptr = (UCHAR
> *)String, where String is a PWCHAR pointer. Now, this PWCHAR pointer
> comes from paged memory allocated with ExAllocateFromPagedLookasideList,
> this memory is allocated inside IRP_MJ_CREATE path, where I also call
> the IdCalcCrc32 function causing the bug check, looking at the DDK
> documentation, it says that dispatch routines are always called at
> PASSIVE_LEVEL for file system driver, mine is a filter driver, so it
> should be the same thing, so why am I getting the bug check?
> I’ve tried also using a non paged lookaside list, but nothing change.
>
> Thanks.
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

In your previous post, it reads you were suspecting the
IdCalcCrc32((UCHAR)*ptr, dwCrc32) causing the problem and the ptr pointed to
paged pool memory. But the bugcheck stack shows it’s actually IdStringCrc32
causing the problem. What’s the relation between IdCalcCrc32 and
IdStringCrc32???

infdrv!IdStringCrc32+36 [h:\progetti\infdrv\infdrvfunc.c @ 1569]
f5d86cb6 8a02 mov al,[edx]

How the value in edx is related to the (UCHAR)*ptr passed to IdCalcCrc32?

Are you able to fix the kernel symbols to show the full call stack?

The bugcheck seemed to complain that edx is pointing to NON_PAGED area but
is not backed by physical memory.
a) Where does the value in EDX come from actually?
b) What does kd>!pool e1921000 say?

Making assumption that IdStringCrc32 is called by IdCalcCrc32, I would try
the following:

  1. FIX THE KERNEL SYMBOLS FIRST.
  2. Right after entering IdCalcCrc32, check if the ptr is valid. (kd>!pool
    )
    3. Check the parameters passed to IdStringCrc32, pay attention to those
    pointers.
    4. Trace the function IdStringCrc32, identify how edx gets a bad pointer to
    NPagedPool.

    Good luck,
    Calvin

    Calvin Guan, Software Developer xxxxx@nospam.ati.com
    SW2D-Radeon NT Core Drivers
    ATI Technologies Inc.
    1 Commerce Valley Drive East
    Markham, Ontario, Canada L3T 7X6
    Tel: (905) 882-2600 Ext. 8654
    Find a driver: http://www.ati.com/support/driver.html

    > -----Original Message-----
    > From: Lorenzo [mailto:xxxxx@email.it]
    > Sent: Thursday, December 02, 2004 10:48 AM
    > To: Windows File Systems Devs Interest List
    > Subject: [ntfsd] Re: PAGE_FAULT_IN_NONPAGED_AREA
    >
    >
    > No, it isn’t a null pointer, it seems like that I can’t use
    > the memory
    > allocated from the paged lookaside list, but I’m not at
    > dispatch_level
    > or above, I’m at passive_level, so I can’t understand why,
    > anyway here
    > is the output of the analyze -v (not very useful in this case):
    >
    > PAGE_FAULT_IN_NONPAGED_AREA (50)
    > Invalid system memory was referenced. This cannot be protected by
    > try-except,
    > it must be protected by a Probe. Typically the address is just plain
    > bad or it
    > is pointing at freed memory.
    > Arguments:
    > Arg1: e1921000, memory referenced.
    > Arg2: 00000000, value 0 = read operation, 1 = write operation.
    > Arg3: f5d86cb6, If non-zero, the instruction address which referenced
    > the bad memory
    > address.
    > Arg4: 00000001, (reserved)
    >
    > Debugging Details:
    > ------------------
    >
    > ***** Kernel symbols are WRONG. Please fix symbols to do analysis.
    >
    >
    > READ_ADDRESS: unable to get nt!MmPoolCodeEnd
    > unable to get nt!MmSpecialPoolEnd
    > unable to get nt!MmPagedPoolEnd
    > unable to get nt!MmNonPagedPoolEnd
    > unable to get nt!MmNonPagedPoolStart
    > unable to get nt!MmSpecialPoolStart
    > unable to get nt!MmPagedPoolStart
    > unable to get nt!MiSessionPoolStart
    > unable to get nt!MiSessionPoolEnd
    > unable to get nt!MmNonPagedPoolExpansionStart
    > unable to get nt!MmPoolCodeStart
    > e1921000
    >
    > FAULTING_IP:
    > infdrv!IdStringCrc32+36 [h:\progetti\infdrv\infdrvfunc.c @ 1569]
    > f5d86cb6 8a02 mov al,[edx]
    >
    > MM_INTERNAL_CODE: 1
    >
    > DEFAULT_BUCKET_ID: DRIVER_FAULT
    >
    > BUGCHECK_STR: 0x50
    >
    > LAST_CONTROL_TRANSFER: from 8051a00c to 804fc1bb
    >
    > STACK_TEXT:
    > WARNING: Stack unwind information not available. Following
    > frames may be
    > wrong.
    > f409636c 8051a00c 00000050 e1921000 00000000 nt!KeBugCheckEx+0x19
    > f40963b8 804d7a5b 00000000 e1921000 00000000 nt!ExRaiseStatus+0x9ddf
    > f40963d0 00000000 e1631550 e1ff0258 00000001 nt!Kei386EoiHelper+0x23a1
    >
    >
    > FOLLOWUP_IP:
    > infdrv!IdStringCrc32+36 [h:\progetti\infdrv\infdrvfunc.c @ 1569]
    > f5d86cb6 8a02 mov al,[edx]
    >
    > FOLLOWUP_NAME: MachineOwner
    >
    > SYMBOL_NAME: infdrv!IdStringCrc32+36
    >
    > IMAGE_NAME: Unknown_Image
    >
    > DEBUG_FLR_IMAGE_TIMESTAMP: 0
    >
    > STACK_COMMAND: kb
    >
    > BUCKET_ID: WRONG_SYMBOLS
    >
    > MODULE_NAME: Unknown_Module
    >
    > Followup: MachineOwner
    > ---------
    >
    >
    > —
    > Questions? First check the IFS FAQ at
    > https://www.osronline.com/article.cfm?id=17
    >
    > You are currently subscribed to ntfsd as: xxxxx@ati.com
    > To unsubscribe send a blank email to xxxxx@lists.osr.com
    >

Well the relation between IdCalcCrc32 and IdStringCrc32 is simply that
IdStringCrc32 calls IdCalcCrc32((UCHAR)*ptr, dwCrc32), where ptr is a
valid pointer and dwCrc32 is just an ULONG *, (UCHAR)*ptr isn’t a
mistake, I want the byte pointed by ptr, and ptr points to a WCHAR
string, but I want to access this string as a byte array, so:
UCHAR *ptr = (UCHAR *)String;

where String is a WCHAR passed to the function IdStringCrc32, this
function works perfectly if I use it in user mode, but as I implemented
it in my driver, it started to crash, apparently the reason is that I
can’t access the paged memory allocated with the lookaside list, but how
is this possible?

anyway here is the code:

VOID
IdStringCrc32(
PWCHAR String,
ULONG *pCrc32,
ULONG Size
)
{
UCHAR *ptr = (UCHAR *)String;
ULONG i;

*dwCrc32 = 0xFFFFFFFF;

for(i = 0; i < Size; i++)
{
IdCalcCrc32((UCHAR)*ptr, pCrc32);
ptr++;
IdCalcCrc32((UCHAR)*ptr, pCrc32);
ptr++;
}

*dwCrc32 = ~(*dwCrc32);
}

I don’t know why, but apparently it crashs only when explorer opens the
files, if they are opened by another process it works without problems,
although I’m not 100% sure about this, right now I can’t check anything
with WinDbg since I don’t have anymore my laptop and I’ll get it back in
15 days, anyway I’ll debug it with softice on my pc.
One last thing, the bug check may be caused by the dispatch routine
being called at an irql >= dispatch_level? if so, why the dispatch
routine should be called at that level??

Regarding the symbols, I don’t know why WinDbg tells that symbols are
wrong, I downloaded them from the microsoft’s website, they always
worked, I don’t know what’s happening now.

Any suggestions are welcome :slight_smile:

Thanks.

Lorenzo

Obvious I know, but you are passing the correct size aren`t you?

You should be passing the length of the string in wchar’s

Also where does dwCrc32 come from

Ben Curley
DESlock+ Lead Programmer
Data Encryption Systems Ltd.

Tel: +44 (0)1823 352357 (Main)
Tel: +44 (0)1823 358320 (Direct Dial)

Web: http://www.deslock.com

-----Original Message-----
From: Lorenzo [mailto:xxxxx@email.it]
Sent: 02 December 2004 18:46
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Re: PAGE_FAULT_IN_NONPAGED_AREA

Well the relation between IdCalcCrc32 and IdStringCrc32 is simply that
IdStringCrc32 calls IdCalcCrc32((UCHAR)*ptr, dwCrc32), where ptr is a
valid pointer and dwCrc32 is just an ULONG *, (UCHAR)*ptr isn’t a
mistake, I want the byte pointed by ptr, and ptr points to a WCHAR
string, but I want to access this string as a byte array, so:
UCHAR *ptr = (UCHAR *)String;

where String is a WCHAR passed to the function IdStringCrc32, this
function works perfectly if I use it in user mode, but as I implemented
it in my driver, it started to crash, apparently the reason is that I
can’t access the paged memory allocated with the lookaside list, but how
is this possible?

anyway here is the code:

VOID
IdStringCrc32(
PWCHAR String,
ULONG *pCrc32,
ULONG Size
)
{
UCHAR *ptr = (UCHAR *)String;
ULONG i;

*dwCrc32 = 0xFFFFFFFF;

for(i = 0; i < Size; i++)
{
IdCalcCrc32((UCHAR)*ptr, pCrc32);
ptr++;
IdCalcCrc32((UCHAR)*ptr, pCrc32);
ptr++;
}

*dwCrc32 = ~(*dwCrc32);
}

I don’t know why, but apparently it crashs only when explorer opens the
files, if they are opened by another process it works without problems,
although I’m not 100% sure about this, right now I can’t check anything
with WinDbg since I don’t have anymore my laptop and I’ll get it back in
15 days, anyway I’ll debug it with softice on my pc.
One last thing, the bug check may be caused by the dispatch routine
being called at an irql >= dispatch_level? if so, why the dispatch
routine should be called at that level??

Regarding the symbols, I don’t know why WinDbg tells that symbols are
wrong, I downloaded them from the microsoft’s website, they always
worked, I don’t know what’s happening now.

Any suggestions are welcome :slight_smile:

Thanks.

Lorenzo


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@des.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com

I checked everything, I still don’t understand what’s wrong.
A strange thing is that when I call wcsrchr on the same string, it
doesn’t crash, and I don’t think that (supposing that I’m at
dispatch_level) between two function’s call my code will get swapped out
from ram, but anyway, why wcsrchr works and my function don’t?

Did you actually allocate e1921000? Unless your allocation was >
PAGE_SIZE, which is the only time when your allocation will start at a
page boundary, this is a red-flag level indication you ran past the end
of the allocation. A pool allocation < PAGE_SIZE will always have a
small pool header (8 bytes) preceeding it.

I.e., did you really get allocated e1920a80 (etc.) which you then walked
past the end of. Do a !pool on the previous page to see if you spot the
allocation you were really using.

Temporarily change to use the non-lookaside allocation APIs and put your
driver under the verifier. Make sure you turn on special pool.

Dan Lovinger
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lorenzo
Sent: Thursday, December 02, 2004 7:48 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Re: PAGE_FAULT_IN_NONPAGED_AREA

No, it isn’t a null pointer, it seems like that I can’t use the memory
allocated from the paged lookaside list, but I’m not at dispatch_level
or above, I’m at passive_level, so I can’t understand why, anyway here
is the output of the analyze -v (not very useful in this case):

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by
try-except,
it must be protected by a Probe. Typically the address is just plain
bad or it
is pointing at freed memory.
Arguments:
Arg1: e1921000, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: f5d86cb6, If non-zero, the instruction address which referenced
the bad memory
address.
Arg4: 00000001, (reserved)

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

READ_ADDRESS: unable to get nt!MmPoolCodeEnd
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSpecialPoolStart
unable to get nt!MmPagedPoolStart
unable to get nt!MiSessionPoolStart
unable to get nt!MiSessionPoolEnd
unable to get nt!MmNonPagedPoolExpansionStart
unable to get nt!MmPoolCodeStart
e1921000

FAULTING_IP:
infdrv!IdStringCrc32+36 [h:\progetti\infdrv\infdrvfunc.c @ 1569]
f5d86cb6 8a02 mov al,[edx]

MM_INTERNAL_CODE: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x50

LAST_CONTROL_TRANSFER: from 8051a00c to 804fc1bb

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be

wrong.
f409636c 8051a00c 00000050 e1921000 00000000 nt!KeBugCheckEx+0x19
f40963b8 804d7a5b 00000000 e1921000 00000000 nt!ExRaiseStatus+0x9ddf
f40963d0 00000000 e1631550 e1ff0258 00000001 nt!Kei386EoiHelper+0x23a1

FOLLOWUP_IP:
infdrv!IdStringCrc32+36 [h:\progetti\infdrv\infdrvfunc.c @ 1569]
f5d86cb6 8a02 mov al,[edx]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: infdrv!IdStringCrc32+36

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: kb

BUCKET_ID: WRONG_SYMBOLS

MODULE_NAME: Unknown_Module

Followup: MachineOwner


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Calvin Guan, Software Developer xxxxx@nospam.ati.com
SW2D-Radeon NT Core Drivers
ATI Technologies Inc.
1 Commerce Valley Drive East
Markham, Ontario, Canada L3T 7X6
Tel: (905) 882-2600 Ext. 8654
Find a driver: http://www.ati.com/support/driver.html

comment inline.

where String is a WCHAR passed to the function IdStringCrc32, this
function works perfectly if I use it in user mode, but as I
implemented
it in my driver, it started to crash, apparently the reason is that I
can’t access the paged memory allocated with the lookaside
list, but how
is this possible?

anyway here is the code:

VOID
IdStringCrc32(
PWCHAR String,
ULONG *pCrc32,
ULONG Size
)
{
UCHAR *ptr = (UCHAR *)String; <<– set an BP here and examine the
ptr to see where it points to (PagedPool or NPagedPool). Does system
bugcheck on access to this region of memory?

ULONG i;

PAGED_CODE(); <<– add this here to make sure it called <
DISPATCH_LEVEL if you doubt it.

*dwCrc32 = 0xFFFFFFFF;

for(i = 0; i < Size; i++)
{
IdCalcCrc32((UCHAR)*ptr, pCrc32);
ptr++;
IdCalcCrc32((UCHAR)*ptr, pCrc32);
ptr++;
}

*dwCrc32 = ~(*dwCrc32);
}

One last thing, the bug check may be caused by the dispatch routine
being called at an irql >= dispatch_level?

If so, it’d been IRQL_NOT_LESS_OR_EQUAL instead of
PAGE_FAULT_IN_NON_PAGED_AREA.

Regarding the symbols, I don’t know why WinDbg tells that symbols are
wrong, I downloaded them from the microsoft’s website, they always
worked, I don’t know what’s happening now.

Are you using MS symbol server?

Did you install any MS update recently? One possibility is that some MS
updates would replace the ntoskrnl but the symbol is not in their symserver.
I hate when that happens. Anyway, you could check the symbol info by:

kd>!sym noisy
kd>.reload /f ntoskrnl.exe

Dispatch routines of storage, serial, USB and 1394 stacks can be called on
DISPATCH_LEVEL.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Lorenzo”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Thursday, December 02, 2004 6:11 PM
Subject: [ntfsd] PAGE_FAULT_IN_NONPAGED_AREA

> Hi, I’m getting this bugcheck within my driver, but I can’t understand
> why, here the code causing the bug check:
>
> IdCalcCrc32((UCHAR)*ptr, dwCrc32);
>
> where dwCrc32 is an ULONG *, and ptr is a pointer UCHAR *ptr = (UCHAR
> *)String, where String is a PWCHAR pointer. Now, this PWCHAR pointer
> comes from paged memory allocated with ExAllocateFromPagedLookasideList,
> this memory is allocated inside IRP_MJ_CREATE path, where I also call
> the IdCalcCrc32 function causing the bug check, looking at the DDK
> documentation, it says that dispatch routines are always called at
> PASSIVE_LEVEL for file system driver, mine is a filter driver, so it
> should be the same thing, so why am I getting the bug check?
> I’ve tried also using a non paged lookaside list, but nothing change.
>
> Thanks.
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

I should clarify what I meant below.

Always run under the driver verifier. At the very least, as soon as you
start getting strange bugchecks, putting your driver under the verifier
should be automatic.

With respect to lookaside allocation APIs: they probably aren’t buying
you anything. Use the regular allocation APIs - they are using
lookasides internally already. Unfortunately, the lookaside allocators
evade the verifier pool allocation hooks and as a result you won’t get
the coverage you need to find problems. If you are sure it makes sense
to use the lookaside APIs longer term, temporarily stop using them to
debug this problem.

Also, with respect to pool headers: what you’d normally see as the first
allocation on a small-pool (< PAGE_SIZE per allocation) page would be at
byte offset 8 (8 byte pool header). So e1921008, etc. The address you
took the fault on below is a pretty strong red flag, absent other
information.

Dan Lovinger
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Lovinger
Sent: Tuesday, December 02, 2003 11:38 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Re: PAGE_FAULT_IN_NONPAGED_AREA

Did you actually allocate e1921000? Unless your allocation was >
PAGE_SIZE, which is the only time when your allocation will start at a
page boundary, this is a red-flag level indication you ran past the end
of the allocation. A pool allocation < PAGE_SIZE will always have a
small pool header (8 bytes) preceeding it.

I.e., did you really get allocated e1920a80 (etc.) which you then walked
past the end of. Do a !pool on the previous page to see if you spot the
allocation you were really using.

Temporarily change to use the non-lookaside allocation APIs and put your
driver under the verifier. Make sure you turn on special pool.

Dan Lovinger
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lorenzo
Sent: Thursday, December 02, 2004 7:48 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Re: PAGE_FAULT_IN_NONPAGED_AREA

No, it isn’t a null pointer, it seems like that I can’t use the memory
allocated from the paged lookaside list, but I’m not at dispatch_level
or above, I’m at passive_level, so I can’t understand why, anyway here
is the output of the analyze -v (not very useful in this case):

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by
try-except,
it must be protected by a Probe. Typically the address is just plain
bad or it
is pointing at freed memory.
Arguments:
Arg1: e1921000, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: f5d86cb6, If non-zero, the instruction address which referenced
the bad memory
address.
Arg4: 00000001, (reserved)

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

READ_ADDRESS: unable to get nt!MmPoolCodeEnd
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSpecialPoolStart
unable to get nt!MmPagedPoolStart
unable to get nt!MiSessionPoolStart
unable to get nt!MiSessionPoolEnd
unable to get nt!MmNonPagedPoolExpansionStart
unable to get nt!MmPoolCodeStart
e1921000

FAULTING_IP:
infdrv!IdStringCrc32+36 [h:\progetti\infdrv\infdrvfunc.c @ 1569]
f5d86cb6 8a02 mov al,[edx]

MM_INTERNAL_CODE: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x50

LAST_CONTROL_TRANSFER: from 8051a00c to 804fc1bb

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be

wrong.
f409636c 8051a00c 00000050 e1921000 00000000 nt!KeBugCheckEx+0x19
f40963b8 804d7a5b 00000000 e1921000 00000000 nt!ExRaiseStatus+0x9ddf
f40963d0 00000000 e1631550 e1ff0258 00000001 nt!Kei386EoiHelper+0x23a1

FOLLOWUP_IP:
infdrv!IdStringCrc32+36 [h:\progetti\infdrv\infdrvfunc.c @ 1569]
f5d86cb6 8a02 mov al,[edx]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: infdrv!IdStringCrc32+36

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: kb

BUCKET_ID: WRONG_SYMBOLS

MODULE_NAME: Unknown_Module

Followup: MachineOwner


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Ok, I solved everything, the problem was related to the way I was
handling unicode string, because I forgot that they can be not null
terminated, and I was searching for the null in my function, so that was
causing the crash
anyway, thanks to everyone for the help :slight_smile:

Lorenzo