AcquireFileForNtCreateSection

NTFSD
1

Hi.
I have a file system filter driver. As it is a file system filter I intercept all the fast-io functions. There is one of this functions, AcquireFileForNtCreateSection, which takes only one parameter, a pointer to FILE_OBJECT. In order to pass the request to the driver below I need to get a pointer to this driver object below mine. This pointer is in the device extension of the target device. So, I need to know which of the driver’s devices this request was targeted to. To get the device I am using IoGetRelatedDeviceObject, this function gives me the device object related to a file object.

Actually I did not write this code, it comes in Rajeev Nagar’s sample. Then I had never taken a look at this part of the code. Until I started to have Blue Screens due to a failed assertion there. The assertion failed because the device object returned by IoGetRelatedDeviceObject was not any of the driver’s devices. That made me think that this device was one above or one below in the stack of attached devices. But it is not either that. I made a search in both directions up and down starting from each of the driver’s devices and I did not find it. After that unsuccesful search the only thing that I thought was left to do is to get out of the function without calling the driver below.
I am just writing to know what is your opinion about this and if you have seen this before. The OS is Windows XP.

2

Actually, if you read the DDK help, you will see that IoGetRelatedDeviceObject() is clearly documented and cannot be used to get the next driver in the fs stack. This function will always return the HIGHEST level device in the stack, This is the intented functionality of this API, and no other. The IO manager itself relay heavily on this function to work as it is.

Moving further, when the a section object is created, in all versions of kernel prior to Windows XP , for synchronization issues, the file is locked exclusivly, using FsRtlAcquireFileExclusive(). This function will always send the request to the base file system device, bypassing the filter driver stack totally. There is only one very dirty trick to see this request in a filter driver prior to XP, which is hijacking the FastIo entry pointer for AcquireFileForNtCreateSection() in the base file system driver object fast IO table, and replacing it with your own, then call the old entry. A ugly, dirty to hell trick which can break any compatibility and should not be used in any circumstance
in production code from multiple reasons. So works the relase operation, in a very simmial manner, but calling the release code path.

In XP and later kernels , the behaviour is slightly altered. You are given the oportunity to register using FsRtlRegisterFileSystemFilterCallbacks() a set of callback routines
to get a chanche to see operations like AcuireFileForCreateSection or AcquireFileForModWrite and so on, using a set of filters which will be called proior and after the actual synch operation. Refere to IFS docs for further info on this. You should not use whatever code path you have in your driver now, and relay on this API.

But why do you want to see those requests? There are extremly few reasons why a FS filter would be interested in seeing and processing this operation.

Regards, Dan

----- Original Message -----
From: Ratmil Torres
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 3:55 PM
Subject: [ntfsd] AcquireFileForNtCreateSection

Hi.
I have a file system filter driver. As it is a file system filter I intercept all the fast-io functions. There is one of this functions, AcquireFileForNtCreateSection, which takes only one parameter, a pointer to FILE_OBJECT. In order to pass the request to the driver below I need to get a pointer to this driver object below mine. This pointer is in the device extension of the target device. So, I need to know which of the driver’s devices this request was targeted to. To get the device I am using IoGetRelatedDeviceObject, this function gives me the device object related to a file object.

Actually I did not write this code, it comes in Rajeev Nagar’s sample. Then I had never taken a look at this part of the code. Until I started to have Blue Screens due to a failed assertion there. The assertion failed because the device object returned by IoGetRelatedDeviceObject was not any of the driver’s devices. That made me think that this device was one above or one below in the stack of attached devices. But it is not either that. I made a search in both directions up and down starting from each of the driver’s devices and I did not find it. After that unsuccesful search the only thing that I thought was left to do is to get out of the function without calling the driver below.
I am just writing to know what is your opinion about this and if you have seen this before. The OS is Windows XP.

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

3

I read the DDK before posting the message. That's why I started to search from which device object of the ones I had created I could reach the device object returned by IoGetRelatedDeviceObject(), always moving by the AttachedDeviceObject field. As I did not find it that way I also made a search going down. Anyway, that was not the right way to solve the problem.

