FS Filter Driver stack dump when BSOD

OSR_Community_User · September 30, 2002, 3:13am

Hi,

I am writing a file system filter driver, using SoftICE as debugging tool.
I have frequently encountered bugcheck, each time the stack dump is as
follows:

: stack
xxxxxxxx yyyyyyyy ntoskernel!KeBugCheckEx+0001
xxxxxxxx yyyyyyyy MyDriver!MyDriverRoutine1+007E
xxxxxxxx yyyyyyyy MyDriver!MyDriverRoutine2+004D
xxxxxxxx yyyyyyyy MyDriver!MyDriverRoutine3+001B
xxxxxxxx yyyyyyyy ntoskernel!IoBuildSynchronousFsdRequest+008F
xxxxxxxx yyyyyyyy ntoskernel!ObFindHandleForObject+0607
xxxxxxxx yyyyyyyy ntoskernel!ObOpenObjectByName+00AF
xxxxxxxx yyyyyyyy ntoskernel!IoUpdateShareAccess+02E2

Here, MyDriver is the filter driver, MyDriverRoutine1~3 is functions
implemented in MyDriver.Sys.

My questions are:

What does the stack dump mean?
What the hexes, such as +0001, 007E, etc mean?

Thanks for any instructions.

Chen

Rajiv_B.L · September 30, 2002, 4:05am

Hi,

Stack dump: dump from your kernel stack, indicates the routines called
sequence. The top most is the last routine called, which was called by
the one below, and so on…

The hex indicates the offset in the code (assembly) of the routine from
where the routine above (in the list) was called.

Good Luck,
Rajiv.

-----Original Message-----
From: Chen [mailto:xxxxx@sina.com]
Sent: Sunday, September 29, 2002 10:30 PM
To: File Systems Developers
Subject: [ntfsd] FS Filter Driver stack dump when BSOD

Hi,

I am writing a file system filter driver, using SoftICE as debugging
tool. I have frequently encountered bugcheck, each time the stack dump
is as
follows:

: stack
xxxxxxxx yyyyyyyy ntoskernel!KeBugCheckEx+0001
xxxxxxxx yyyyyyyy MyDriver!MyDriverRoutine1+007E
xxxxxxxx yyyyyyyy MyDriver!MyDriverRoutine2+004D
xxxxxxxx yyyyyyyy MyDriver!MyDriverRoutine3+001B
xxxxxxxx yyyyyyyy ntoskernel!IoBuildSynchronousFsdRequest+008F
xxxxxxxx yyyyyyyy ntoskernel!ObFindHandleForObject+0607
xxxxxxxx yyyyyyyy ntoskernel!ObOpenObjectByName+00AF
xxxxxxxx yyyyyyyy ntoskernel!IoUpdateShareAccess+02E2

Here, MyDriver is the filter driver, MyDriverRoutine1~3 is functions
implemented in MyDriver.Sys.

My questions are:

What does the stack dump mean?
What the hexes, such as +0001, 007E, etc mean?

Thanks for any instructions.

Chen

You are currently subscribed to ntfsd as: xxxxx@wipro.com To
unsubscribe send a blank email to %%email.unsub%%

OSR_Community_User · September 30, 2002, 6:15am

(1) This is the sequence of function calls, as determined by the debugger.
This would suggest your code has called KeBugCheckEx directly (in
MyDriverRoutine1)

(2) The hex offsets indicate the return instruction of the call. Thus,
where it says “MyDriver!MyDriverRoutine3+001B” it indicates that the
instruction preceding this was a function call (most likely to
MyDriverRoutine2) and when that routine returns, it will continue execution
at the noted instruction. If the transfer of control was because of a
processor trap, then the return instruction is the SAME instruction where
the trap occurred.

I hope that helps.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Chen [mailto:xxxxx@sina.com]
Sent: Sunday, September 29, 2002 1:00 PM
To: File Systems Developers
Subject: [ntfsd] FS Filter Driver stack dump when BSOD

Hi,

I am writing a file system filter driver, using SoftICE as debugging tool.
I have frequently encountered bugcheck, each time the stack dump is as
follows:

: stack
xxxxxxxx yyyyyyyy ntoskernel!KeBugCheckEx+0001
xxxxxxxx yyyyyyyy MyDriver!MyDriverRoutine1+007E
xxxxxxxx yyyyyyyy MyDriver!MyDriverRoutine2+004D
xxxxxxxx yyyyyyyy MyDriver!MyDriverRoutine3+001B
xxxxxxxx yyyyyyyy ntoskernel!IoBuildSynchronousFsdRequest+008F
xxxxxxxx yyyyyyyy ntoskernel!ObFindHandleForObject+0607
xxxxxxxx yyyyyyyy ntoskernel!ObOpenObjectByName+00AF
xxxxxxxx yyyyyyyy ntoskernel!IoUpdateShareAccess+02E2

Here, MyDriver is the filter driver, MyDriverRoutine1~3 is functions
implemented in MyDriver.Sys.

My questions are:

What does the stack dump mean?
What the hexes, such as +0001, 007E, etc mean?

Thanks for any instructions.

Chen

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

OSR_Community_User · October 2, 2002, 5:03am

Hi,

Thanks a lot for all the instructions.

Please see the stack dump again:

xxxxxxxx yyyyyyyy ntoskernel!KeBugCheckEx+0001
xxxxxxxx yyyyyyyy MyDriver!MyDriverRoutine1+007E
xxxxxxxx yyyyyyyy MyDriver!MyDriverRoutine2+004D
xxxxxxxx yyyyyyyy MyDriver!MyDriverRoutine3+001B
xxxxxxxx yyyyyyyy ntoskernel!IoBuildSynchronousFsdRequest+008F
xxxxxxxx yyyyyyyy ntoskernel!ObFindHandleForObject+0607
xxxxxxxx yyyyyyyy ntoskernel!ObOpenObjectByName+00AF
xxxxxxxx yyyyyyyy ntoskernel!IoUpdateShareAccess+02E2

