Sometimes system crash when calling FltWrite in pre-create callback function

NTFSD
1

Sometimes, my windows XP x86 system crashes because my minifilter driver. I
simply called FltWrite in pre-create callback function as follow.
I noticed that the system crashed only when the disk is almost out of space
and there is a coming remote desktop connection. If there is enough disk
space (more than 10M) or there is no coming remote desktop connection, the
system won’t crash.

What do can do to prevent the crash? Is it possible to print some trace info
into a file.
MyPreCreate
{
TraceErrorOutput(SYBDBG_TRACE_ROUTINES);

// must set CompletionContext to NULL if return with
FLT_PREOP_SUCCESS_NO_CALLBACK
*CompletionContext = NULL;
}

VOID TraceErrorOutput()
{
FltWriteFile( gContext.Instance,
gContext.trcFileObject,
NULL,
100*sizeof(WCHAR),
gBuf,
0,
NULL,
NULL,
NULL);
return;
}

Where gBuf has already been allocated by
FltAllocatePoolAlignedWithTag(Instance, NonPagedPool, 100*sizeof(WCHAR),
‘abcd’).
Where the file is opened by calling
FltCreateFile( filterHandle,
Instance,
&trcFileHandle,
SYNCHRONIZE | FILE_APPEND_DATA,
&objectAttributes,
&ioStatusBlock,
(PLARGE_INTEGER) NULL,
FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ | FILE_SHARE_WRITE,
FILE_SUPERSEDE,
FILE_NON_DIRECTORY_FILE |
FILE_SYNCHRONOUS_IO_NONALERT,
NULL,
0L,
0 );

