System restore interaction question...

NTFSD
1

Hi all,

I’m writing a legacy filter that actually is currently running above system
restore in the file system stack. One problem I’m having (causing a crash)
is that system restore decides to call IoCreateFileSpecifyDeviceObjectHint
with a NULL DeviceObject argument in sr!SrpExpandPathOfFileName when getting
a rename setinfo IRP, thus re-entering the top of the device stack, and my
filter of course. Using the handle it gets back from this call it gets a
file object and sends it down to FAT/NTFS, which barfs for reasons which are
obvious to me.

My question is this: Shouldn’t system restore be calling
IoCreateFileSpecifyDeviceObjectHint with it’s device object or using the
shadow device technique, so as to avoid re-entering the stack at the top, or
is this behaviour intentional? Any help/advice is appreciated. Of course,
if I’m located below SR, I have no problems.

Below is the stack trace for the crash I’m talking about (on XP SP2, checked
kernel, my driver is impwinxp):

STACK_TEXT:
f30fc1bc bae95d60 f30fc2a8 82a0f678 f30fc1f8 Ntfs!NtfsDecodeFileObject+0x37
f30fc230 bae944b4 f30fc2a8 83182e70 82cb8388
Ntfs!NtfsCommonQueryInformation+0x56
f30fc294 bae944ed f30fc2a8 83182e70 00000001
Ntfs!NtfsFsdDispatchSwitch+0x12a
f30fc3b8 80a21a49 82cb8388 83182e70 82cb8388 Ntfs!NtfsFsdDispatchWait+0x1c
f30fc3d0 80cd4128 82cb8388 83182e70 00000000 nt!IopfCallDriver+0x51
f30fc3f4 baf2152d 82d02458 f30fc4ba f30fc4a8 nt!IovCallDriver+0xa0
f30fc420 baf1b82c 82cb8388 82a0f678 f30fc4ba sr!SrQueryInformationFile+0x99
f30fc44c baf1bf33 0000002e 82a0f678 f30fc4a8 sr!SrpGetFileName+0x32
f30fc5bc baf1c4e9 82d02458 f30fc71c f30fc8f6
sr!SrpExpandPathOfFileName+0x19f
f30fc830 baf1f3b5 82d02458 00000000 00000028 sr!SrpExpandDestPath+0x41b
f30fc944 baf1ff0e 82d02458 83022e28 82d023a0 sr!SrpSetRenameInfo+0x135
f30fc960 80a21a49 82d02458 83022e28 82d023a0 sr!SrSetInformation+0x142
f30fc978 80cd4128 83022fd4 83022ff8 00000000 nt!IopfCallDriver+0x51
f30fc99c f2d9804e 82a15cd8 83022e28 f2d80000 nt!IovCallDriver+0xa0
f30fc9e8 f2d86006 82a15cd8 83022e28 00000000
impwinxp!ImpVfsForwardIrpSynchronously+0x18e
f30fcab8 f2d8370d 83350b48 83284f58 82a15d90
impwinxp!ImpVfsSetRenameInformation+0x756
f30fcc08 f2d8184b 83216fc8 83022e28 82a15cd8
impwinxp!ImpVfsCommonFileInfo+0x149d
f30fcc78 80a21a49 82a15cd8 83022e28 82a15cd8 impwinxp!ImpVfsFileInfo+0x30b
f30fcc90 80cd4128 83022fdc 00000000 83022e28 nt!IopfCallDriver+0x51
f30fccb4 80b2aabf f30fcd58 0013f0c4 80b2a4d8 nt!IovCallDriver+0xa0
f30fcd3c 80ad5a48 000002f0 0013f138 001593f8 nt!NtSetInformationFile+0x5e7
f30fcd3c 7c90eb94 000002f0 0013f138 001593f8 nt!KiFastCallEntry+0x158
0013f0a4 7c90e5e5 7c821735 000002f0 0013f138 ntdll!KiFastSystemCallRet
0013f0a8 7c821735 000002f0 0013f138 001593f8 ntdll!NtSetInformationFile+0xc
0013f17c 7c839936 0013f410 0013f618 00000000
kernel32!MoveFileWithProgressW+0x3b4
0013f198 4ad06db3 0013f410 0013f618 00000002 kernel32!MoveFileExW+0x17
0013f1b8 4ad06d16 0013f410 0013f618 0013f83c cmd!MyMoveFile+0x2b
0013f82c 4ad06ab8 0013f858 0013fa60 00000001 cmd!Move+0x2e9
0013fc6c 4ad05aa2 00158450 00000000 00158450 cmd!eMove+0xb2
0013fe9c 4ad013eb 00158450 00158450 00000002 cmd!FindFixAndRun+0x1f5
0013fee0 4ad0bbba 00000000 00000001 00000000 cmd!Dispatch+0x137
0013ff44 4ad05164 00000001 000340b8 00032950 cmd!main+0x216
0013ffc0 7c816d4f 00320030 00300034 7ffd8000 cmd!mainCRTStartup+0x125
0013fff0 00000000 4ad05056 00000000 78746341 kernel32!BaseProcessStart+0x23