According to what you have said I see that I did not explain things right. I would be very happy if I wouldn't receive these calls and the system would just send the request to the base file system device.
When you make a filter driver isn't your task to give the same functionallity as the driver you are filtering?
I have to fill FastIoDispatch structure. What should I do with AcquireFileForNtCreateSection and ReleaseFileForNtCreateSection fields? Would it be ok to set them to NULL?
Thank you very much, Dan.
----- Original Message -----
From: Dan Partelly
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 7:37 AM
Subject: [ntfsd] Re: AcquireFileForNtCreateSection

Actually, if you read the DDK help, you will see that IoGetRelatedDeviceObject() is clearly documented and cannot be used to get the next driver in the fs stack. This function will always return the HIGHEST level device in the stack, This is the intented functionality of this API, and no other. The IO manager itself relay heavily on this function to work as it is.

Moving further, when the a section object is created, in all versions of kernel prior to Windows XP , for synchronization issues, the file is locked exclusivly, using FsRtlAcquireFileExclusive(). This function will always send the request to the base file system device, bypassing the filter driver stack totally. There is only one very dirty trick to see this request in a filter driver prior to XP, which is hijacking the FastIo entry pointer for AcquireFileForNtCreateSection() in the base file system driver object fast IO table, and replacing it with your own, then call the old entry. A ugly, dirty to hell trick which can break any compatibility and should not be used in any circumstance
in production code from multiple reasons. So works the relase operation, in a very simmial manner, but calling the release code path.
In XP and later kernels , the behaviour is slightly altered. You are given the oportunity to register using FsRtlRegisterFileSystemFilterCallbacks() a set of callback routines
to get a chanche to see operations like AcuireFileForCreateSection or AcquireFileForModWrite and so on, using a set of filters which will be called proior and after the actual synch operation. Refere to IFS docs for further info on this. You should not use whatever code path you have in your driver now, and relay on this API.

But why do you want to see those requests? There are extremly few reasons why a FS filter would be interested in seeing and processing this operation.

Regards, Dan

----- Original Message -----
From: Ratmil Torres
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 3:55 PM
Subject: [ntfsd] AcquireFileForNtCreateSection

Hi.
I have a file system filter driver. As it is a file system filter I intercept all the fast-io functions. There is one of this functions, AcquireFileForNtCreateSection, which takes only one parameter, a pointer to FILE_OBJECT. In order to pass the request to the driver below I need to get a pointer to this driver object below mine. This pointer is in the device extension of the target device. So, I need to know which of the driver's devices this request was targeted to. To get the device I am using IoGetRelatedDeviceObject, this function gives me the device object related to a file object.

Actually I did not write this code, it comes in Rajeev Nagar's sample. Then I had never taken a look at this part of the code. Until I started to have Blue Screens due to a failed assertion there. The assertion failed because the device object returned by IoGetRelatedDeviceObject was not any of the driver's devices. That made me think that this device was one above or one below in the stack of attached devices. But it is not either that. I made a search in both directions up and down starting from each of the driver's devices and I did not find it. After that unsuccesful search the only thing that I thought was left to do is to get out of the function without calling the driver below.
I am just writing to know what is your opinion about this and if you have seen this before. The OS is Windows XP.

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

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

4

Its a good programming practice to ensure that the fast io dispatch table is zeroed before poking pointers in it. You should have NULL for all calls which the Mm send directly to the FS itself, such as AcquireForNtCreateSection, AcquireForCcFlush, AcquireForModWrite and their release counterparts, and fast IO handlers present for all others, even if its only minimal passthrough logic.

Dan

----- Original Message -----
From: Ratmil Torres
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 6:21 PM
Subject: [ntfsd] Re: AcquireFileForNtCreateSection

I read the DDK before posting the message. That's why I started to search from which device object of the ones I had created I could reach the device object returned by IoGetRelatedDeviceObject(), always moving by the AttachedDeviceObject field. As I did not find it that way I also made a search going down. Anyway, that was not the right way to solve the problem.

According to what you have said I see that I did not explain things right. I would be very happy if I wouldn't receive these calls and the system would just send the request to the base file system device.
When you make a filter driver isn't your task to give the same functionallity as the driver you are filtering?
I have to fill FastIoDispatch structure. What should I do with AcquireFileForNtCreateSection and ReleaseFileForNtCreateSection fields? Would it be ok to set them to NULL?
Thank you very much, Dan.
----- Original Message -----
From: Dan Partelly
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 7:37 AM
Subject: [ntfsd] Re: AcquireFileForNtCreateSection