MyDriverRouine1 is defined as follows:

NTSTATUS
GetFullFilePathName(PFILE_OBJECT FileObject,
PHOOK_EXTENSION pHookExt,
CHAR AnsiFileName[520])
{
UNICODE_STRING uszFileName;
ANSI_STRING szFileName;
NTSTATUS nsRet;

if(KeGetCurrentIrql() >= DISPATCH_LEVEL)
return STATUS_UNSUCCESSFUL;

RtlInitUnicodeString(&uszFileName, FileObject->FileName.Buffer);
nsRet = RtlUnicodeStringToAnsiString(&szFileName, &uszFileName, TRUE);
if(!NT_SUCCESS(nsRet))
return STATUS_UNSUCCESSFUL;

RtlZeroMemory(AnsiFileName, 510);
AnsiFileName[0] = pHookExt->LogicalDrive;
AnsiFileName[1] = ‘:’;
RtlCopyMemory(AnsiFileName+2, szFileName.Buffer, 500);
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (MyDriverRoutine1+007E)
MyStringUpper(AnsiFileName);

RtlFreeAnsiString(&szFileName);

return STATUS_SUCCESS;
}

I have found the place of MyDriverRoutine1+007E, the bugcheck code is 50(PAGE_FAULT_IN_NONPAGED_AREA), but I have no idea about why this error should happen.

Thanks again,

Chen

OSR_Community_User · October 2, 2002, 5:20am

Can you create COD files to help you detect which line is causing the
problem?

At any rate, this error can occur even at DISPATCH_LEVEL (irql == 2)
when a piece of memory is in paged pool and you’re touching it here.
For example, is AnsiFileName in paged or non-paged pool?

The best bet to solving this issue (and others that crop up) is to be
able to have WinDbg show the function names by setting the symbol files
and dbg/pdb files up correctly. In lieu of that, use the COD files to
specify the exact line causing the problem.

jb
============================================
Jonathan Borden
L5 Software Group
“All computers wait at the same speed.”

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chen
Sent: Wednesday, October 02, 2002 3:59 AM
To: File Systems Developers
Subject: [ntfsd] RE: FS Filter Driver stack dump when BSOD

Hi,

Thanks a lot for all the instructions.

Please see the stack dump again:

xxxxxxxx yyyyyyyy ntoskernel!KeBugCheckEx+0001
xxxxxxxx yyyyyyyy MyDriver!MyDriverRoutine1+007E
xxxxxxxx yyyyyyyy MyDriver!MyDriverRoutine2+004D
xxxxxxxx yyyyyyyy MyDriver!MyDriverRoutine3+001B
xxxxxxxx yyyyyyyy ntoskernel!IoBuildSynchronousFsdRequest+008F
xxxxxxxx yyyyyyyy ntoskernel!ObFindHandleForObject+0607
xxxxxxxx yyyyyyyy ntoskernel!ObOpenObjectByName+00AF
xxxxxxxx yyyyyyyy ntoskernel!IoUpdateShareAccess+02E2

MyDriverRouine1 is defined as follows:

NTSTATUS
GetFullFilePathName(PFILE_OBJECT FileObject,
PHOOK_EXTENSION pHookExt,
CHAR AnsiFileName[520])
{
UNICODE_STRING uszFileName;
ANSI_STRING szFileName;
NTSTATUS nsRet;

if(KeGetCurrentIrql() >= DISPATCH_LEVEL)
return STATUS_UNSUCCESSFUL;

RtlInitUnicodeString(&uszFileName, FileObject->FileName.Buffer);
nsRet = RtlUnicodeStringToAnsiString(&szFileName, &uszFileName,
TRUE);
if(!NT_SUCCESS(nsRet))
return STATUS_UNSUCCESSFUL;

RtlZeroMemory(AnsiFileName, 510);
AnsiFileName[0] = pHookExt->LogicalDrive;
AnsiFileName[1] = ‘:’;
RtlCopyMemory(AnsiFileName+2, szFileName.Buffer, 500);
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(MyDriverRoutine1+007E)
MyStringUpper(AnsiFileName);

RtlFreeAnsiString(&szFileName);

return STATUS_SUCCESS;
}

I have found the place of MyDriverRoutine1+007E, the bugcheck code is
50(PAGE_FAULT_IN_NONPAGED_AREA), but I have no idea about why this error
should happen.

Thanks again,

Chen

You are currently subscribed to ntfsd as: xxxxx@L5sg.com
To unsubscribe send a blank email to %%email.unsub%%

OSR_Community_User · October 2, 2002, 5:52am

Hi,

Hmm… quite strange code.

CHAR AnsiFileName[520], RtlZeroMemory(AnsiFileName, 510) and
RtlCopyMemory(AnsiFileName+2, szFileName.Buffer, 500)

Anyway…

…

nsRet = RtlUnicodeStringToAnsiString(&szFileName, &uszFileName, TRUE);
…
RtlCopyMemory(AnsiFileName+2, szFileName.Buffer, 500);
…

RtlUnicodeStringToAnsiString allocates buffer of size enough to hold
converted string. It could be less than 500 bytes.

So, check the length and copy only valid data:

if (szFileName.Length < destination buffer length) {
RtlCopyMemory(AnsiFileName+2, szFileName.Buffer, szFileName.Length);
}
else {
return error or copy just part of the name
}
terminate with \0 if necessary

Leonid.