Crash Dump in PreCreate Operation

NTFSD
1

Hi All,

I am developing a mini-filter.In my PreCreate Operation,i got crash dump.

My Pseudo Code:

PreCreate()
{
HANDLE hFileHandle = NULL;
PFILE_OBJECT pobjFileObject = NULL;
OBJECT_ATTRIBUTES objectAttributes;

try
{
InitializeObjectAttributes(&objectAttributes,
&FileName,
OBJ_KERNEL_HANDLE,
NULL,
NULL);

status = FltCreateFile(gFilterHandle,
FltObjects->Instance,
&hFileHandle,
FILE_READ_DATA,
&objectAttributes,
&ioStatus,
(PLARGE_INTEGER) NULL,
FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ,
FILE_OPEN,
0L,
NULL,
0L,
0);

if(STATUS_SUCCESS != status)
{
leave;
}

status = ObReferenceObjectByHandle(hFileHandle,
STANDARD_RIGHTS_REQUIRED,
*IoFileObjectType,
KernelMode,
&pobjFileObject,
NULL);

if(STATUS_SUCCESS != status)
{
leave;
}

}
finally
{
if(hFileHandle)
{
//Here Crash occurs
FltClose(hFileHandle);
hFileHandle = NULL;
}
if(pobjFileObject)
{
ObDereferenceObject(pobjFileObject);
pobjFileObject = NULL;
}
}
}

The pobjFileObject parameter has different value in try block and when it leaves try block and goes to finally block it has some different value.
Why the value of pobjFileObject changes?

Following is the Crash Dump:

Bug Check 0x6: INVALID_PROCESS_DETACH_ATTEMPT

f5e10798 8080c77e 00000006 84980020 f5e107ec nt!KeBugCheck+0x14

f5e107b8 8091bef3 f5e107d0 f5e10808 f5e10884 nt!KeUnstackDetachProcess+0x10b

f5e107ec 80905562 00000294 00000000 f5e10808 nt!ObpCloseHandle+0xb5

f5e107fc 8082337b 80000294 f5e10924 8082138c nt!NtClose+0x1b

f5e107fc 8082138c 80000294 f5e10924 8082138c nt!KiFastCallEntry+0xf8

f5e10878 f72a9621 80000294 f72a95aa 8518dee4 nt!ZwClose+0x11

f5e10880 f72a95aa 8518dee4 8518dda0 851c92f0 testFilter!PreCreate+0x7e1

f5e10924 f734d4e8 851c934c f5e10944 f5e10960 testFilter!PreCreate+0x76a

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

f5e10984 f734ef48 00e109c8 851c92f0 851d2548 fltmgr+0x24e8

f5e10998 f735d0ad f5e109c8 f735b540 00000000 fltmgr+0x3f48

f5e109b0 f735d59d f5e109c8 851d23b8 851d2564 fltmgr+0x120ad

f5e109e4 80828c93 84d03e58 851d23b8 00000000 fltmgr+0x1259d

f5e109f8 f769e934 84bb3478 8507e0a8 84b6df08 nt!IofCallDriver+0x45

f5e10a5c 80828c93 84d33b98 00000000 851d23b8 TmPreFlt!TmpQueryFullName+0x5ba4

f5e10a70 80907bea f5e10c18 84d33018 00000000 nt!IofCallDriver+0x45

f5e10b58 80902f9d 84d33030 00000000 8494d008 nt!IopParseDevice+0xa35

f5e10bd8 80906a05 00000000 f5e10c18 00000040 nt!ObpLookupObjectName+0x5a9

f5e10c2c 8090612b 00000000 00000000 3f100001 nt!ObOpenObjectByName+0xea

f5e10ca8 8092b2b0 000f288c c1150000 000f27e0 nt!IopCreateFile+0x447

f5e10d04 8091bd20 000f288c c1150000 000f27e0 nt!IoCreateFile+0xa3

f5e10d44 8082337b 000f288c c1150000 000f27e0 nt!NtOpenFile+0x27

