How to search in UNICODE_STRING, my function causes ocasionally a PAGE FAULT

NTFSD
1

Hey all,

I use this self-written function to search a UNICODE_STRING for a specific substring.
However i get a BSOD telling me about a PAGE FAULT.

The Bugcheck contains information about:
unable to get nt!MmSpecialPoolEnd
" " " nt!MmPoolCodeStart
" " " nt!MmPoolCodeEnd

Faulting IP: movzx edi, word ptr [ecx]

Well the line the error occurs is marked with exclamation marks, and here the code comes:

BOOLEAN SfFindInUnicodeString(PUNICODE_STRING object, PWCHAR findit,PWCHAR finditupper, int len)
{
int is_substring=0;
int i=0;
int j=0;

if(object->Buffer==NULL)
return FALSE;

if(object->Length return FALSE; // this is obvious

DbgPrint(“Length: %d, Content: %wZ\n”,object->Length,object);

for(i=0;iLength-len-5;i++) // -5, give the buffer enough space, this ugly workaround seems to work!
{
is_substring=1;
for(j=i;j {
WCHAR bufChar;
WCHAR lowerChar=findit[(j-i)];
WCHAR upperChar=finditupper[(j-i)];

/*!!! PAGEFAULT !!! */ bufChar=object->Buffer[j];

if((bufChar!=lowerChar) && (bufChar!=upperChar))
{
is_substring=0;
break;
}
}
if(is_substring==1)
break;
}

// Return result
return (is_substring==1)?TRUE:FALSE;

}

2

Well, strings are, actually, allocated from paged pool, so that I really don’t know what makes you
surprized here…

You just cannot incur page faults at elevated IRQL, so that you have to make sure that your search is done only at IRQL< DPC level…

Anton Bassov

3

> Well, strings are, actually, allocated from paged pool
It’s worse: the OP goes along the buffer using Length as if it counts wide chars.
Both object->Length and object->MaximumLength are in bytes!
Of course his code goes twice as far as needed…

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-301902-
xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Sunday, September 30, 2007 7:50 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] How to search in UNICODE_STRING, my function causes
ocasionally a PAGE FAULT

Well, strings are, actually, allocated from paged pool, so that I
really don’t know what makes you
surprized here…

You just cannot incur page faults at elevated IRQL, so that you have to
make sure that your search is done only at IRQL< DPC level…

Anton Bassov

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

4

> It’s worse: the OP goes along the buffer using Length as if it counts wide chars.

To be honest, I did not even look at his code - it is just obvious that string operations may cause page faults, so that I assumed that he runs his code at elevated IRQL. The view was based solely upon bugcheck code - AFAIK, PAGE_FAULT_IN_NONPAGED_AREA turns up only at elevated IRQL, even if the address is plainly invalid, i.e. in a situation when you would normally expect GENERAL_PROTECTION_FAULT.

However, as you have properly pointed out, the above code may cause access violation even at low IRQL - I just overlooked it (apparently, because, judging from the bugcheck code, the OP has not yet encoutered this scenario in so far)…

Anton Bassov

5

Can I add a different thing here? The search algorithm is too sloooooow. We should use KMP to search strings - at least if the string is not very small and we do it frequently. Complexity here is O(n^2) where KMP suggests linear complexity. Personally I do not like the idea of using inefficient algorithms in my program- (motivated by ACM Regional and national programming contests- i got a lot of time limit exited error :D). Look at following-

http://en.wikipedia.org/wiki/Knuth–Morris–Pratt_algorithm