STACK_TEXT:
b61862c4 ba6a16ad c000007f 89c7c270 8a498100 nt!ExRaiseStatus+0x82
b61862dc ba6fa3c6 89c7c270 c000007f 00000000 Ntfs!NtfsRaiseStatus+0xa0
b6186410 ba6caea4 89c7c270 8a498100 e2c130d0 Ntfs!NtfsAllocateClusters+0x85f
b61864e0 ba69fe5d 89c7c270 89d2f148 e2c130d0 Ntfs!NtfsAddAllocation+0x31e
b61866e0 ba69dc18 89c7c270 89c8c4d0 00000000 Ntfs!NtfsCommonWrite+0x12df
b6186744 804e37f7 8a498020 89c8c4d0 89c8c4d0 Ntfs!NtfsFsdWrite+0xf3
b6186754 ba743e9b 00000000 8a2abf5c 00000000 nt!IopfCallDriver+0x31
b6186778 ba7449e5 b6186798 89bd0188 00000000
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
b61867b0 ba7450b2 89bb3a50 89c91fb4 89c91e70
fltmgr!FltPerformSynchronousIo+0xb9
b6186818 b641e72b 89bb3a50 89d2f148 00000000 fltmgr!FltWriteFile+0x286
b6186880 b641e2dc 00000001 00000001 00000000 myfilter!TraceErrorOutput+0xbb
b61876b0 ba741888 89d0b3fc b61876d0 b6187700 myfilter!MyPreCreate+0x1c
b6187710 ba7432a0 00187754 89d0b3a0 89bb44fc
fltmgr!FltpPerformPreCallbacks+0x2d4
b6187724 ba750217 b6187754 ba74e6aa 00000000
fltmgr!FltpPassThroughInternal+0x32
b618773c ba750742 b6187754 89d18f10 89bb43a0 fltmgr!FltpCreateInternal+0x63
b6187770 804e37f7 8a2b8020 89bb4390 89bb4390 fltmgr!FltpCreate+0x258
b6187780 8056c712 8a758c80 8a316304 b6187928 nt!IopfCallDriver+0x31
b6187860 80563fec 8a758c98 00000000 8a316260 nt!IopParseDevice+0xa12
b61878e8 805684da 00000000 b6187928 00000240 nt!ObpLookupObjectName+0x56a
b618793c 8056cbeb 00000000 00000000 d1f85800 nt!ObOpenObjectByName+0xeb
b61879b8 8056ccba b6187b80 00100001 b6187b58 nt!IopCreateFile+0x407
b6187a14 8056cdf0 b6187b80 00100001 b6187b58 nt!IoCreateFile+0x8e
b6187a54 804de7ec b6187b80 00100001 b6187b58 nt!NtCreateFile+0x30
b6187a54 804dc9b1 b6187b80 00100001 b6187b58 nt!KiFastCallEntry+0xf8
b6187af8 bf84fbcf b6187b80 00100001 b6187b58 nt!ZwCreateFile+0x11
b6187dc8 bf84f822 000004e4 b6187e48 000001c0
win32k!ConvertToAndFromWideChar+0x17f
b6187de8 bf84f9a3 000004e4 b6187e48 000001c0
win32k!EngMultiByteToWideChar+0x1b
b6187e18 bf891317 000004e4 20000020 000000e0
win32k!cUnicodeRangesSupported+0x106
b61883ec bf8919dc bf9a933c 00000020 000000ff win32k!pcpComputeGlyphset+0x89
b6188414 bf89191c 004b0000 00003260 b6188460 win32k!bConvertFontRes+0x68
b6188594 bf8914b9 e2bf65f0 004b0000 00003260 win32k!bBmfdLoadFont+0x2e1
b61885dc bf87fe68 00000001 e2bf65e8 e2f27e20 win32k!BmfdLoadFontFileTE+0x3c
b618860c bf880cc3 00000001 e2bf65e8 e2f27e20
win32k!PDEVOBJ::LoadFontFile+0x3a
b6188644 bf880159 b618870c 0000001e e2bf65e8 win32k!vLoadFontFileView+0x94
b61886c0 bf89b81b b618870c 0000001e 00000001
win32k!PUBLIC_PFTOBJ::bLoadFonts+0x1da
b618891c bf9aeb71 e2b34008 b6188944 00000002
win32k!PUBLIC_PFTOBJ::bLoadAFont+0x77
b6188af0 bf9aeb20 e2b34008 00000001 0000000d
win32k!bInitOneStockFontInternal+0x42
b6188b0c bf9ae916 bf9963e4 00000001 0000000d win32k!bInitOneStockFont+0x3f
b6188cf4 bf9ae833 bf996430 bf89c7cc 0015fd98
win32k!bInitStockFontsInternal+0x12a
b6188cfc bf89c7cc 0015fd98 bf9af0da 00000000 win32k!bInitStockFonts+0xa
b6188d48 bf89c65d b6188d64 804de7ec 00050000 win32k!InitializeGreCSRSS+0x144
b6188d50 804de7ec 00050000 00000058 0000005c win32k!NtUserInitialize+0x62
b6188d50 7c90e4f4 00050000 00000058 0000005c nt!KiFastCallEntry+0xf8
0015fd80 75b686df 75b68669 00050000 00000058 ntdll!KiFastSystemCallRet
0015fdb0 75b43472 00000000 00000000 0016273d winsrv!NtUserInitialize+0xc
0015fe20 75b4301b 0016271a 00162721 00000003 CSRSRV!CsrLoadServerDll+0x1a0
0015ff74 75b430f3 0000000a 00162438 7c90dc80
CSRSRV!CsrParseServerCommandLine+0x2d6
0015ff88 4a68115d 0000000a 00162438 00000005
CSRSRV!CsrServerInitialization+0x95
0015ffa8 4a6818d7 0000000a 00162438 00162464 csrss!main+0x4f
0015fff4 00000000 7ffdd000 000000c8 000001f1 csrss!NtProcessStartup+0x1d2

2

Is there anybody knows the problems? Thanks very much.
By the way, gContext.Instance is assigned in instance setup function.

3

AFAIK if system disk has less than 10 MB of free space it usually means
short path to crash.

wrote in message news:xxxxx@ntfsd…
> Is there anybody knows the problems? Thanks very much.
> By the way, gContext.Instance is assigned in instance setup function.
>

4

Anything that crashes in such a situation is buggy. What crashes are you observing?