f5e10d44 7c82ed54 000f288c c1150000 000f27e0 nt!KiFastCallEntry+0xf8

000f2af8 501667af 0717d52c 000f2b28 00000000 ntdll!KiFastSystemCallRet

000f2d38 501668e8 010a4f58 0717d52c 000f2d70 msenv!DllCanUnloadNow+0x48e58

000f2d80 500e1cc1 010968e0 0717d52c 00000001 msenv!DllCanUnloadNow+0x48f91

000f2da4 500e1f03 00000001 0717d52c 00000000 msenv!DllGetClassObject+0x23ea9

000f2e14 50166ce4 00000002 010968e0 0717d52c msenv!DllGetClassObject+0x240eb

000f2e30 50166c67 009f2e68 00000002 010968e0 msenv!DllCanUnloadNow+0x4938d

000f2e88 78134bbe 259c64a4 00000001 0a659980 msenv!DllCanUnloadNow+0x49310

000f2e88 78134bbe 259c64a4 00000001 0a659980 MSVCR80!free+0xec

000f2e88 78134bbe 259c64a4 00000001 0a659980 MSVCR80!free+0xec

Thanks in Advance
Anand.

2

  1. You should not use (STATUS_SUCCESS != status), use NT_SUCCESS(status)

  2. There may be situations where FltCreateFile will return an invalid file handle, which is -1 (not NULL). You should check for
    that as well.

  3. The “Bug Check 0x6: INVALID_PROCESS_DETACH_ATTEMPT” is strange – not sure why your code would cause that…

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@rediff.com
Sent: Wednesday, June 06, 2007 12:06 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Crash Dump in PreCreate Operation

Hi All,

I am developing a mini-filter.In my PreCreate Operation,i got crash dump.

My Pseudo Code:

PreCreate()
{
HANDLE hFileHandle = NULL;
PFILE_OBJECT pobjFileObject = NULL;
OBJECT_ATTRIBUTES objectAttributes;

try
{
InitializeObjectAttributes(&objectAttributes,
&FileName,
OBJ_KERNEL_HANDLE,
NULL,
NULL);

status = FltCreateFile(gFilterHandle,
FltObjects->Instance,
&hFileHandle,
FILE_READ_DATA,
&objectAttributes,
&ioStatus,
(PLARGE_INTEGER) NULL,
FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ,
FILE_OPEN,
0L,
NULL,
0L,
0);

if(STATUS_SUCCESS != status)
{
leave;
}

status = ObReferenceObjectByHandle(hFileHandle,
STANDARD_RIGHTS_REQUIRED,
*IoFileObjectType,
KernelMode,
&pobjFileObject,
NULL);

if(STATUS_SUCCESS != status)
{
leave;
}

}
finally
{
if(hFileHandle)
{
//Here Crash occurs
FltClose(hFileHandle);
hFileHandle = NULL;
}
if(pobjFileObject)
{
ObDereferenceObject(pobjFileObject);
pobjFileObject = NULL;
}
}
}

The pobjFileObject parameter has different value in try block and when it leaves try block and goes to finally block it has some
different value.
Why the value of pobjFileObject changes?

Following is the Crash Dump:

Bug Check 0x6: INVALID_PROCESS_DETACH_ATTEMPT

f5e10798 8080c77e 00000006 84980020 f5e107ec nt!KeBugCheck+0x14

f5e107b8 8091bef3 f5e107d0 f5e10808 f5e10884 nt!KeUnstackDetachProcess+0x10b

f5e107ec 80905562 00000294 00000000 f5e10808 nt!ObpCloseHandle+0xb5

f5e107fc 8082337b 80000294 f5e10924 8082138c nt!NtClose+0x1b

f5e107fc 8082138c 80000294 f5e10924 8082138c nt!KiFastCallEntry+0xf8

f5e10878 f72a9621 80000294 f72a95aa 8518dee4 nt!ZwClose+0x11

f5e10880 f72a95aa 8518dee4 8518dda0 851c92f0 testFilter!PreCreate+0x7e1

f5e10924 f734d4e8 851c934c f5e10944 f5e10960 testFilter!PreCreate+0x76a

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