Actually, if you read the DDK help, you will see that IoGetRelatedDeviceObject() is clearly documented and cannot be used to get the next driver in the fs stack. This function will always return the HIGHEST level device in the stack, This is the intented functionality of this API, and no other. The IO manager itself relay heavily on this function to work as it is.

Moving further, when the a section object is created, in all versions of kernel prior to Windows XP , for synchronization issues, the file is locked exclusivly, using FsRtlAcquireFileExclusive(). This function will always send the request to the base file system device, bypassing the filter driver stack totally. There is only one very dirty trick to see this request in a filter driver prior to XP, which is hijacking the FastIo entry pointer for AcquireFileForNtCreateSection() in the base file system driver object fast IO table, and replacing it with your own, then call the old entry. A ugly, dirty to hell trick which can break any compatibility and should not be used in any circumstance
in production code from multiple reasons. So works the relase operation, in a very simmial manner, but calling the release code path.
In XP and later kernels , the behaviour is slightly altered. You are given the oportunity to register using FsRtlRegisterFileSystemFilterCallbacks() a set of callback routines
to get a chanche to see operations like AcuireFileForCreateSection or AcquireFileForModWrite and so on, using a set of filters which will be called proior and after the actual synch operation. Refere to IFS docs for further info on this. You should not use whatever code path you have in your driver now, and relay on this API.

But why do you want to see those requests? There are extremly few reasons why a FS filter would be interested in seeing and processing this operation.

Regards, Dan

----- Original Message -----
From: Ratmil Torres
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 3:55 PM
Subject: [ntfsd] AcquireFileForNtCreateSection

Hi.
I have a file system filter driver. As it is a file system filter I intercept all the fast-io functions. There is one of this functions, AcquireFileForNtCreateSection, which takes only one parameter, a pointer to FILE_OBJECT. In order to pass the request to the driver below I need to get a pointer to this driver object below mine. This pointer is in the device extension of the target device. So, I need to know which of the driver's devices this request was targeted to. To get the device I am using IoGetRelatedDeviceObject, this function gives me the device object related to a file object.

Actually I did not write this code, it comes in Rajeev Nagar's sample. Then I had never taken a look at this part of the code. Until I started to have Blue Screens due to a failed assertion there. The assertion failed because the device object returned by IoGetRelatedDeviceObject was not any of the driver's devices. That made me think that this device was one above or one below in the stack of attached devices. But it is not either that. I made a search in both directions up and down starting from each of the driver's devices and I did not find it. After that unsuccesful search the only thing that I thought was left to do is to get out of the function without calling the driver below.
I am just writing to know what is your opinion about this and if you have seen this before. The OS is Windows XP.

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

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

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

5

Then, if I have not missed anything I can set to NULL all the calls I am not interested in filtering.
OK, I will try that.
Thank you very much.
----- Original Message -----
From: Dan Partelly
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 8:36 AM
Subject: [ntfsd] Re: AcquireFileForNtCreateSection

Its a good programming practice to ensure that the fast io dispatch table is zeroed before poking pointers in it. You should have NULL for all calls which the Mm send directly to the FS itself, such as AcquireForNtCreateSection, AcquireForCcFlush, AcquireForModWrite and their release counterparts, and fast IO handlers present for all others, even if its only minimal passthrough logic.

Dan

----- Original Message -----
From: Ratmil Torres
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 6:21 PM
Subject: [ntfsd] Re: AcquireFileForNtCreateSection

I read the DDK before posting the message. That's why I started to search from which device object of the ones I had created I could reach the device object returned by IoGetRelatedDeviceObject(), always moving by the AttachedDeviceObject field. As I did not find it that way I also made a search going down. Anyway, that was not the right way to solve the problem.

According to what you have said I see that I did not explain things right. I would be very happy if I wouldn't receive these calls and the system would just send the request to the base file system device.
When you make a filter driver isn't your task to give the same functionallity as the driver you are filtering?
I have to fill FastIoDispatch structure. What should I do with AcquireFileForNtCreateSection and ReleaseFileForNtCreateSection fields? Would it be ok to set them to NULL?
Thank you very much, Dan.
----- Original Message -----
From: Dan Partelly
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 7:37 AM
Subject: [ntfsd] Re: AcquireFileForNtCreateSection