? S

-----Original Message-----
From: Jan Milan
Sent: Wednesday, January 14, 2009 08:20
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Sometimes system crash when calling FltWrite in pre-create callback function

AFAIK if system disk has less than 10 MB of free space it usually means
short path to crash.

wrote in message news:xxxxx@ntfsd…
> Is there anybody knows the problems? Thanks very much.
> By the way, gContext.Instance is assigned in instance setup function.
>

—
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@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Hi, Jan and Ken

Thanks for your reponse very much. There some info from me to reponse to you.

  1. If the disk is full, but I do not do remote desktop connection from other machine, the system won’t crash. I traced the return value of function FltWriteFile, it returns the STATUS_DISK_FULL. But it does not lead system crash. Only after there is a coming remote desktop connection, will the system crash.
  2. In the stack trace, we can see the crash happens when the system calls FltWriteFile.
  3. The Instance passed to FltWriteFile is obtained during Instance Setup. It should be correct becasue the data are written into the file.
  4. The Instance passed to FltWriteFile may not be the Instance in FltObjects passed in pre-create callback becasue I want to write the trace info into a trace file which may be in a different volume from current volume during pre-create. Is there any problem?
  5. Is there any info I can provide?
6

Actually, my requirement is very simple. In pre-create callback, write a trace info into a file which is opened during the instance where the trace file is located is setup.
Do you know whether it is a feasible task in minifilter driver?

7

Hi,
if system run out of disk space it may soon run out of memory too. Remote
desktop connection connect new user on machine and so it takes a big piece
of memory. Allocation of memory then return NULL. If application is buggy
and does not handle that state then crash is matter of ms.
You should check all allocation paths that the shortage of memory is handled
corectly.

wrote in message news:xxxxx@ntfsd…
> Hi, Jan and Ken
>
> Thanks for your reponse very much. There some info from me to reponse to
you.
>
> 1. If the disk is full, but I do not do remote desktop connection from
other machine, the system won’t crash. I traced the return value of function
FltWriteFile, it returns the STATUS_DISK_FULL. But it does not lead system
crash. Only after there is a coming remote desktop connection, will the
system crash.
> 2. In the stack trace, we can see the crash happens when the system calls
FltWriteFile.
> 3. The Instance passed to FltWriteFile is obtained during Instance Setup.
It should be correct becasue the data are written into the file.
> 4. The Instance passed to FltWriteFile may not be the Instance in
FltObjects passed in pre-create callback becasue I want to write the trace
info into a trace file which may be in a different volume from current
volume during pre-create. Is there any problem?
> 5. Is there any info I can provide?
>

8

I’v checked the memory allocation code. No memory cases are handled. I think the memory is enough bacuase when the system crash, sometimes, the disk is not full (100K+ left).

In the stack trace, we can see the crash is caused by calling FltWriteFile in my driver myfilter.

b6186818 b641e72b 89bb3a50 89d2f148 00000000 fltmgr!FltWriteFile+0x286
b6186880 b641e2dc 00000001 00000001 00000000 myfilter!TraceErrorOutput+0xbb
b61876b0 ba741888 89d0b3fc b61876d0 b6187700 myfilter!MyPreCreate+0x1c

My question is whehter it is possible to save the instance attached to a volume during its instance setup and use it to call FltWriteFile in the pre create callback for another volume/instance.

9

The instance remains valid only if you have a acquired a reference on
the instance - else it could go away at any time - volume teardown,
filter detach, etc.

If you are holding on to a reference to any object, you are now in the
lifetime management path for that object. If you leak that reference
then the object will never teardown. If you release it more than once
then you will bugcheck pretty quick.

Regards,
Sarosh.
File System Filter Lead
Microsoft Corp

This posting is provided “AS IS” with no warranties, and confers no Rights

xxxxx@gmail.com wrote:

I’v checked the memory allocation code. No memory cases are handled. I think the memory is enough bacuase when the system crash, sometimes, the disk is not full (100K+ left).

