xxxxx@yahoo.com wrote:
> Instead, you must queue up a work item. The work item will be called later, when the thread’s >IRQL returns to a safe level.
Thank you for explaining this to me can you point me in the right direction of any documents or examples of how to do this?
Is there no Google where you live?
http://msdn.microsoft.com/en-us/library/ff549466.aspx
I reduced the code down to just getting the owner and posted it below and an updated crash report. Does anyone have anymore ideas on this?
Yes, I see the problem. More in a moment…
Also I have 2 questions about the allocation of the UNICODE_STRING.
- owner.Length = (USHORT)ownerSize + 1; /// for the ‘\0’
Is the null terminator 1 byte or 2 or should I be adding 1 or 2 for it?- owner.Buffer = (PWCH)ExAllocatePoolWithTag(PagedPool, owner.Length, ‘oytF’);
When should you allocate using NonPagedPool over PagedPool? I have tried both allocation methods but they have both crashed, but I am also unsure when I should be using one over the other.
Paged pool memory can be copied out to the page file. When you access
memory that is paged out, it causes a page fault, and the memory is
loaded back in. Kernel code is only allowed to have a page fault at
PASSIVE_LEVEL or APC_LEVEL. If you will ever need to access this memory
at a raised IRQL, then you need to use non-paged pool so the memory
remains resident.
// Look up the SID to find out the owner. On the first call we only get
// the size of the owner so that we can allocate that much memory and call
// it again.
UNICODE_STRING owner;
ULONG ownerSize = 1;
SID_NAME_USE eUse = SidTypeUnknown;
status = SecLookupAccountSid(sid, &ownerSize, &owner, 0, NULL, &eUse);
What do you think is contained in the “owner” string that you are
sending? You are telling the API that you are providing a 1-byte
buffer, but the memory you are passing is garbage. I suggest you zero
out the “owner” structure before the call.
The documentation for SecLookupAccountSid is very confusing. If I were
writing that API, I would have allowed NULL for NameBuffer when NameSize
was 0. The description implies that NameSize is both input and output,
although the annotation says __out. I’m also not clear on why NameSize
and DomainSize are present at all, since a UNICODE_STRING always
includes a maximum length field.
Maxim has suggested in years past that you forget about this API and not
work with user names in the kernel at all. What are you really trying
to do here?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.