f5e10984 f734ef48 00e109c8 851c92f0 851d2548 fltmgr+0x24e8

f5e10998 f735d0ad f5e109c8 f735b540 00000000 fltmgr+0x3f48

f5e109b0 f735d59d f5e109c8 851d23b8 851d2564 fltmgr+0x120ad

f5e109e4 80828c93 84d03e58 851d23b8 00000000 fltmgr+0x1259d

f5e109f8 f769e934 84bb3478 8507e0a8 84b6df08 nt!IofCallDriver+0x45

f5e10a5c 80828c93 84d33b98 00000000 851d23b8 TmPreFlt!TmpQueryFullName+0x5ba4

f5e10a70 80907bea f5e10c18 84d33018 00000000 nt!IofCallDriver+0x45

f5e10b58 80902f9d 84d33030 00000000 8494d008 nt!IopParseDevice+0xa35

f5e10bd8 80906a05 00000000 f5e10c18 00000040 nt!ObpLookupObjectName+0x5a9

f5e10c2c 8090612b 00000000 00000000 3f100001 nt!ObOpenObjectByName+0xea

f5e10ca8 8092b2b0 000f288c c1150000 000f27e0 nt!IopCreateFile+0x447

f5e10d04 8091bd20 000f288c c1150000 000f27e0 nt!IoCreateFile+0xa3

f5e10d44 8082337b 000f288c c1150000 000f27e0 nt!NtOpenFile+0x27

f5e10d44 7c82ed54 000f288c c1150000 000f27e0 nt!KiFastCallEntry+0xf8

000f2af8 501667af 0717d52c 000f2b28 00000000 ntdll!KiFastSystemCallRet

000f2d38 501668e8 010a4f58 0717d52c 000f2d70 msenv!DllCanUnloadNow+0x48e58

000f2d80 500e1cc1 010968e0 0717d52c 00000001 msenv!DllCanUnloadNow+0x48f91

000f2da4 500e1f03 00000001 0717d52c 00000000 msenv!DllGetClassObject+0x23ea9

000f2e14 50166ce4 00000002 010968e0 0717d52c msenv!DllGetClassObject+0x240eb

000f2e30 50166c67 009f2e68 00000002 010968e0 msenv!DllCanUnloadNow+0x4938d

000f2e88 78134bbe 259c64a4 00000001 0a659980 msenv!DllCanUnloadNow+0x49310

000f2e88 78134bbe 259c64a4 00000001 0a659980 MSVCR80!free+0xec

000f2e88 78134bbe 259c64a4 00000001 0a659980 MSVCR80!free+0xec

Thanks in Advance
Anand.

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

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

3

is it really needed to open the file in pre-operation callback? Why don’t
you move your code to post-operation when the file will be already opened
for you? Then, optionally, you may call FltCancelFileOpen, but don’t open
the file twice: open operation is very slow.

Petr