Thanks,
Matt

2

SR is not the only software out there that causes
reentrancy. Unfortunately, you’ll have to deal with
it.

SR may have a reason that it does this, but I can’t
think of what that might be. Crusty design IMO.
Maybe someone can shed some light on what might be a
reason to do this.

If there is a reason to send it down from the top
again, why isn’t there a stupid bit that says, “This
call originated below you. You can pay attention or
not.” When it got back to the caller, the stupid bit
could be cleared.

As far as I know (please correct me if I’m wrong) the
filter manager doesn’t do anything to help. You still
have to deal with it there.

— “Matthew N. White” wrote:

> Hi all,
>
> I’m writing a legacy filter that actually is
> currently running above system
> restore in the file system stack. One problem I’m
> having (causing a crash)
> is that system restore decides to call
> IoCreateFileSpecifyDeviceObjectHint
> with a NULL DeviceObject argument in
> sr!SrpExpandPathOfFileName when getting
> a rename setinfo IRP, thus re-entering the top of
> the device stack, and my
> filter of course. Using the handle it gets back
> from this call it gets a
> file object and sends it down to FAT/NTFS, which
> barfs for reasons which are
> obvious to me.
>
> My question is this: Shouldn’t system restore be
> calling
> IoCreateFileSpecifyDeviceObjectHint with it’s device
> object or using the
> shadow device technique, so as to avoid re-entering
> the stack at the top, or
> is this behaviour intentional? Any help/advice is
> appreciated. Of course,
> if I’m located below SR, I have no problems.
>
> Below is the stack trace for the crash I’m talking
> about (on XP SP2, checked
> kernel, my driver is impwinxp):
>
> STACK_TEXT:
> f30fc1bc bae95d60 f30fc2a8 82a0f678 f30fc1f8
> Ntfs!NtfsDecodeFileObject+0x37
> f30fc230 bae944b4 f30fc2a8 83182e70 82cb8388
> Ntfs!NtfsCommonQueryInformation+0x56
> f30fc294 bae944ed f30fc2a8 83182e70 00000001
> Ntfs!NtfsFsdDispatchSwitch+0x12a
> f30fc3b8 80a21a49 82cb8388 83182e70 82cb8388
> Ntfs!NtfsFsdDispatchWait+0x1c
> f30fc3d0 80cd4128 82cb8388 83182e70 00000000
> nt!IopfCallDriver+0x51
> f30fc3f4 baf2152d 82d02458 f30fc4ba f30fc4a8
> nt!IovCallDriver+0xa0
> f30fc420 baf1b82c 82cb8388 82a0f678 f30fc4ba
> sr!SrQueryInformationFile+0x99
> f30fc44c baf1bf33 0000002e 82a0f678 f30fc4a8
> sr!SrpGetFileName+0x32
> f30fc5bc baf1c4e9 82d02458 f30fc71c f30fc8f6
> sr!SrpExpandPathOfFileName+0x19f
> f30fc830 baf1f3b5 82d02458 00000000 00000028
> sr!SrpExpandDestPath+0x41b
> f30fc944 baf1ff0e 82d02458 83022e28 82d023a0
> sr!SrpSetRenameInfo+0x135
> f30fc960 80a21a49 82d02458 83022e28 82d023a0
> sr!SrSetInformation+0x142
> f30fc978 80cd4128 83022fd4 83022ff8 00000000
> nt!IopfCallDriver+0x51
> f30fc99c f2d9804e 82a15cd8 83022e28 f2d80000
> nt!IovCallDriver+0xa0
> f30fc9e8 f2d86006 82a15cd8 83022e28 00000000
> impwinxp!ImpVfsForwardIrpSynchronously+0x18e
> f30fcab8 f2d8370d 83350b48 83284f58 82a15d90
> impwinxp!ImpVfsSetRenameInformation+0x756
> f30fcc08 f2d8184b 83216fc8 83022e28 82a15cd8
> impwinxp!ImpVfsCommonFileInfo+0x149d
> f30fcc78 80a21a49 82a15cd8 83022e28 82a15cd8
> impwinxp!ImpVfsFileInfo+0x30b
> f30fcc90 80cd4128 83022fdc 00000000 83022e28
> nt!IopfCallDriver+0x51
> f30fccb4 80b2aabf f30fcd58 0013f0c4 80b2a4d8
> nt!IovCallDriver+0xa0
> f30fcd3c 80ad5a48 000002f0 0013f138 001593f8
> nt!NtSetInformationFile+0x5e7
> f30fcd3c 7c90eb94 000002f0 0013f138 001593f8
> nt!KiFastCallEntry+0x158
> 0013f0a4 7c90e5e5 7c821735 000002f0 0013f138
> ntdll!KiFastSystemCallRet
> 0013f0a8 7c821735 000002f0 0013f138 001593f8
> ntdll!NtSetInformationFile+0xc
> 0013f17c 7c839936 0013f410 0013f618 00000000
> kernel32!MoveFileWithProgressW+0x3b4
> 0013f198 4ad06db3 0013f410 0013f618 00000002
> kernel32!MoveFileExW+0x17
> 0013f1b8 4ad06d16 0013f410 0013f618 0013f83c
> cmd!MyMoveFile+0x2b
> 0013f82c 4ad06ab8 0013f858 0013fa60 00000001
> cmd!Move+0x2e9
> 0013fc6c 4ad05aa2 00158450 00000000 00158450
> cmd!eMove+0xb2
> 0013fe9c 4ad013eb 00158450 00158450 00000002
> cmd!FindFixAndRun+0x1f5
> 0013fee0 4ad0bbba 00000000 00000001 00000000
> cmd!Dispatch+0x137
> 0013ff44 4ad05164 00000001 000340b8 00032950
> cmd!main+0x216
> 0013ffc0 7c816d4f 00320030 00300034 7ffd8000
> cmd!mainCRTStartup+0x125
> 0013fff0 00000000 4ad05056 00000000 78746341
> kernel32!BaseProcessStart+0x23
>
>
> Thanks,
> Matt
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

