Hi.
Is there any field in IRP that can be use by file system filter driver or minifilter for its own purpose so that it can send some information to disk filter driver such as process ID.
That field value should remain same across stack, as new IRP get created across stack.
or
I want to know that, is there any solution that gives a process id at disk filter driver level.
This has been answered many times, bottom line is you cannot get a useful
ID at the disk level. For instance most cached I/O will show up as the
system process even though a specific process is doing the request. There
is no useful data at this level.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
wrote in message news:xxxxx@ntfsd…
> Hi.
>
> Is there any field in IRP that can be use by file system filter driver or
> minifilter for its own purpose so that it can send some information to
> disk filter driver such as process ID.
> That field value should remain same across stack, as new IRP get created
> across stack.
> or
> I want to know that, is there any solution that gives a process id at
> disk filter driver level.
>
>
>
If three programs need to access dlls in the windows directory and their
last access date needs to be updated. Which program (process) should be
associated with the write to the directory block that will be written? On
FAT32 if several programs need free space and fastfat.sys needs to read
chunks of the FAT into memory, which process should be connected with the
read? How about the writes where the FAT is written, twice?
Do you have source code access to NTFS? If not, how does it read/write MFT
entries to update last access, read/write data stored in the MFT, or to find
random blocks in a file to read/write? How can you predict what you don’t
know? Remember for efficiency that almost all system areas are cached for
some period of time after the initial write by the FSD occurs. This allows
the FSD to get the update done, but not to repeatedly write the same block
many times. Do a directory copy from one drive to another and see how few
times it really writes the directory sectors and FATs using fastfat.sys
where source code is available.
wrote in message news:xxxxx@ntfsd…
> Hi.
>
> Is there any field in IRP that can be use by file system filter driver or
> minifilter for its own purpose so that it can send some information to
> disk filter driver such as process ID.
> That field value should remain same across stack, as new IRP get created
> across stack.
> or
> I want to know that, is there any solution that gives a process id at disk
> filter driver level.
>
>
>
Sorry, can you explain me why he cannot build a file system driver to
maintain a list of IRPs along with the processes and threads that initiated
the operations so that he can find them back in his disk filter later when
the IRPs have been passed down the stack and this information is no longer
available ?
/Daniel
“Don Burn” wrote in message news:xxxxx@ntfsd…
> This has been answered many times, bottom line is you cannot get a useful
> ID at the disk level. For instance most cached I/O will show up as the
> system process even though a specific process is doing the request. There
> is no useful data at this level.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
> wrote in message news:xxxxx@ntfsd…
>> Hi.
>>
>> Is there any field in IRP that can be use by file system filter driver or
>> minifilter for its own purpose so that it can send some information to
>> disk filter driver such as process ID.
>> That field value should remain same across stack, as new IRP get created
>> across stack.
>> or
>> I want to know that, is there any solution that gives a process id at
>> disk filter driver level.
>>
>>
>>
>
>
>
Well if he wants to write a file system (note not a filter) he can do this.
Of course most people expect their filter to work with standard file
systems, and on the boot volume, etc. But if the individual wants to take
the long time to do his own file system he can make his disk filter know
the user. Of course at that point one has to ask if he would be better
off writing a file system filter to do what he wants to do, but since we do
not know the purpose of the disk filter this is not something we can
determine.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
“Daniel Terhell” wrote in message
news:xxxxx@ntfsd…
> Sorry, can you explain me why he cannot build a file system driver to
> maintain a list of IRPs along with the processes and threads that
> initiated the operations so that he can find them back in his disk filter
> later when the IRPs have been passed down the stack and this information
> is no longer available ?
>
> /Daniel
>
>
> “Don Burn” wrote in message news:xxxxx@ntfsd…
>> This has been answered many times, bottom line is you cannot get a
>> useful ID at the disk level. For instance most cached I/O will show up
>> as the system process even though a specific process is doing the
>> request. There is no useful data at this level.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> http://www.windrvr.com
>> Remove StopSpam from the email to reply
>>
>>
>> wrote in message news:xxxxx@ntfsd…
>>> Hi.
>>>
>>> Is there any field in IRP that can be use by file system filter driver
>>> or minifilter for its own purpose so that it can send some information
>>> to disk filter driver such as process ID.
>>> That field value should remain same across stack, as new IRP get
>>> created across stack.
>>> or
>>> I want to know that, is there any solution that gives a process id at
>>> disk filter driver level.
>>>
>>>
>>>
>>
>>
>>
>
>
>
If you look at the firewall software it is often a combination of a TDI
filter and some kind of NDIS driver. The TDI filter is often there only
because it more high in the stack so they run in the context of the threads
that initiated the I/O operations so this information can be saved for
later. This is because the firewall needs to be able to block traffic
depending on the process. What I never understood is why do IRPs not pass
around this information themselves I mean as member of IO_STACK_LOCATION.
/Daniel
“Don Burn” wrote in message news:xxxxx@ntfsd…
> Well if he wants to write a file system (note not a filter) he can do
> this. Of course most people expect their filter to work with standard file
> systems, and on the boot volume, etc. But if the individual wants to take
> the long time to do his own file system he can make his disk filter know
> the user. Of course at that point one has to ask if he would be better
> off writing a file system filter to do what he wants to do, but since we
> do not know the purpose of the disk filter this is not something we can
> determine.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
>
> “Daniel Terhell” wrote in message
> news:xxxxx@ntfsd…
>> Sorry, can you explain me why he cannot build a file system driver to
>> maintain a list of IRPs along with the processes and threads that
>> initiated the operations so that he can find them back in his disk filter
>> later when the IRPs have been passed down the stack and this information
>> is no longer available ?
>>
>> /Daniel
>>
>>
>> “Don Burn” wrote in message news:xxxxx@ntfsd…
>>> This has been answered many times, bottom line is you cannot get a
>>> useful ID at the disk level. For instance most cached I/O will show up
>>> as the system process even though a specific process is doing the
>>> request. There is no useful data at this level.
>>>
>>>
>>> –
>>> Don Burn (MVP, Windows DDK)
>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>> http://www.windrvr.com
>>> Remove StopSpam from the email to reply
>>>
>>>
>>> wrote in message news:xxxxx@ntfsd…
>>>> Hi.
>>>>
>>>> Is there any field in IRP that can be use by file system filter driver
>>>> or minifilter for its own purpose so that it can send some information
>>>> to disk filter driver such as process ID.
>>>> That field value should remain same across stack, as new IRP get
>>>> created across stack.
>>>> or
>>>> I want to know that, is there any solution that gives a process id at
>>>> disk filter driver level.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Sorry no, filter of course, not file system.
/Daniel
“Don Burn” wrote in message news:xxxxx@ntfsd…
> Well if he wants to write a file system (note not a filter) he can do
> this. Of course most people expect their filter to work with standard file
> systems, and on the boot volume, etc. But if the individual wants to take
> the long time to do his own file system he can make his disk filter know
> the user. Of course at that point one has to ask if he would be better
> off writing a file system filter to do what he wants to do, but since we
> do not know the purpose of the disk filter this is not something we can
> determine.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
>
> “Daniel Terhell” wrote in message
> news:xxxxx@ntfsd…
>> Sorry, can you explain me why he cannot build a file system driver to
>> maintain a list of IRPs along with the processes and threads that
>> initiated the operations so that he can find them back in his disk filter
>> later when the IRPs have been passed down the stack and this information
>> is no longer available ?
>>
>> /Daniel
>>
>>
>> “Don Burn” wrote in message news:xxxxx@ntfsd…
>>> This has been answered many times, bottom line is you cannot get a
>>> useful ID at the disk level. For instance most cached I/O will show up
>>> as the system process even though a specific process is doing the
>>> request. There is no useful data at this level.
>>>
>>>
>>> –
>>> Don Burn (MVP, Windows DDK)
>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>> http://www.windrvr.com
>>> Remove StopSpam from the email to reply
>>>
>>>
>>> wrote in message news:xxxxx@ntfsd…
>>>> Hi.
>>>>
>>>> Is there any field in IRP that can be use by file system filter driver
>>>> or minifilter for its own purpose so that it can send some information
>>>> to disk filter driver such as process ID.
>>>> That field value should remain same across stack, as new IRP get
>>>> created across stack.
>>>> or
>>>> I want to know that, is there any solution that gives a process id at
>>>> disk filter driver level.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Well the problem is the cache, which is not present in a network stack. A
large number of I/O operations hit the cache and get their data there. Now
take a cache write, this may become a read to get in the cached data, then
store the data into cache, with the write occuring a long time later, like
possibly after the application is gone (so what PID do you use then?).
To answer your second post, a filter will not work (ok it might work if you
make a big and weird enough one, but then write a filesystem) because the
I/O will still hit the cache. Of course, you could eliminate all caching,
but then your performance sucks, and little things like non-block aligned
or block sized I/O quit working.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
“Daniel Terhell” wrote in message
news:xxxxx@ntfsd…
> If you look at the firewall software it is often a combination of a TDI
> filter and some kind of NDIS driver. The TDI filter is often there only
> because it more high in the stack so they run in the context of the
> threads that initiated the I/O operations so this information can be
> saved for later. This is because the firewall needs to be able to block
> traffic depending on the process. What I never understood is why do IRPs
> not pass around this information themselves I mean as member of
> IO_STACK_LOCATION.
>
> /Daniel
>
>
> “Don Burn” wrote in message news:xxxxx@ntfsd…
>> Well if he wants to write a file system (note not a filter) he can do
>> this. Of course most people expect their filter to work with standard
>> file systems, and on the boot volume, etc. But if the individual wants
>> to take the long time to do his own file system he can make his disk
>> filter know the user. Of course at that point one has to ask if he
>> would be better off writing a file system filter to do what he wants to
>> do, but since we do not know the purpose of the disk filter this is not
>> something we can determine.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> http://www.windrvr.com
>> Remove StopSpam from the email to reply
>>
>>
>>
>> “Daniel Terhell” wrote in message
>> news:xxxxx@ntfsd…
>>> Sorry, can you explain me why he cannot build a file system driver to
>>> maintain a list of IRPs along with the processes and threads that
>>> initiated the operations so that he can find them back in his disk
>>> filter later when the IRPs have been passed down the stack and this
>>> information is no longer available ?
>>>
>>> /Daniel
>>>
>>>
>>> “Don Burn” wrote in message news:xxxxx@ntfsd…
>>>> This has been answered many times, bottom line is you cannot get a
>>>> useful ID at the disk level. For instance most cached I/O will show
>>>> up as the system process even though a specific process is doing the
>>>> request. There is no useful data at this level.
>>>>
>>>>
>>>> –
>>>> Don Burn (MVP, Windows DDK)
>>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>>> http://www.windrvr.com
>>>> Remove StopSpam from the email to reply
>>>>
>>>>
>>>> wrote in message news:xxxxx@ntfsd…
>>>>> Hi.
>>>>>
>>>>> Is there any field in IRP that can be use by file system filter
>>>>> driver or minifilter for its own purpose so that it can send some
>>>>> information to disk filter driver such as process ID.
>>>>> That field value should remain same across stack, as new IRP get
>>>>> created across stack.
>>>>> or
>>>>> I want to know that, is there any solution that gives a process id at
>>>>> disk filter driver level.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
I can…
The disk filter usually will not get the same IRPs that the filesystem got.
If it did, you wouldn’t need to keep a list and make the association, it
would be a simple matter of calling IoGetRequestorProcess.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Thursday, October 12, 2006 2:54 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] how to get process id at disk level ?
Sorry, can you explain me why he cannot build a file system driver to
maintain a list of IRPs along with the processes and threads that initiated
the operations so that he can find them back in his disk filter later when
the IRPs have been passed down the stack and this information is no longer
available ?
/Daniel
“Don Burn” wrote in message news:xxxxx@ntfsd…
> This has been answered many times, bottom line is you cannot get a
> useful
> ID at the disk level. For instance most cached I/O will show up as the
> system process even though a specific process is doing the request. There
> is no useful data at this level.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
> wrote in message news:xxxxx@ntfsd…
>> Hi.
>>
>> Is there any field in IRP that can be use by file system filter
>> driver or
>> minifilter for its own purpose so that it can send some information to
>> disk filter driver such as process ID.
>> That field value should remain same across stack, as new IRP get created
>> across stack.
>> or
>> I want to know that, is there any solution that gives a process id at
>> disk filter driver level.
>>
>>
>>
>
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Excuse me gentlemen, whereas this discussion has been of great interest, the
part i have missed is where a filter driver other than top of stack, can get
the desired process stuff, for sure, other than perhaps, or well perhaps
not, for some rather specific cases. I seek, as ever, enlightenment.
wrote in message news:xxxxx@ntfsd…
> Hi.
>
> Is there any field in IRP that can be use by file system filter driver or
> minifilter for its own purpose so that it can send some information to
> disk filter driver such as process ID.
> That field value should remain same across stack, as new IRP get created
> across stack.
> or
> I want to know that, is there any solution that gives a process id at disk
> filter driver level.
>
>
>
A pid is just a value which by itself does not make sense anyway to most of
us. What about maintaining a list of PIDs, their creation and termination
time stamps and the process name and paths that they map to ? It would be
nice if such a list were available always in the system because a lot of
drivers seem to be doing exactly the same thing.
/Daniel
“Don Burn” wrote in message news:xxxxx@ntfsd…
> Well the problem is the cache, which is not present in a network stack. A
> large number of I/O operations hit the cache and get their data there.
> Now take a cache write, this may become a read to get in the cached data,
> then store the data into cache, with the write occuring a long time later,
> like possibly after the application is gone (so what PID do you use
> then?).
>
> To answer your second post, a filter will not work (ok it might work if
> you make a big and weird enough one, but then write a filesystem) because
> the I/O will still hit the cache. Of course, you could eliminate all
> caching, but then your performance sucks, and little things like non-block
> aligned or block sized I/O quit working.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
>
> “Daniel Terhell” wrote in message
> news:xxxxx@ntfsd…
>> If you look at the firewall software it is often a combination of a TDI
>> filter and some kind of NDIS driver. The TDI filter is often there only
>> because it more high in the stack so they run in the context of the
>> threads that initiated the I/O operations so this information can be
>> saved for later. This is because the firewall needs to be able to block
>> traffic depending on the process. What I never understood is why do IRPs
>> not pass around this information themselves I mean as member of
>> IO_STACK_LOCATION.
>>
>> /Daniel
>>
>>
>> “Don Burn” wrote in message news:xxxxx@ntfsd…
>>> Well if he wants to write a file system (note not a filter) he can do
>>> this. Of course most people expect their filter to work with standard
>>> file systems, and on the boot volume, etc. But if the individual wants
>>> to take the long time to do his own file system he can make his disk
>>> filter know the user. Of course at that point one has to ask if he
>>> would be better off writing a file system filter to do what he wants to
>>> do, but since we do not know the purpose of the disk filter this is not
>>> something we can determine.
>>>
>>>
>>> –
>>> Don Burn (MVP, Windows DDK)
>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>> http://www.windrvr.com
>>> Remove StopSpam from the email to reply
>>>
>>>
>>>
>>> “Daniel Terhell” wrote in message
>>> news:xxxxx@ntfsd…
>>>> Sorry, can you explain me why he cannot build a file system driver to
>>>> maintain a list of IRPs along with the processes and threads that
>>>> initiated the operations so that he can find them back in his disk
>>>> filter later when the IRPs have been passed down the stack and this
>>>> information is no longer available ?
>>>>
>>>> /Daniel
>>>>
>>>>
>>>> “Don Burn” wrote in message news:xxxxx@ntfsd…
>>>>> This has been answered many times, bottom line is you cannot get a
>>>>> useful ID at the disk level. For instance most cached I/O will show
>>>>> up as the system process even though a specific process is doing the
>>>>> request. There is no useful data at this level.
>>>>>
>>>>>
>>>>> –
>>>>> Don Burn (MVP, Windows DDK)
>>>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>>>> http://www.windrvr.com
>>>>> Remove StopSpam from the email to reply
>>>>>
>>>>>
>>>>> wrote in message news:xxxxx@ntfsd…
>>>>>> Hi.
>>>>>>
>>>>>> Is there any field in IRP that can be use by file system filter
>>>>>> driver or minifilter for its own purpose so that it can send some
>>>>>> information to disk filter driver such as process ID.
>>>>>> That field value should remain same across stack, as new IRP get
>>>>>> created across stack.
>>>>>> or
>>>>>> I want to know that, is there any solution that gives a process id at
>>>>>> disk filter driver level.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
I think the IoGetRequestorProcess is not making sense in an arbitrary thread
context and is only for IRPs associated with a thread.
/Daniel
“Dan Kyler” wrote in message news:xxxxx@ntfsd…
>I can…
>
> The disk filter usually will not get the same IRPs that the filesystem
> got.
> If it did, you wouldn’t need to keep a list and make the association, it
> would be a simple matter of calling IoGetRequestorProcess.
>
> - Dan.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
> Sent: Thursday, October 12, 2006 2:54 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] how to get process id at disk level ?
>
>
> Sorry, can you explain me why he cannot build a file system driver to
> maintain a list of IRPs along with the processes and threads that
> initiated
> the operations so that he can find them back in his disk filter later when
> the IRPs have been passed down the stack and this information is no longer
> available ?
>
> /Daniel
>
>
> “Don Burn” wrote in message news:xxxxx@ntfsd…
>> This has been answered many times, bottom line is you cannot get a
>> useful
>> ID at the disk level. For instance most cached I/O will show up as the
>> system process even though a specific process is doing the request.
>> There
>
>> is no useful data at this level.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> http://www.windrvr.com
>> Remove StopSpam from the email to reply
>>
>>
>> wrote in message news:xxxxx@ntfsd…
>>> Hi.
>>>
>>> Is there any field in IRP that can be use by file system filter
>>> driver or
>>> minifilter for its own purpose so that it can send some information to
>>> disk filter driver such as process ID.
>>> That field value should remain same across stack, as new IRP get created
>>> across stack.
>>> or
>>> I want to know that, is there any solution that gives a process id at
>>> disk filter driver level.
>>>
>>>
>>>
>>
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
It is about installing a higher level driver and saving this process
information for a lower level driver. I am trying to understand if it is
possible at all for a disk driver to recognize requests that were passing
through a file system driver.
/Daniel
“Lyndon J. Clarke” wrote in message
news:xxxxx@ntfsd…
> Excuse me gentlemen, whereas this discussion has been of great interest,
> the part i have missed is where a filter driver other than top of stack,
> can get the desired process stuff, for sure, other than perhaps, or well
> perhaps not, for some rather specific cases. I seek, as ever,
> enlightenment.
>
> wrote in message news:xxxxx@ntfsd…
>> Hi.
>>
>> Is there any field in IRP that can be use by file system filter driver or
>> minifilter for its own purpose so that it can send some information to
>> disk filter driver such as process ID.
>> That field value should remain same across stack, as new IRP get created
>> across stack.
>> or
>> I want to know that, is there any solution that gives a process id at
>> disk filter driver level.
>>
>>
>>
>
>
>
“Daniel Terhell” wrote in message
news:xxxxx@ntfsd…
> It is about installing a higher level driver and saving this process
> information for a lower level driver. I am trying to understand if it is
> possible at all for a disk driver to recognize requests that were passing
> through a file system driver.
>
> /Daniel
That is it, many requests do not pass through a file system, they end there
and some related but unassociated request then goes to the disk. So you
loose all the context.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
Disk IRPs are not FSD’s IRPs, and the association between the 2 exist
inside the FSD only and is not visible for the filters.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Daniel Terhell”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Friday, October 13, 2006 12:54 AM
Subject: Re:[ntfsd] how to get process id at disk level ?
> Sorry, can you explain me why he cannot build a file system driver to
> maintain a list of IRPs along with the processes and threads that initiated
> the operations so that he can find them back in his disk filter later when
> the IRPs have been passed down the stack and this information is no longer
> available ?
>
> /Daniel
>
>
> “Don Burn” wrote in message news:xxxxx@ntfsd…
> > This has been answered many times, bottom line is you cannot get a useful
> > ID at the disk level. For instance most cached I/O will show up as the
> > system process even though a specific process is doing the request. There
> > is no useful data at this level.
> >
> >
> > –
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > http://www.windrvr.com
> > Remove StopSpam from the email to reply
> >
> >
> > wrote in message news:xxxxx@ntfsd…
> >> Hi.
> >>
> >> Is there any field in IRP that can be use by file system filter driver or
> >> minifilter for its own purpose so that it can send some information to
> >> disk filter driver such as process ID.
> >> That field value should remain same across stack, as new IRP get created
> >> across stack.
> >> or
> >> I want to know that, is there any solution that gives a process id at
> >> disk filter driver level.
> >>
> >>
> >>
> >
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com