wrote in message news:xxxxx@ntfsd…
> Hi All,
>
> I am developing a mini-filter.In my PreCreate Operation,i got crash dump.
>
>
> My Pseudo Code:
>
> PreCreate()
> {
> HANDLE hFileHandle = NULL;
> PFILE_OBJECT pobjFileObject = NULL;
> OBJECT_ATTRIBUTES objectAttributes;
>
> try
> {
> InitializeObjectAttributes(&objectAttributes,
> &FileName,
> OBJ_KERNEL_HANDLE,
> NULL,
> NULL);
>
> status = FltCreateFile(gFilterHandle,
> FltObjects->Instance,
> &hFileHandle,
> FILE_READ_DATA,
> &objectAttributes,
> &ioStatus,
> (PLARGE_INTEGER) NULL,
> FILE_ATTRIBUTE_NORMAL,
> FILE_SHARE_READ,
> FILE_OPEN,
> 0L,
> NULL,
> 0L,
> 0);
>
> if(STATUS_SUCCESS != status)
> {
> leave;
> }
>
> status = ObReferenceObjectByHandle(hFileHandle,
> STANDARD_RIGHTS_REQUIRED,
> *IoFileObjectType,
> KernelMode,
> &pobjFileObject,
> NULL);
>
> if(STATUS_SUCCESS != status)
> {
> leave;
> }
>
> }
> finally
> {
> if(hFileHandle)
> {
> //Here Crash occurs
> FltClose(hFileHandle);
> hFileHandle = NULL;
> }
> if(pobjFileObject)
> {
> ObDereferenceObject(pobjFileObject);
> pobjFileObject = NULL;
> }
> }
> }
>
>
> The pobjFileObject parameter has different value in try block and when it
> leaves try block and goes to finally block it has some different value.
> Why the value of pobjFileObject changes?
>
>
>
>
> Following is the Crash Dump:
>
> Bug Check 0x6: INVALID_PROCESS_DETACH_ATTEMPT
>
> f5e10798 8080c77e 00000006 84980020 f5e107ec nt!KeBugCheck+0x14
>
> f5e107b8 8091bef3 f5e107d0 f5e10808 f5e10884
> nt!KeUnstackDetachProcess+0x10b
>
> f5e107ec 80905562 00000294 00000000 f5e10808 nt!ObpCloseHandle+0xb5
>
> f5e107fc 8082337b 80000294 f5e10924 8082138c nt!NtClose+0x1b
>
> f5e107fc 8082138c 80000294 f5e10924 8082138c nt!KiFastCallEntry+0xf8
>
> f5e10878 f72a9621 80000294 f72a95aa 8518dee4 nt!ZwClose+0x11
>
> f5e10880 f72a95aa 8518dee4 8518dda0 851c92f0 testFilter!PreCreate+0x7e1
>
> f5e10924 f734d4e8 851c934c f5e10944 f5e10960 testFilter!PreCreate+0x76a
>
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
>
> f5e10984 f734ef48 00e109c8 851c92f0 851d2548 fltmgr+0x24e8
>
> f5e10998 f735d0ad f5e109c8 f735b540 00000000 fltmgr+0x3f48
>
> f5e109b0 f735d59d f5e109c8 851d23b8 851d2564 fltmgr+0x120ad
>
> f5e109e4 80828c93 84d03e58 851d23b8 00000000 fltmgr+0x1259d
>
> f5e109f8 f769e934 84bb3478 8507e0a8 84b6df08 nt!IofCallDriver+0x45
>
> f5e10a5c 80828c93 84d33b98 00000000 851d23b8
> TmPreFlt!TmpQueryFullName+0x5ba4
>
> f5e10a70 80907bea f5e10c18 84d33018 00000000 nt!IofCallDriver+0x45
>
> f5e10b58 80902f9d 84d33030 00000000 8494d008 nt!IopParseDevice+0xa35
>
> f5e10bd8 80906a05 00000000 f5e10c18 00000040 nt!ObpLookupObjectName+0x5a9
>
> f5e10c2c 8090612b 00000000 00000000 3f100001 nt!ObOpenObjectByName+0xea
>
> f5e10ca8 8092b2b0 000f288c c1150000 000f27e0 nt!IopCreateFile+0x447
>
> f5e10d04 8091bd20 000f288c c1150000 000f27e0 nt!IoCreateFile+0xa3
>
> f5e10d44 8082337b 000f288c c1150000 000f27e0 nt!NtOpenFile+0x27
>
> f5e10d44 7c82ed54 000f288c c1150000 000f27e0 nt!KiFastCallEntry+0xf8
>
> 000f2af8 501667af 0717d52c 000f2b28 00000000 ntdll!KiFastSystemCallRet
>
> 000f2d38 501668e8 010a4f58 0717d52c 000f2d70 msenv!DllCanUnloadNow+0x48e58
>
> 000f2d80 500e1cc1 010968e0 0717d52c 00000001 msenv!DllCanUnloadNow+0x48f91
>
> 000f2da4 500e1f03 00000001 0717d52c 00000000
> msenv!DllGetClassObject+0x23ea9
>
> 000f2e14 50166ce4 00000002 010968e0 0717d52c
> msenv!DllGetClassObject+0x240eb
>
> 000f2e30 50166c67 009f2e68 00000002 010968e0 msenv!DllCanUnloadNow+0x4938d
>
> 000f2e88 78134bbe 259c64a4 00000001 0a659980 msenv!DllCanUnloadNow+0x49310
>
> 000f2e88 78134bbe 259c64a4 00000001 0a659980 MSVCR80!free+0xec
>
> 000f2e88 78134bbe 259c64a4 00000001 0a659980 MSVCR80!free+0xec
>
>
>
>
> Thanks in Advance
> Anand.
>

