Re: Event tracing in Procmon by Sysinternals

(Moving this over to NTFSD)

Sounds like you have a bug in your filter, you should certainly see paging
file I/O. Did you set FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO by any
chance? Also, FAT and NTFS do not support per-stream contexts on paging
files, which might be an issue for your filter.

-scott


Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Pavel Sokolov” wrote in message news:xxxxx@ntdev…

I’m trying to get information about reads/writes in the system and almost
finished a minifilter. But it doesn’t look so good.
minifilter doesn’t receive operations with pagefile and few other system
files.
Procmon (by sysinternals) can see this operations and it uses Event Tracing.
But how it works? Looks like operation system
already have file/io provider and driver isn’t required, only usermode app.
But as I see in traceview WDK sample, there is no
filenames, only FileObj pointers -how to resolve them to filenames in
usermode?
Is there any good documentation about event tracing? Msdn (in this part)
isn’t easy to understand.


Pavel Sokolov

> Sounds like you have a bug in your filter, you should certainly see paging

file I/O. Did you set FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO by any
chance? Also, FAT and NTFS do not support per-stream contexts on paging
files, which might be an issue for your filter.

My minifilter is based on WDK sample (minispy), so there is no FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO.


Pavel Sokolov

Do you ever see a create arrive with SL_OPEN_PAGING_FILE set?

-scott


Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Pavel Sokolov” wrote in message news:xxxxx@ntfsd…

Sounds like you have a bug in your filter, you should certainly see paging
file I/O. Did you set FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO by any
chance? Also, FAT and NTFS do not support per-stream contexts on paging
files, which might be an issue for your filter.

My minifilter is based on WDK sample (minispy), so there is no
FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO.


Pavel Sokolov

> Do you ever see a create arrive with SL_OPEN_PAGING_FILE set?

No. How I can receive it when user mode application loades the driver dynamically.
Windows opens pagefile every time to access it?

This is the reason to try Event tracing and my original post is about event tracing, not about minifilter.
I think that application without driver is better than with driver.


Pavel Sokolov

>No. How I can receive it when user mode application loades the driver

dynamically.

Where was that again in your original post?

This is the reason to try Event tracing and my original post is about event
tracing, not about minifilter.

Just because you miss the create doesn’t mean you’ll miss the I/Os, I was
just trying to understand the situation by asking if you even see the
create.

But, I digress…You’ve already chosen your new solution without
understanding why your existing one is insufficient, so I’ll stop bothering.
Good luck.

-scott


Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

> Just because you miss the create doesn’t mean you’ll miss the I/Os, I was just trying to understand the situation by asking if

you even see the create.

I can’t see any activity on the drive where page file is located. Even if I stimulate it to grow or shrink. Driver code wasn’t
changed in processing or any other significant parts.

But, I digress…You’ve already chosen your new solution without understanding why your existing one is insufficient, so I’ll
stop bothering. Good luck.

I’m ready to try to fix it. Can you help me? 99.9% of driver code is the same as original sample in WDK (removed unwanted
operations, because I want to see only write operations ).


Pavel Sokolov

Scott,

I think that might be a bit harsh. I’d like to hear if there is a way to accomplish entirely in user-mode, what I’m using a minifilter to do. I suspect that the ETW is used as part of the whole, not the whole data-gathering mechanism, though I’m not sure what part it plays. I could see using ETW as the transport between PROCMON20 and the procmon process, possibly. But I don’t know how Mark and/or Bryce did it, and would be interested to hear anyone’s thoughts on the matter.

Phil
Philip D. Barila (303) 776-1264

>I think that might be a bit harsh. I’d like to hear if there is a way to

accomplish entirely in user-mode,
what I’m using a minifilter to do.

That is of course entirely legit. However this entire thread started out
because the OP decided that minifilters can’t see page file I/O but ETW can,
which is wrong and bad for the archives. Understanding what was going on
there might have helped those with a similar problem in the future or helped
the OP make a more informed decision about what the right solution would be
going forward.

From my perspective, once the OP no longer seemed interested in figuring out
what’s going on in their minifilter I decided to step out and let others
with more knowledge of the various ETW trace points step in. Hopefully we’ll
get an answer.

-scott


Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntfsd…

Scott,

I think that might be a bit harsh. I’d like to hear if there is a way to
accomplish entirely in user-mode, what I’m using a minifilter to do. I
suspect that the ETW is used as part of the whole, not the whole
data-gathering mechanism, though I’m not sure what part it plays. I could
see using ETW as the transport between PROCMON20 and the procmon process,
possibly. But I don’t know how Mark and/or Bryce did it, and would be
interested to hear anyone’s thoughts on the matter.

Phil
Philip D. Barila (303) 776-1264

> I think that might be a bit harsh. I’d like to hear if there is a way to accomplish entirely in user-mode, what I’m using a

minifilter to do. I suspect that the ETW is used as part of the whole, not the whole data-gathering mechanism, though I’m not
sure what part it plays. I could see using ETW as the transport between PROCMON20 and the procmon process, possibly. But I
don’t know how Mark and/or Bryce did it, and would be interested to hear anyone’s thoughts on the matter.

It looks like it can. But I can’t be sure due to my really small knowledge in drivers.

\WinDDK\tools\tracing\i386\traceview.exe