In the stack trace, we can see the crash is caused by calling FltWriteFile in my driver myfilter.

b6186818 b641e72b 89bb3a50 89d2f148 00000000 fltmgr!FltWriteFile+0x286
b6186880 b641e2dc 00000001 00000001 00000000 myfilter!TraceErrorOutput+0xbb
b61876b0 ba741888 89d0b3fc b61876d0 b6187700 myfilter!MyPreCreate+0x1c

My question is whehter it is possible to save the instance attached to a volume during its instance setup and use it to call FltWriteFile in the pre create callback for another volume/instance.

10

Thanks Sarosh’s reply.
When I first saw bluescreen and the stack trace, I also suspect it was caused by the instance was changed. So I set break point in InstanceSetup, InstanceQueryTeardown and Unload callback function. But after I do remote desktop form another machine and the blue screen happens, Windows does not call these 3 functions at all. Can I say the instance is not changed before bluescreen?

I really hold a global reference to the instance to the volume and never free it.

In InstanceSetupFunction, I set gInstance = FltObjects->Instance when the volume is the trace file located. In pre create function, I did very simple function like:

FLT_PREOP_CALLBACK_STATUS MyPreCreate (…)
{
TraceErrorOutput1();
*CompletionContext = NULL;
TraceErrorOutput1();
return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

VOID TraceErrorOutput1()
{
WCHAR *buf;

// Do some check here
…

buf = (WCHAR *)FltAllocatePoolAlignedWithTag(gInstance, NonPagedPool, 100*sizeof(WCHAR), FILE_NAME_TAG);
if(buf == NULL)
return;

RtlStringCbPrintfW( buf, 100*sizeof(WCHAR), L"abcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefg\n");

FltWriteFile( gInstance,
gContext.trcFileObject,
NULL,
100*sizeof(WCHAR),
buf,
0,
NULL,
NULL,
NULL);

FltFreePoolAlignedWithTag(gInstance, buf, FILE_NAME_TAG);

return;
}

11

Is there anybody can help me? Thanks in advance!

12

Hi,
you should consider to set up debug enviroment.

Writing to a file is feasible in pre-create. The hard task is to synchronize
access to it. There is an example for that in WDK how to do that (the name
is “meta…” - don’t remember exactly :slight_smile: ).

If TraceErrorOutput1 is called only in pre-create path you should use
PagePool instead of NonPagedPool when allocating memory.

To acquire a refence on instance you should call FltObjectReference. Don’t
forget to realease it then by calling FltObjectDereference.

If you allocate buffer which size is at least PAGE_SIZE you may not bother
about aligning it thus you won’t need to call FltAllocatePoolAlignedWithTag.

wrote in message news:xxxxx@ntfsd…
> Thanks Sarosh’s reply.
> When I first saw bluescreen and the stack trace, I also suspect it was
caused by the instance was changed. So I set break point in InstanceSetup,
InstanceQueryTeardown and Unload callback function. But after I do remote
desktop form another machine and the blue screen happens, Windows does not
call these 3 functions at all. Can I say the instance is not changed before
bluescreen?
>
> I really hold a global reference to the instance to the volume and never
free it.
>
> In InstanceSetupFunction, I set gInstance = FltObjects->Instance when the
volume is the trace file located. In pre create function, I did very simple
function like:
>
> FLT_PREOP_CALLBACK_STATUS MyPreCreate (…)
> {
> TraceErrorOutput1();
> CompletionContext = NULL;
> TraceErrorOutput1();
> return FLT_PREOP_SUCCESS_NO_CALLBACK;
> }
>
> VOID TraceErrorOutput1()
> {
> WCHAR buf;
>
> // Do some check here
> …
>
> buf = (WCHAR )FltAllocatePoolAlignedWithTag(gInstance, NonPagedPool,
100sizeof(WCHAR), FILE_NAME_TAG);
> if(buf == NULL)
> return;
>
> RtlStringCbPrintfW( buf, 100sizeof(WCHAR),
L"abcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcdefgabcd
efgabcdefgabcdefgabcdefg\n");
>
> FltWriteFile( gInstance,
> gContext.trcFileObject,
> NULL,
> 100sizeof(WCHAR),
> buf,
> 0,
> NULL,
> NULL,
> NULL);
>
> FltFreePoolAlignedWithTag(gInstance, buf, FILE_NAME_TAG);
>
> return;
> }
>
>

13

Thanks Jan’s info.

Actually, I have debug enironment and have been debugging it for a long time.

I sync the write process by adding ExAcquireFastMutex/ExReleaseFastMutex before and after FltWriteFile. But the bluescreen still happens when I do remote desktop connection.

I called FltObjectReference in instance setup function to reference gContext.Instance, and dereference it in MiniFilterUnload function. But this cannot prevent bluescreen.

I also use PagedPool instead PagePool but it does change anything.

I read MetadataManager source code, but it does not call FltWriteFile which caused bluescreen in my code. And more important, in MetadataManager, every volume has a meta file while in my code, there is only one file stored in one specified volume. In precreate callback, I always need to write data to the same opened file which may not be in the current volume.

14

Hi,
So send more info about bugcheck (use analyze -v).

Metadatamanager release resource when preforming file system operation. You
should not hold lock while running FltWriteFile since deadlock may occur.
That’s why synchronize access to file is hard. You may however set up some
rule how the threads will access the file (e.g. watermark or every thread
has own space and so on). Another problem is that ExAcquireFastMutex will
raise level to APC_LEVEL and FltWriteFile should be called at passive level.

I recommend you to go through Metadatamanager code until you understad it.
It is basic template which you should have implemented when working with
metafile. It does not matter if it reside on every volume or only on one.

Jan

wrote in message news:xxxxx@ntfsd…
> Thanks Jan’s info.
>
> Actually, I have debug enironment and have been debugging it for a long
time.
>
> I sync the write process by adding ExAcquireFastMutex/ExReleaseFastMutex
before and after FltWriteFile. But the bluescreen still happens when I do
remote desktop connection.
>
> I called FltObjectReference in instance setup function to reference
gContext.Instance, and dereference it in MiniFilterUnload function. But this
cannot prevent bluescreen.
>
> I also use PagedPool instead PagePool but it does change anything.
>
> I read MetadataManager source code, but it does not call FltWriteFile
which caused bluescreen in my code. And more important, in MetadataManager,
every volume has a meta file while in my code, there is only one file stored
in one specified volume. In precreate callback, I always need to write data
to the same opened file which may not be in the current volume.
>
>
>

15

Hi, Jan

Here is the output of “!analyze -v”. naiavf5x.sys is a McAfee file which is verified no matter with this crash. I unistalled McAfee on another machine and the same crash happened.

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a trap of a kind
that the kernel isn’t allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 80042000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

BUGCHECK_STR: 0x7f_8

TSS: 00000028 – (.tss 28)
eax=a994bfbc ebx=c000007f ecx=baea0e4b edx=00000000 esi=893a32e0 edi=00000100
eip=804dc677 esp=a994bfbc ebp=a994c2e0 iopl=3 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00013282
nt!ExRaiseStatus+0x91:
804dc677 89480c mov [eax+0xc],ecx
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from baea0e4b to 804dc677

STACK_TEXT:
a994c2e0 baea0e4b c000007f 893a32e0 894d8330 nt!ExRaiseStatus+0x91
a994c2f8 baefa169 893a32e0 c000007f 00000000 Ntfs!NtfsRaiseStatus+0xa0
a994c42c baecaca2 893a32e0 894d8330 e40dda50 Ntfs!NtfsAllocateClusters+0x85f
a994c4fc bae9f9ba 893a32e0 88ee1408 e40dda50 Ntfs!NtfsAddAllocation+0x31e
a994c700 bae9dc24 893a32e0 89412840 89412840 Ntfs!NtfsCommonWrite+0x12df
a994c764 804e37f7 894d8250 89412840 894bcac0 Ntfs!NtfsFsdWrite+0xf3
a994c774 a971a97e 00000000 8950d6f8 8935bbc0 nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may be wrong.
a994c7a4 a9714940 88ee1408 00000000 894d0238 naiavf5x+0x897e
a994c7b8 804e37f7 89481ce0 89412840 89412840 naiavf5x+0x2940
a994c7c8 baf43e9b 00000000 8935bc1c 00000000 nt!IopfCallDriver+0x31
a994c7ec baf449e5 a994c80c 88fa1498 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
a994c824 baf44d5d 88ef59e8 88ee4ccc 88ee4b88 fltMgr!FltPerformSynchronousIo+0xb9
a994c850 ace4f512 8935bc1c 00ee1408 00000000 fltMgr!FltWriteFile+0x105
a994c880 ace51851 88ee4b88 00000000 00000000 myfilter!TraceErrorOutput1+0x92 [e:\work\drivers\myfilter\myerr.c @ 202]
a994d6b0 baf41888 88f343b4 a994d6d0 a994d700 myfilter!MyPreCreate+0x21 [e:\work\drivers\myfilter\myfilter.c @ 778]
a994d710 baf432a0 0094d754 88f34358 88f03da8 fltMgr!FltpPerformPreCallbacks+0x2d4
a994d724 baf4ff17 a994d754 baf4e3aa 00000000 fltMgr!FltpPassThroughInternal+0x32
a994d73c baf50436 a994d754 8903eef8 88f03c28 fltMgr!FltpCreateInternal+0x63
a994d770 804e37f7 88f2bac8 88f03c18 88f03c18 fltMgr!FltpCreate+0x258
a994d780 8056f5ca 89c17250 8933f254 a994d928 nt!IopfCallDriver+0x31
a994d860 805633ec 89c17268 00000000 8933f1b0 nt!IopParseDevice+0xa12
a994d8e8 8056751a 00000000 a994d928 00000240 nt!ObpLookupObjectName+0x56a
a994d93c 8056faa3 00000000 00000000 478da000 nt!ObOpenObjectByName+0xeb
a994d9b8 8056fb72 a994db80 00100001 a994db58 nt!IopCreateFile+0x407
a994da14 8056fca8 a994db80 00100001 a994db58 nt!IoCreateFile+0x8e
a994da54 804de7ec a994db80 00100001 a994db58 nt!NtCreateFile+0x30
a994da54 804dc9b1 a994db80 00100001 a994db58 nt!KiFastCallEntry+0xf8
a994daf8 bf8affc6 a994db80 00100001 a994db58 nt!ZwCreateFile+0x11
a994ddc8 bf8afc19 000004e4 a994de48 000001c0 win32k!ConvertToAndFromWideChar+0x17f
a994dde8 bf8afd9a 000004e4 a994de48 000001c0 win32k!EngMultiByteToWideChar+0x1b
a994de18 bf8926f1 000004e4 20000020 000000e0 win32k!cUnicodeRangesSupported+0x106
a994e3ec bf892db6 bf9a9154 00000020 000000ff win32k!pcpComputeGlyphset+0x89
a994e414 bf892cf6 004c0000 00003260 a994e460 win32k!bConvertFontRes+0x68
a994e594 bf892893 e1076220 004c0000 00003260 win32k!bBmfdLoadFont+0x2e1
a994e5dc bf881286 00000001 e1076218 e11b94b8 win32k!BmfdLoadFontFileTE+0x3c
a994e60c bf8820e1 00000001 e1076218 e11b94b8 win32k!PDEVOBJ::LoadFontFile+0x3a
a994e644 bf881577 a994e70c 0000001e e1076218 win32k!vLoadFontFileView+0x94
a994e6c0 bf89cbd8 a994e70c 0000001e 00000001 win32k!PUBLIC_PFTOBJ::bLoadFonts+0x1da
a994e91c bf9ae97f e40c4008 a994e944 00000002 win32k!PUBLIC_PFTOBJ::bLoadAFont+0x77
a994eaf0 bf9ae92e e40c4008 00000001 0000000d win32k!bInitOneStockFontInternal+0x42
a994eb0c bf9ae724 bf996214 00000001 0000000d win32k!bInitOneStockFont+0x3f
a994ecf4 bf9ae641 bf996260 bf89db89 0015fd98 win32k!bInitStockFontsInternal+0x12a
a994ecfc bf89db89 0015fd98 bf9aeee8 00000000 win32k!bInitStockFonts+0xa
a994ed48 bf89da1a a994ed64 804de7ec 00050000 win32k!InitializeGreCSRSS+0x144
a994ed50 804de7ec 00050000 00000058 0000005c win32k!NtUserInitialize+0x62
a994ed50 7c90eb94 00050000 00000058 0000005c nt!KiFastCallEntry+0xf8
0015fd80 75b686d7 75b68661 00050000 00000058 ntdll!KiFastSystemCallRet
0015fdb0 75b43472 00000000 00000000 00162725 winsrv!NtUserInitialize+0xc
0015fe20 75b4301b 00162702 00162709 00000003 CSRSRV!CsrLoadServerDll+0x1a0
0015ff74 75b430f3 0000000a 00162438 7c90e62d CSRSRV!CsrParseServerCommandLine+0x2d6

FOLLOWUP_IP:
naiavf5x+897e
a971a97e 5f pop edi

SYMBOL_STACK_INDEX: 7

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: naiavf5x+897e

MODULE_NAME: naiavf5x

IMAGE_NAME: naiavf5x.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 46e85c88

STACK_COMMAND: .tss 28 ; kb

BUCKET_ID: 0x7f_8_naiavf5x+897e

Followup: MachineOwner

16

Well, that makes it easy.

0x7F, with param 1 = 8 is almost always a stack overflow (I don’t think
I’ve ever seen a case when it isn’t, in fact.)

I did some quick arithmetic. Your two routines are using almost 4K of
stack. Given that there may only be 12K of stack, using 1/3 of it just
seems to be asking for trouble. Of course, if others don’t use much
stack, you get away with it. If they need a bit more, you crash.

My advice would be to stop using so much stack space. Move your
automatic variables into pool. Don’t put buffers on the stack.

Tony
OSR

17

Hi, Tony

Great! I removed two array in MyPreCreate function and no crash anymore! Thanks very much! By the way, how to calcualate that 4K of stack is used up by two rountines?

18

You can use the ‘kfn’ command in the debugger to have it compute the difference for you, or you could just manually subtract the difference between stack pointers for each frame.

  • S

-----Original Message-----
From: xxxxx@gmail.com
Sent: Thursday, February 12, 2009 23:35
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Sometimes system crash when calling FltWrite in pre-create callback function

Hi, Tony

Great! I removed two array in MyPreCreate function and no crash anymore! Thanks very much! By the way, how to calcualate that 4K of stack is used up by two rountines?

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

19

Run prefast on the driver. It tells you when you exceed 1KB by default and
that can be overridden to make it smaller. It is function by function, so
deeply nested calls can quickly accumulate. There are system calls
available that let you know how much stack is available so you could put
those in the checked build to display an error and breakpoint at that
location. I think no single function should have more than 256 bytes used,
except in special cases such as DriverEntry for a PnP/miniport driver where
you won’t be calling a bunch of other stuff or down into other drivers.

“Skywing” wrote in message news:xxxxx@ntfsd…
You can use the ‘kfn’ command in the debugger to have it compute the
difference for you, or you could just manually subtract the difference
between stack pointers for each frame.

- S

-----Original Message-----
From: xxxxx@gmail.com
Sent: Thursday, February 12, 2009 23:35
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Sometimes system crash when calling FltWrite in
pre-create callback function

Hi, Tony

Great! I removed two array in MyPreCreate function and no crash anymore!
Thanks very much! By the way, how to calcualate that 4K of stack is used up
by two rountines?

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

20

Hi, Tony

Great! After I remove an big array (> 1k) in MyPreCreate, the crash does not happend again. Thanks very much!
By the way, could you tell me how to determine that the stack is used up 4K by 2 rountines?