4

Here,

http://www.osronline.com/showThread.cfm?link=78517

somebody describes something similar…and guess what: he has TrendMicro
installed, too. Just an indication (not blaming anybody), but give your
filter a try without Trend-Filter installed and see what happens.

schrieb im Newsbeitrag news:xxxxx@ntfsd…
> Hi All,
>
> I am developing a mini-filter.In my PreCreate Operation,i got crash dump.
>
>
> My Pseudo Code:
>
> PreCreate()
> {
> HANDLE hFileHandle = NULL;
> PFILE_OBJECT pobjFileObject = NULL;
> OBJECT_ATTRIBUTES objectAttributes;
>
> try
> {
> InitializeObjectAttributes(&objectAttributes,
> &FileName,
> OBJ_KERNEL_HANDLE,
> NULL,
> NULL);
>
> status = FltCreateFile(gFilterHandle,
> FltObjects->Instance,
> &hFileHandle,
> FILE_READ_DATA,
> &objectAttributes,
> &ioStatus,
> (PLARGE_INTEGER) NULL,
> FILE_ATTRIBUTE_NORMAL,
> FILE_SHARE_READ,
> FILE_OPEN,
> 0L,
> NULL,
> 0L,
> 0);
>
> if(STATUS_SUCCESS != status)
> {
> leave;
> }
>
> status = ObReferenceObjectByHandle(hFileHandle,
> STANDARD_RIGHTS_REQUIRED,
> *IoFileObjectType,
> KernelMode,
> &pobjFileObject,
> NULL);
>
> if(STATUS_SUCCESS != status)
> {
> leave;
> }
>
> }
> finally
> {
> if(hFileHandle)
> {
> //Here Crash occurs
> FltClose(hFileHandle);
> hFileHandle = NULL;
> }
> if(pobjFileObject)
> {
> ObDereferenceObject(pobjFileObject);
> pobjFileObject = NULL;
> }
> }
> }
>
>
> The pobjFileObject parameter has different value in try block and when it
> leaves try block and goes to finally block it has some different value.
> Why the value of pobjFileObject changes?
>
>
>
>
> Following is the Crash Dump:
>
> Bug Check 0x6: INVALID_PROCESS_DETACH_ATTEMPT
>
> f5e10798 8080c77e 00000006 84980020 f5e107ec nt!KeBugCheck+0x14
>
> f5e107b8 8091bef3 f5e107d0 f5e10808 f5e10884
> nt!KeUnstackDetachProcess+0x10b
>
> f5e107ec 80905562 00000294 00000000 f5e10808 nt!ObpCloseHandle+0xb5
>
> f5e107fc 8082337b 80000294 f5e10924 8082138c nt!NtClose+0x1b
>
> f5e107fc 8082138c 80000294 f5e10924 8082138c nt!KiFastCallEntry+0xf8
>
> f5e10878 f72a9621 80000294 f72a95aa 8518dee4 nt!ZwClose+0x11
>
> f5e10880 f72a95aa 8518dee4 8518dda0 851c92f0 testFilter!PreCreate+0x7e1
>
> f5e10924 f734d4e8 851c934c f5e10944 f5e10960 testFilter!PreCreate+0x76a
>
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
>
> f5e10984 f734ef48 00e109c8 851c92f0 851d2548 fltmgr+0x24e8
>
> f5e10998 f735d0ad f5e109c8 f735b540 00000000 fltmgr+0x3f48
>
> f5e109b0 f735d59d f5e109c8 851d23b8 851d2564 fltmgr+0x120ad
>
> f5e109e4 80828c93 84d03e58 851d23b8 00000000 fltmgr+0x1259d
>
> f5e109f8 f769e934 84bb3478 8507e0a8 84b6df08 nt!IofCallDriver+0x45
>
> f5e10a5c 80828c93 84d33b98 00000000 851d23b8
> TmPreFlt!TmpQueryFullName+0x5ba4
>
> f5e10a70 80907bea f5e10c18 84d33018 00000000 nt!IofCallDriver+0x45
>
> f5e10b58 80902f9d 84d33030 00000000 8494d008 nt!IopParseDevice+0xa35
>
> f5e10bd8 80906a05 00000000 f5e10c18 00000040 nt!ObpLookupObjectName+0x5a9
>
> f5e10c2c 8090612b 00000000 00000000 3f100001 nt!ObOpenObjectByName+0xea
>
> f5e10ca8 8092b2b0 000f288c c1150000 000f27e0 nt!IopCreateFile+0x447
>
> f5e10d04 8091bd20 000f288c c1150000 000f27e0 nt!IoCreateFile+0xa3
>
> f5e10d44 8082337b 000f288c c1150000 000f27e0 nt!NtOpenFile+0x27
>
> f5e10d44 7c82ed54 000f288c c1150000 000f27e0 nt!KiFastCallEntry+0xf8
>
> 000f2af8 501667af 0717d52c 000f2b28 00000000 ntdll!KiFastSystemCallRet
>
> 000f2d38 501668e8 010a4f58 0717d52c 000f2d70 msenv!DllCanUnloadNow+0x48e58
>
> 000f2d80 500e1cc1 010968e0 0717d52c 00000001 msenv!DllCanUnloadNow+0x48f91
>
> 000f2da4 500e1f03 00000001 0717d52c 00000000
> msenv!DllGetClassObject+0x23ea9
>
> 000f2e14 50166ce4 00000002 010968e0 0717d52c
> msenv!DllGetClassObject+0x240eb
>
> 000f2e30 50166c67 009f2e68 00000002 010968e0 msenv!DllCanUnloadNow+0x4938d
>
> 000f2e88 78134bbe 259c64a4 00000001 0a659980 msenv!DllCanUnloadNow+0x49310
>
> 000f2e88 78134bbe 259c64a4 00000001 0a659980 MSVCR80!free+0xec
>
> 000f2e88 78134bbe 259c64a4 00000001 0a659980 MSVCR80!free+0xec
>
>
>
>
> Thanks in Advance
> Anand.
>