3

Yeah, that’s what I figured, but since this IS a Microsoft filter, I was
thinking there must be a good reason for this. Maybe I am wrong. If this
was really intended, why would they use IoCreateFileSpecifyDeviceObjectHint
instead of just one of the normal create file routines (which are re-entrant
anyway). Any ideas?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Randy Cook
Sent: Thursday, September 22, 2005 12:45 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] System restore interaction question…

SR is not the only software out there that causes reentrancy.
Unfortunately, you’ll have to deal with it.

SR may have a reason that it does this, but I can’t think of what that might
be. Crusty design IMO.
Maybe someone can shed some light on what might be a reason to do this.

If there is a reason to send it down from the top again, why isn’t there a
stupid bit that says, “This call originated below you. You can pay
attention or not.” When it got back to the caller, the stupid bit could be
cleared.

As far as I know (please correct me if I’m wrong) the filter manager doesn’t
do anything to help. You still have to deal with it there.

— “Matthew N. White” wrote:

> Hi all,
>
> I’m writing a legacy filter that actually is currently running above
> system restore in the file system stack. One problem I’m having
> (causing a crash) is that system restore decides to call
> IoCreateFileSpecifyDeviceObjectHint
> with a NULL DeviceObject argument in
> sr!SrpExpandPathOfFileName when getting a rename setinfo IRP, thus
> re-entering the top of the device stack, and my filter of course.
> Using the handle it gets back from this call it gets a file object and
> sends it down to FAT/NTFS, which barfs for reasons which are obvious
> to me.
>
> My question is this: Shouldn’t system restore be calling
> IoCreateFileSpecifyDeviceObjectHint with it’s device object or using
> the shadow device technique, so as to avoid re-entering the stack at
> the top, or is this behaviour intentional? Any help/advice is
> appreciated. Of course, if I’m located below SR, I have no problems.
>
> Below is the stack trace for the crash I’m talking about (on XP SP2,
> checked kernel, my driver is impwinxp):
>
> STACK_TEXT:
> f30fc1bc bae95d60 f30fc2a8 82a0f678 f30fc1f8
> Ntfs!NtfsDecodeFileObject+0x37
> f30fc230 bae944b4 f30fc2a8 83182e70 82cb8388
> Ntfs!NtfsCommonQueryInformation+0x56
> f30fc294 bae944ed f30fc2a8 83182e70 00000001
> Ntfs!NtfsFsdDispatchSwitch+0x12a
> f30fc3b8 80a21a49 82cb8388 83182e70 82cb8388
> Ntfs!NtfsFsdDispatchWait+0x1c f30fc3d0 80cd4128 82cb8388 83182e70
> 00000000
> nt!IopfCallDriver+0x51
> f30fc3f4 baf2152d 82d02458 f30fc4ba f30fc4a8 nt!IovCallDriver+0xa0
> f30fc420 baf1b82c 82cb8388 82a0f678 f30fc4ba
> sr!SrQueryInformationFile+0x99
> f30fc44c baf1bf33 0000002e 82a0f678 f30fc4a8
> sr!SrpGetFileName+0x32
> f30fc5bc baf1c4e9 82d02458 f30fc71c f30fc8f6
> sr!SrpExpandPathOfFileName+0x19f f30fc830 baf1f3b5 82d02458 00000000
> 00000028 sr!SrpExpandDestPath+0x41b
> f30fc944 baf1ff0e 82d02458 83022e28 82d023a0
> sr!SrpSetRenameInfo+0x135
> f30fc960 80a21a49 82d02458 83022e28 82d023a0
> sr!SrSetInformation+0x142
> f30fc978 80cd4128 83022fd4 83022ff8 00000000
> nt!IopfCallDriver+0x51
> f30fc99c f2d9804e 82a15cd8 83022e28 f2d80000 nt!IovCallDriver+0xa0
> f30fc9e8 f2d86006 82a15cd8 83022e28 00000000
> impwinxp!ImpVfsForwardIrpSynchronously+0x18e
> f30fcab8 f2d8370d 83350b48 83284f58 82a15d90
> impwinxp!ImpVfsSetRenameInformation+0x756
> f30fcc08 f2d8184b 83216fc8 83022e28 82a15cd8
> impwinxp!ImpVfsCommonFileInfo+0x149d
> f30fcc78 80a21a49 82a15cd8 83022e28 82a15cd8
> impwinxp!ImpVfsFileInfo+0x30b f30fcc90 80cd4128 83022fdc 00000000
> 83022e28
> nt!IopfCallDriver+0x51
> f30fccb4 80b2aabf f30fcd58 0013f0c4 80b2a4d8 nt!IovCallDriver+0xa0
> f30fcd3c 80ad5a48 000002f0 0013f138 001593f8
> nt!NtSetInformationFile+0x5e7
> f30fcd3c 7c90eb94 000002f0 0013f138 001593f8
> nt!KiFastCallEntry+0x158
> 0013f0a4 7c90e5e5 7c821735 000002f0 0013f138 ntdll!KiFastSystemCallRet
> 0013f0a8 7c821735 000002f0 0013f138 001593f8
> ntdll!NtSetInformationFile+0xc 0013f17c 7c839936 0013f410 0013f618
> 00000000
> kernel32!MoveFileWithProgressW+0x3b4
> 0013f198 4ad06db3 0013f410 0013f618 00000002
> kernel32!MoveFileExW+0x17
> 0013f1b8 4ad06d16 0013f410 0013f618 0013f83c cmd!MyMoveFile+0x2b
> 0013f82c 4ad06ab8 0013f858 0013fa60 00000001
> cmd!Move+0x2e9
> 0013fc6c 4ad05aa2 00158450 00000000 00158450
> cmd!eMove+0xb2
> 0013fe9c 4ad013eb 00158450 00158450 00000002
> cmd!FindFixAndRun+0x1f5
> 0013fee0 4ad0bbba 00000000 00000001 00000000
> cmd!Dispatch+0x137
> 0013ff44 4ad05164 00000001 000340b8 00032950
> cmd!main+0x216
> 0013ffc0 7c816d4f 00320030 00300034 7ffd8000
> cmd!mainCRTStartup+0x125
> 0013fff0 00000000 4ad05056 00000000 78746341
> kernel32!BaseProcessStart+0x23
>
>
> Thanks,
> Matt
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

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

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