Add New Log Session -> Add provider -> Kernel Logger (FileIO & DiskIO )


Pavel Sokolov

Event tracing doesn’t have anything to do with File I/O. It is merely a way how to deliver events from one component to another. So, there must be a minifilter that captures I/O events and pushes them to the queue provided by ETW. And the user mode application pops them and shows them to the user in a friendly way.

I don’t know how Procmon does it, but I guess it’s Minifilter ==> ETW ==> UserMode, the same way how FileSpy does it, using the FileTrace driver.

Since Vista, there is FileTrace driver, that is basically a MiniSpy-based minifilter, which stuffs ETW with I/O events, and an user mode application can utilize them. So yes, it can be done without driver, or at least without driver written by you.

L.

When I last looked at this (which was prior to Vista), there was a trace point in the storage stack – at the partition manager, perhaps? It was remarkably effective at getting File I/O based on the FILE_OBJECT in the IRP.

The system-provided ETW trace-points are *very* cool and useful. If only they were nicely documented…

Peter
OSR

> When I last looked at this (which was prior to Vista), there was a trace point in the storage stack –

at the partition manager, perhaps? It was remarkably effective at getting File I/O based on the
FILE_OBJECT in the IRP.

By “File I/O” you mean “Disk I/O”, is that correct?

I haven’t really followed this thread, but, for what it’s worth, I was
hesitant to take a look at ETW for a long time because in my mind, ETW ==
WPP, which isn’t really the case. As Peter, said, ETW is capable of some
very cool stuff.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, February 08, 2011 9:21 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Re: Event tracing in Procmon by Sysinternals

When I last looked at this (which was prior to Vista), there was a trace
point in the storage stack – at the partition manager, perhaps? It was
remarkably effective at getting File I/O based on the FILE_OBJECT in the
IRP.

The system-provided ETW trace-points are *very* cool and useful. If only
they were nicely documented…

Peter
OSR


NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

After some testing and searching for documentation(it was really hard) I see that it’s not possible to see pagefile operations
with ETW and system ‘NT Kernel Logger’. After analyzing of procmon logs, it look like they use minifilter (or other driver)
because there is some information that is not presented in the ETW logs.
So, I still trying to find the way to see the pagefile operations in minifilter (procmon do this, but how…)


Pavel Sokolov

You are not going to see the create if you load the driver dynamically.
For the mini-filters I’ve done that were dealing with the page file,
loading them early was a prerequisite. As Scott pointed out your
mini-filter has a bug, seeing paging I/O is definitely something a
minifilter can do.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Scott Noone” wrote in message news:xxxxx@ntfsd:

> >No. How I can receive it when user mode application loades the driver
> >dynamically.
>
> Where was that again in your original post?
>
> >This is the reason to try Event tracing and my original post is about event
> >tracing, not about minifilter.
>
> Just because you miss the create doesn’t mean you’ll miss the I/Os, I was
> just trying to understand the situation by asking if you even see the
> create.
>
> But, I digress…You’ve already chosen your new solution without
> understanding why your existing one is insufficient, so I’ll stop bothering.
> Good luck.
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com

> You are not going to see the create if you load the driver dynamically.

For the mini-filters I’ve done that were dealing with the page file,
loading them early was a prerequisite. As Scott pointed out your
mini-filter has a bug, seeing paging I/O is definitely something a
minifilter can do.

But procmon can see it!


Pavel Sokolov

Don’s point is that you’re going to miss the create, not that you’ll miss
the I/Os.

If I take an otherwise unmodified minispy and add this to the beginning of
SpyPreOperationCallback:

if (Data->Iopb->MajorFunction == IRP_MJ_READ ||
Data->Iopb->MajorFunction == IRP_MJ_WRITE) {

if (FsRtlIsPagingFile(FltObjects->FileObject)) {
DbgPrint(“PAGING FILE\n”);
}
}

I start getting DbgPrints after manually attaching to c: on Win7.

Note that there was an issue on older platforms where FsRtlPagingFile wasn’t
correct for the first few operations on the file, as reported here:

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

In that case you would indeed need to be attached early and catch the create
so that you could track the paging file yourself (or use some other
heuristic to determine that it is a paging file).

-scott


Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Pavel Sokolov” wrote in message news:xxxxx@ntfsd…

You are not going to see the create if you load the driver dynamically.
For the mini-filters I’ve done that were dealing with the page file,
loading them early was a prerequisite. As Scott pointed out your
mini-filter has a bug, seeing paging I/O is definitely something a
minifilter can do.

But procmon can see it!


Pavel Sokolov

> I start getting DbgPrints after manually attaching to c: on Win7.

Note that there was an issue on older platforms where FsRtlPagingFile wasn’t correct for the first few operations on the file,
as reported here:

Thank you very much! I’m trying to find the problem right now.
However, Is there possibility that I have installed the driver in the wrong way?
Each time my GUI creates the service with my driver and starts it. But I found that .inf file(supplied with minifilter driver
sample) have some additional values like:

Class = “ActivityMonitor” ;This is determined by the work this filter driver does
ClassGuid = {b86dff51-a31e-4bac-b3cf-e8cfe75c9fc2} ;This value is determined by the Class

Is it necessary?


Pavel Sokolov