5

Hi,

Thanks for your replies.

Ken, I have checked the value in Handle its not -1, it has some valid value.

Petr, I am doing FltCreate() only in particular scenarios which does not occur in normal flow.

I haven’t understood, why the pobjFileObject parameter has different value in try and finally block?
In the crash dump, there are 2 entries of testfilter. 1st points to leave statement in try block and 2nd points to FltClose(hFileHandle) in finally block.

Is there any other thing that i can try out to analyze the dump?

Thanks in Advance
Anand

6

Hi,

Again crash dump occurs at same location.Additionally, i see the ReplaceFileW() function in call stack and the input parameters of this function are valid files.

Following is the dump:

kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************
INVALID_PROCESS_DETACH_ATTEMPT (6)

Arguments:

Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x6

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from 8080c77e to 80875d84

STACK_TEXT:

f5e10798 8080c77e 00000006 84980020 f5e107ec nt!KeBugCheck+0x14

f5e107b8 8091bef3 f5e107d0 f5e10808 f5e10884 nt!KeUnstackDetachProcess+0x10b

f5e107ec 80905562 00000294 00000000 f5e10808 nt!ObpCloseHandle+0xb5

f5e107fc 8082337b 80000294 f5e10924 8082138c nt!NtClose+0x1b

f5e107fc 8082138c 80000294 f5e10924 8082138c nt!KiFastCallEntry+0xf8