4

I mentioned this in here (for the record) a cupla weeks back but I get the
feeling that the Microsoft people who might answer are otherwise occupied
right now.

/rod

“Matthew N. White” wrote in message news:xxxxx@ntfsd…
> Yeah, that’s what I figured, but since this IS a Microsoft filter, I was
> thinking there must be a good reason for this. Maybe I am wrong. If this
> was really intended, why would they use
> IoCreateFileSpecifyDeviceObjectHint
> instead of just one of the normal create file routines (which are
> re-entrant
> anyway). Any ideas?
>

5

I want to know, too !
Thanks!
“Matthew N. White” wrote in message news:xxxxx@ntfsd…
> Hi all,
>
> I’m writing a legacy filter that actually is currently running above
> system
> restore in the file system stack. One problem I’m having (causing a
> crash)
> is that system restore decides to call IoCreateFileSpecifyDeviceObjectHint
> with a NULL DeviceObject argument in sr!SrpExpandPathOfFileName when
> getting
> a rename setinfo IRP, thus re-entering the top of the device stack, and my
> filter of course. Using the handle it gets back from this call it gets a
> file object and sends it down to FAT/NTFS, which barfs for reasons which
> are
> obvious to me.
>
> My question is this: Shouldn’t system restore be calling
> IoCreateFileSpecifyDeviceObjectHint with it’s device object or using the
> shadow device technique, so as to avoid re-entering the stack at the top,
> or
> is this behaviour intentional? Any help/advice is appreciated. Of
> course,
> if I’m located below SR, I have no problems.
>
> Below is the stack trace for the crash I’m talking about (on XP SP2,
> checked
> kernel, my driver is impwinxp):
>
> STACK_TEXT:
> f30fc1bc bae95d60 f30fc2a8 82a0f678 f30fc1f8
> Ntfs!NtfsDecodeFileObject+0x37
> f30fc230 bae944b4 f30fc2a8 83182e70 82cb8388
> Ntfs!NtfsCommonQueryInformation+0x56
> f30fc294 bae944ed f30fc2a8 83182e70 00000001
> Ntfs!NtfsFsdDispatchSwitch+0x12a
> f30fc3b8 80a21a49 82cb8388 83182e70 82cb8388 Ntfs!NtfsFsdDispatchWait+0x1c
> f30fc3d0 80cd4128 82cb8388 83182e70 00000000 nt!IopfCallDriver+0x51
> f30fc3f4 baf2152d 82d02458 f30fc4ba f30fc4a8 nt!IovCallDriver+0xa0
> f30fc420 baf1b82c 82cb8388 82a0f678 f30fc4ba
> sr!SrQueryInformationFile+0x99
> f30fc44c baf1bf33 0000002e 82a0f678 f30fc4a8 sr!SrpGetFileName+0x32
> f30fc5bc baf1c4e9 82d02458 f30fc71c f30fc8f6
> sr!SrpExpandPathOfFileName+0x19f
> f30fc830 baf1f3b5 82d02458 00000000 00000028 sr!SrpExpandDestPath+0x41b
> f30fc944 baf1ff0e 82d02458 83022e28 82d023a0 sr!SrpSetRenameInfo+0x135
> f30fc960 80a21a49 82d02458 83022e28 82d023a0 sr!SrSetInformation+0x142
> f30fc978 80cd4128 83022fd4 83022ff8 00000000 nt!IopfCallDriver+0x51
> f30fc99c f2d9804e 82a15cd8 83022e28 f2d80000 nt!IovCallDriver+0xa0
> f30fc9e8 f2d86006 82a15cd8 83022e28 00000000
> impwinxp!ImpVfsForwardIrpSynchronously+0x18e
> f30fcab8 f2d8370d 83350b48 83284f58 82a15d90
> impwinxp!ImpVfsSetRenameInformation+0x756
> f30fcc08 f2d8184b 83216fc8 83022e28 82a15cd8
> impwinxp!ImpVfsCommonFileInfo+0x149d
> f30fcc78 80a21a49 82a15cd8 83022e28 82a15cd8 impwinxp!ImpVfsFileInfo+0x30b
> f30fcc90 80cd4128 83022fdc 00000000 83022e28 nt!IopfCallDriver+0x51
> f30fccb4 80b2aabf f30fcd58 0013f0c4 80b2a4d8 nt!IovCallDriver+0xa0
> f30fcd3c 80ad5a48 000002f0 0013f138 001593f8 nt!NtSetInformationFile+0x5e7
> f30fcd3c 7c90eb94 000002f0 0013f138 001593f8 nt!KiFastCallEntry+0x158
> 0013f0a4 7c90e5e5 7c821735 000002f0 0013f138 ntdll!KiFastSystemCallRet
> 0013f0a8 7c821735 000002f0 0013f138 001593f8
> ntdll!NtSetInformationFile+0xc
> 0013f17c 7c839936 0013f410 0013f618 00000000
> kernel32!MoveFileWithProgressW+0x3b4
> 0013f198 4ad06db3 0013f410 0013f618 00000002 kernel32!MoveFileExW+0x17
> 0013f1b8 4ad06d16 0013f410 0013f618 0013f83c cmd!MyMoveFile+0x2b
> 0013f82c 4ad06ab8 0013f858 0013fa60 00000001 cmd!Move+0x2e9
> 0013fc6c 4ad05aa2 00158450 00000000 00158450 cmd!eMove+0xb2
> 0013fe9c 4ad013eb 00158450 00158450 00000002 cmd!FindFixAndRun+0x1f5
> 0013fee0 4ad0bbba 00000000 00000001 00000000 cmd!Dispatch+0x137
> 0013ff44 4ad05164 00000001 000340b8 00032950 cmd!main+0x216
> 0013ffc0 7c816d4f 00320030 00300034 7ffd8000 cmd!mainCRTStartup+0x125
> 0013fff0 00000000 4ad05056 00000000 78746341
> kernel32!BaseProcessStart+0x23
>
>
> Thanks,
> Matt
>
>
>
>