Actually, if you read the DDK help, you will see that IoGetRelatedDeviceObject() is clearly documented and cannot be used to get the next driver in the fs stack. This function will always return the HIGHEST level device in the stack, This is the intented functionality of this API, and no other. The IO manager itself relay heavily on this function to work as it is.

Moving further, when the a section object is created, in all versions of kernel prior to Windows XP , for synchronization issues, the file is locked exclusivly, using FsRtlAcquireFileExclusive(). This function will always send the request to the base file system device, bypassing the filter driver stack totally. There is only one very dirty trick to see this request in a filter driver prior to XP, which is hijacking the FastIo entry pointer for AcquireFileForNtCreateSection() in the base file system driver object fast IO table, and replacing it with your own, then call the old entry. A ugly, dirty to hell trick which can break any compatibility and should not be used in any circumstance
in production code from multiple reasons. So works the relase operation, in a very simmial manner, but calling the release code path.
In XP and later kernels , the behaviour is slightly altered. You are given the oportunity to register using FsRtlRegisterFileSystemFilterCallbacks() a set of callback routines
to get a chanche to see operations like AcuireFileForCreateSection or AcquireFileForModWrite and so on, using a set of filters which will be called proior and after the actual synch operation. Refere to IFS docs for further info on this. You should not use whatever code path you have in your driver now, and relay on this API.

But why do you want to see those requests? There are extremly few reasons why a FS filter would be interested in seeing and processing this operation.

Regards, Dan

----- Original Message -----
From: Ratmil Torres
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 3:55 PM
Subject: [ntfsd] AcquireFileForNtCreateSection

Hi.
I have a file system filter driver. As it is a file system filter I intercept all the fast-io functions. There is one of this functions, AcquireFileForNtCreateSection, which takes only one parameter, a pointer to FILE_OBJECT. In order to pass the request to the driver below I need to get a pointer to this driver object below mine. This pointer is in the device extension of the target device. So, I need to know which of the driver's devices this request was targeted to. To get the device I am using IoGetRelatedDeviceObject, this function gives me the device object related to a file object.

Actually I did not write this code, it comes in Rajeev Nagar's sample. Then I had never taken a look at this part of the code. Until I started to have Blue Screens due to a failed assertion there. The assertion failed because the device object returned by IoGetRelatedDeviceObject was not any of the driver's devices. That made me think that this device was one above or one below in the stack of attached devices. But it is not either that. I made a search in both directions up and down starting from each of the driver's devices and I did not find it. After that unsuccesful search the only thing that I thought was left to do is to get out of the function without calling the driver below.
I am just writing to know what is your opinion about this and if you have seen this before. The OS is Windows XP.

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

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

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

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

6

No, you should have at least passthrough logic for all other calls except the one I specifically said.

Dan
----- Original Message -----
From: Ratmil Torres
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 6:42 PM
Subject: [ntfsd] Re: AcquireFileForNtCreateSection

Then, if I have not missed anything I can set to NULL all the calls I am not interested in filtering.
OK, I will try that.
Thank you very much.
----- Original Message -----
From: Dan Partelly
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 8:36 AM
Subject: [ntfsd] Re: AcquireFileForNtCreateSection

Its a good programming practice to ensure that the fast io dispatch table is zeroed before poking pointers in it. You should have NULL for all calls which the Mm send directly to the FS itself, such as AcquireForNtCreateSection, AcquireForCcFlush, AcquireForModWrite and their release counterparts, and fast IO handlers present for all others, even if its only minimal passthrough logic.

Dan

----- Original Message -----
From: Ratmil Torres
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 6:21 PM
Subject: [ntfsd] Re: AcquireFileForNtCreateSection

I read the DDK before posting the message. That's why I started to search from which device object of the ones I had created I could reach the device object returned by IoGetRelatedDeviceObject(), always moving by the AttachedDeviceObject field. As I did not find it that way I also made a search going down. Anyway, that was not the right way to solve the problem.

According to what you have said I see that I did not explain things right. I would be very happy if I wouldn't receive these calls and the system would just send the request to the base file system device.
When you make a filter driver isn't your task to give the same functionallity as the driver you are filtering?
I have to fill FastIoDispatch structure. What should I do with AcquireFileForNtCreateSection and ReleaseFileForNtCreateSection fields? Would it be ok to set them to NULL?
Thank you very much, Dan.
----- Original Message -----
From: Dan Partelly
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 7:37 AM
Subject: [ntfsd] Re: AcquireFileForNtCreateSection