f5e10878 f72a9621 80000294 f72a95aa 8518dee4 nt!ZwClose+0x11

f5e10880 f72a95aa 8518dee4 8518dda0 851c92f0 testFilter!PreCreate+0x7e1

f5e10924 f734d4e8 851c934c f5e10944 f5e10960 testFilter!PreCreate+0x76a

f5e10984 f734ef48 00e109c8 851c92f0 851d2548 fltmgr!FltpPerformPreCallbacks+0x2d4

f5e10998 f735d0ad f5e109c8 f735b540 00000000 fltmgr!FltpPassThroughInternal+0x32

f5e109b0 f735d59d f5e109c8 851d23b8 851d2564 fltmgr!FltpCreateInternal+0x63

f5e109e4 80828c93 84d03e58 851d23b8 00000000 fltmgr!FltpCreate+0x229

f5e109f8 f769e934 84bb3478 8507e0a8 84b6df08 nt!IofCallDriver+0x45

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

f5e10a5c 80828c93 84d33b98 00000000 851d23b8 TmPreFlt!TmpQueryFullName+0x5ba4

f5e10a70 80907bea f5e10c18 84d33018 00000000 nt!IofCallDriver+0x45

f5e10b58 80902f9d 84d33030 00000000 8494d008 nt!IopParseDevice+0xa35

f5e10bd8 80906a05 00000000 f5e10c18 00000040 nt!ObpLookupObjectName+0x5a9

f5e10c2c 8090612b 00000000 00000000 3f100001 nt!ObOpenObjectByName+0xea

f5e10ca8 8092b2b0 000f288c c1150000 000f27e0 nt!IopCreateFile+0x447

f5e10d04 8091bd20 000f288c c1150000 000f27e0 nt!IoCreateFile+0xa3

f5e10d44 8082337b 000f288c c1150000 000f27e0 nt!NtOpenFile+0x27

f5e10d44 7c82ed54 000f288c c1150000 000f27e0 nt!KiFastCallEntry+0xf8

000f26ec 7c821734 77e8feb9 000f288c c1150000 ntdll!KiFastSystemCallRet

000f26f0 77e8feb9 000f288c c1150000 000f27e0 ntdll!NtOpenFile+0xc

000f2af8 501667af 0717d52c 000f2b28 00000000 kernel32!ReplaceFileW+0x24c

000f2d38 501668e8 010a4f58 0717d52c 000f2d70 msenv!DllCanUnloadNow+0x48e58

000f2d80 500e1cc1 010968e0 0717d52c 00000001 msenv!DllCanUnloadNow+0x48f91

000f2da4 500e1f03 00000001 0717d52c 00000000 msenv!DllGetClassObject+0x23ea9

000f2e14 50166ce4 00000002 010968e0 0717d52c msenv!DllGetClassObject+0x240eb

000f2e30 50166c67 009f2e68 00000002 010968e0 msenv!DllCanUnloadNow+0x4938d

000f2e88 78134bbe 259c64a4 00000001 0a659980 msenv!DllCanUnloadNow+0x49310

000f2ed0 7c82f9dd 78134b9f 003c0000 00000000 MSVCR80!free+0xec

ffffffff 00000000 00000000 00000000 00000000 ntdll!RtlFreeHeap+0x70f

I thought it might be due to ReplaceFileW() function, so i created a test application which calls ReplaceFileW number of times but it works.

What can be the problem?

Thanks in Advance
Anand.

7

Hi,

I tried looking for handle passed to ZwClose(). Following is the output.

kd> !handle 80000294
processor number 0
PROCESS 849792f8 SessionId: 0 Cid: 0f5c Peb: 7ffdc000 ParentCid: 0a44
DirBase: 111d5000 ObjectTable: e1654f40 HandleCount: 618.
Image: devenv.exe

Kernel New version of handle table at e1652000 with 576 Entries in use
Unable to get _HANDLE_TABLE_ENTRY : 00059592

I also tried doing !handle. This did not return the handle value seen as parameter to the ZwClose().

Kindly help me to analyze this dump.

Thanks in Advance.
Anand.