6

Maybe we can form an angry mob…

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Leo
Sent: Friday, September 23, 2005 12:08 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] System restore interaction question…

I want to know, too !
Thanks!
“Matthew N. White” wrote in message news:xxxxx@ntfsd…
> Hi all,
>
> I’m writing a legacy filter that actually is currently running above
> system restore in the file system stack. One problem I’m having
> (causing a
> crash)
> is that system restore decides to call
> IoCreateFileSpecifyDeviceObjectHint
> with a NULL DeviceObject argument in sr!SrpExpandPathOfFileName when
> getting a rename setinfo IRP, thus re-entering the top of the device
> stack, and my filter of course. Using the handle it gets back from
> this call it gets a file object and sends it down to FAT/NTFS, which
> barfs for reasons which are obvious to me.
>
> My question is this: Shouldn’t system restore be calling
> IoCreateFileSpecifyDeviceObjectHint with it’s device object or using
> the shadow device technique, so as to avoid re-entering the stack at
> the top, or is this behaviour intentional? Any help/advice is
> appreciated. Of course, if I’m located below SR, I have no problems.
>
> Below is the stack trace for the crash I’m talking about (on XP SP2,
> checked kernel, my driver is impwinxp):
>
> STACK_TEXT:
> f30fc1bc bae95d60 f30fc2a8 82a0f678 f30fc1f8
> Ntfs!NtfsDecodeFileObject+0x37
> f30fc230 bae944b4 f30fc2a8 83182e70 82cb8388
> Ntfs!NtfsCommonQueryInformation+0x56
> f30fc294 bae944ed f30fc2a8 83182e70 00000001
> Ntfs!NtfsFsdDispatchSwitch+0x12a
> f30fc3b8 80a21a49 82cb8388 83182e70 82cb8388
> Ntfs!NtfsFsdDispatchWait+0x1c f30fc3d0 80cd4128 82cb8388 83182e70
> 00000000 nt!IopfCallDriver+0x51
> f30fc3f4 baf2152d 82d02458 f30fc4ba f30fc4a8 nt!IovCallDriver+0xa0
> f30fc420 baf1b82c 82cb8388 82a0f678 f30fc4ba
> sr!SrQueryInformationFile+0x99
> f30fc44c baf1bf33 0000002e 82a0f678 f30fc4a8 sr!SrpGetFileName+0x32
> f30fc5bc baf1c4e9 82d02458 f30fc71c f30fc8f6
> sr!SrpExpandPathOfFileName+0x19f f30fc830 baf1f3b5 82d02458 00000000
> 00000028 sr!SrpExpandDestPath+0x41b
> f30fc944 baf1ff0e 82d02458 83022e28 82d023a0 sr!SrpSetRenameInfo+0x135
> f30fc960 80a21a49 82d02458 83022e28 82d023a0 sr!SrSetInformation+0x142
> f30fc978 80cd4128 83022fd4 83022ff8 00000000 nt!IopfCallDriver+0x51
> f30fc99c f2d9804e 82a15cd8 83022e28 f2d80000 nt!IovCallDriver+0xa0
> f30fc9e8 f2d86006 82a15cd8 83022e28 00000000
> impwinxp!ImpVfsForwardIrpSynchronously+0x18e
> f30fcab8 f2d8370d 83350b48 83284f58 82a15d90
> impwinxp!ImpVfsSetRenameInformation+0x756
> f30fcc08 f2d8184b 83216fc8 83022e28 82a15cd8
> impwinxp!ImpVfsCommonFileInfo+0x149d
> f30fcc78 80a21a49 82a15cd8 83022e28 82a15cd8
> impwinxp!ImpVfsFileInfo+0x30b f30fcc90 80cd4128 83022fdc 00000000
> 83022e28 nt!IopfCallDriver+0x51
> f30fccb4 80b2aabf f30fcd58 0013f0c4 80b2a4d8 nt!IovCallDriver+0xa0
> f30fcd3c 80ad5a48 000002f0 0013f138 001593f8
> nt!NtSetInformationFile+0x5e7 f30fcd3c 7c90eb94 000002f0 0013f138
> 001593f8 nt!KiFastCallEntry+0x158
> 0013f0a4 7c90e5e5 7c821735 000002f0 0013f138 ntdll!KiFastSystemCallRet
> 0013f0a8 7c821735 000002f0 0013f138 001593f8
> ntdll!NtSetInformationFile+0xc 0013f17c 7c839936 0013f410 0013f618
> 00000000
> kernel32!MoveFileWithProgressW+0x3b4
> 0013f198 4ad06db3 0013f410 0013f618 00000002 kernel32!MoveFileExW+0x17
> 0013f1b8 4ad06d16 0013f410 0013f618 0013f83c cmd!MyMoveFile+0x2b
> 0013f82c 4ad06ab8 0013f858 0013fa60 00000001 cmd!Move+0x2e9 0013fc6c
> 4ad05aa2 00158450 00000000 00158450 cmd!eMove+0xb2 0013fe9c 4ad013eb
> 00158450 00158450 00000002 cmd!FindFixAndRun+0x1f5 0013fee0 4ad0bbba
> 00000000 00000001 00000000 cmd!Dispatch+0x137
> 0013ff44 4ad05164 00000001 000340b8 00032950 cmd!main+0x216 0013ffc0
> 7c816d4f 00320030 00300034 7ffd8000 cmd!mainCRTStartup+0x125 0013fff0
> 00000000 4ad05056 00000000 78746341
> kernel32!BaseProcessStart+0x23
>
>
> Thanks,
> Matt
>
>
>
>

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

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