Actually, if you read the DDK help, you will see that IoGetRelatedDeviceObject() is clearly documented and cannot be used to get the next driver in the fs stack. This function will always return the HIGHEST level device in the stack, This is the intented functionality of this API, and no other. The IO manager itself relay heavily on this function to work as it is.

Moving further, when the a section object is created, in all versions of kernel prior to Windows XP , for synchronization issues, the file is locked exclusivly, using FsRtlAcquireFileExclusive(). This function will always send the request to the base file system device, bypassing the filter driver stack totally. There is only one very dirty trick to see this request in a filter driver prior to XP, which is hijacking the FastIo entry pointer for AcquireFileForNtCreateSection() in the base file system driver object fast IO table, and replacing it with your own, then call the old entry. A ugly, dirty to hell trick which can break any compatibility and should not be used in any circumstance
in production code from multiple reasons. So works the relase operation, in a very simmial manner, but calling the release code path.
In XP and later kernels , the behaviour is slightly altered. You are given the oportunity to register using FsRtlRegisterFileSystemFilterCallbacks() a set of callback routines
to get a chanche to see operations like AcuireFileForCreateSection or AcquireFileForModWrite and so on, using a set of filters which will be called proior and after the actual synch operation. Refere to IFS docs for further info on this. You should not use whatever code path you have in your driver now, and relay on this API.

But why do you want to see those requests? There are extremly few reasons why a FS filter would be interested in seeing and processing this operation.

Regards, Dan

----- Original Message -----
From: Ratmil Torres
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 3:55 PM
Subject: [ntfsd] AcquireFileForNtCreateSection

Hi.
I have a file system filter driver. As it is a file system filter I intercept all the fast-io functions. There is one of this functions, AcquireFileForNtCreateSection, which takes only one parameter, a pointer to FILE_OBJECT. In order to pass the request to the driver below I need to get a pointer to this driver object below mine. This pointer is in the device extension of the target device. So, I need to know which of the driver's devices this request was targeted to. To get the device I am using IoGetRelatedDeviceObject, this function gives me the device object related to a file object.

Actually I did not write this code, it comes in Rajeev Nagar's sample. Then I had never taken a look at this part of the code. Until I started to have Blue Screens due to a failed assertion there. The assertion failed because the device object returned by IoGetRelatedDeviceObject was not any of the driver's devices. That made me think that this device was one above or one below in the stack of attached devices. But it is not either that. I made a search in both directions up and down starting from each of the driver's devices and I did not find it. After that unsuccesful search the only thing that I thought was left to do is to get out of the function without calling the driver below.
I am just writing to know what is your opinion about this and if you have seen this before. The OS is Windows XP.

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

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

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

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

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

7

IIRC AcquireFileForNtCreateSection is never called for filters, and is called for the lowest base FSD only.

This makes sense, since the only goal of this function is to acquire the FCB locks, which belong to base FSD only.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: Ratmil Torres
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 17, 2003 4:55 PM
Subject: [ntfsd] AcquireFileForNtCreateSection

Hi.
I have a file system filter driver. As it is a file system filter I intercept all the fast-io functions. There is one of this functions, AcquireFileForNtCreateSection, which takes only one parameter, a pointer to FILE_OBJECT. In order to pass the request to the driver below I need to get a pointer to this driver object below mine. This pointer is in the device extension of the target device. So, I need to know which of the driver’s devices this request was targeted to. To get the device I am using IoGetRelatedDeviceObject, this function gives me the device object related to a file object.

Actually I did not write this code, it comes in Rajeev Nagar’s sample. Then I had never taken a look at this part of the code. Until I started to have Blue Screens due to a failed assertion there. The assertion failed because the device object returned by IoGetRelatedDeviceObject was not any of the driver’s devices. That made me think that this device was one above or one below in the stack of attached devices. But it is not either that. I made a search in both directions up and down starting from each of the driver’s devices and I did not find it. After that unsuccesful search the only thing that I thought was left to do is to get out of the function without calling the driver below.
I am just writing to know what is your opinion about this and if you have seen this before. The OS is Windows XP.

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