I’m trying to use IrpTracker to hunt down an issue that results in
undeleteable files. I’m trying to use it at two points, 1) to track the
IRPs at the time the file gets created, written, and closed, and 2) to
see what is happening when I try to delete the file. Unfortunately,
since Windows does so much “stuff” in the background, I’m capturing
*way* more IRPs than are relevant to my issue. The other problem, is
that the driver I’m having trouble with is a minifilter driver, so
virtually everything goes through it. Even if I could pick it out of
the device tree or give the driver image name, if I understand
IrpTracker correctly, I’m still going to see virtually every IRP.
What would be *really* helpful would be to be able to filter Irps by the
name of the userland process that begot them with Track Life Of Irps on.
Is there any way to do this or something like this? Are there any other
tricks that I can use to make the output more manageable?
Thanks,
~Eric
eric,
this might be off topic, but have u considered using filemon? is that of any
use to you?
ab
On 9/12/07, Eric Diven wrote:
>
> I’m trying to use IrpTracker to hunt down an issue that results in
> undeleteable files. I’m trying to use it at two points, 1) to track the
> IRPs at the time the file gets created, written, and closed, and 2) to
> see what is happening when I try to delete the file. Unfortunately,
> since Windows does so much “stuff” in the background, I’m capturing
> way more IRPs than are relevant to my issue. The other problem, is
> that the driver I’m having trouble with is a minifilter driver, so
> virtually everything goes through it. Even if I could pick it out of
> the device tree or give the driver image name, if I understand
> IrpTracker correctly, I’m still going to see virtually every IRP.
>
> What would be really helpful would be to be able to filter Irps by the
> name of the userland process that begot them with Track Life Of Irps on.
> Is there any way to do this or something like this? Are there any other
> tricks that I can use to make the output more manageable?
>
> Thanks,
>
> ~Eric
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
- amitr0
Not off topic at all, I’ll take a look at it tomorrow, thanks. I’m
always open to suggesions of more appropriate tools for the task at
hand.
~Eric
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Tuesday, September 11, 2007 5:01 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] IrpTracker use guidance please
eric,
this might be off topic, but have u considered using filemon? is that of
any use to you?
ab
On 9/12/07, Eric Diven wrote:
I’m trying to use IrpTracker to hunt down an issue that results
in
undeleteable files. I’m trying to use it at two points, 1) to
track the
IRPs at the time the file gets created, written, and closed, and
2) to
see what is happening when I try to delete the file.
Unfortunately,
since Windows does so much “stuff” in the background, I’m
capturing
way more IRPs than are relevant to my issue. The other
problem, is
that the driver I’m having trouble with is a minifilter driver,
so
virtually everything goes through it. Even if I could pick it
out of
the device tree or give the driver image name, if I understand
IrpTracker correctly, I’m still going to see virtually every
IRP.
What would be really helpful would be to be able to filter
Irps by the
name of the userland process that begot them with Track Life Of
Irps on.
Is there any way to do this or something like this? Are there
any other
tricks that I can use to make the output more manageable?
Thanks,
~Eric
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
–
- amitr0 — NTFSD is sponsored by OSR For our schedule debugging and
file system seminars (including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars You are currently subscribed to ntfsd as:
xxxxx@edsiohio.com To unsubscribe send a blank email to
xxxxx@lists.osr.com
I have always found sysinternals filemon very helpful in debugging FS
issues.
all the best.
AB
On 9/12/07, Eric Diven wrote:
>
> Not off topic at all, I’ll take a look at it tomorrow, thanks. I’m
> always open to suggesions of more appropriate tools for the task at hand.
>
> ~Eric
>
> ------------------------------
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *amitr0
> Sent: Tuesday, September 11, 2007 5:01 PM
> To: Windows File Systems Devs Interest List
> Subject: Re: [ntfsd] IrpTracker use guidance please
>
>
> eric,
>
> this might be off topic, but have u considered using filemon? is that of
> any use to you?
>
> ab
>
>
> On 9/12/07, Eric Diven wrote:
> >
> > I’m trying to use IrpTracker to hunt down an issue that results in
> > undeleteable files. I’m trying to use it at two points, 1) to track the
> >
> > IRPs at the time the file gets created, written, and closed, and 2) to
> > see what is happening when I try to delete the file. Unfortunately,
> > since Windows does so much “stuff” in the background, I’m capturing
> > way more IRPs than are relevant to my issue. The other problem, is
> > that the driver I’m having trouble with is a minifilter driver, so
> > virtually everything goes through it. Even if I could pick it out of
> > the device tree or give the driver image name, if I understand
> > IrpTracker correctly, I’m still going to see virtually every IRP.
> >
> > What would be really helpful would be to be able to filter Irps by the
> > name of the userland process that begot them with Track Life Of Irps on.
> >
> > Is there any way to do this or something like this? Are there any other
> > tricks that I can use to make the output more manageable?
> >
> > Thanks,
> >
> > ~Eric
> >
> > —
> > NTFSD is sponsored by OSR
> >
> > For our schedule debugging and file system seminars
> > (including our new fs mini-filter seminar) visit:
> > http://www.osr.com/seminars
> >
> > You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
> > ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
> –
>
> - amitr0 — NTFSD is sponsored by OSR For our schedule debugging and file
> system seminars (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars You are currently subscribed to ntfsd as:
> xxxxx@edsiohio.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
>
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
- amitr0
Hi,
You’re right, it is voluminous and I agree, we need better filtering/search
capabilities However, that doesn’t help you in the short term…
Some tips which may or may not be useful/obvious:
-
The first thing I do when I have a problem like this is try to repro the
issue on something other than the boot drive. If you’re I/O is the only I/O
going to the drive life is way easier.
-
If you save the output to a file you get the process name there, so you
could scan for the I/Os that way (this might a a bit like looking for a
needle in a haystack though. The only good thing about this approach is that
it’s sure to cure your insomnia).
HTH,
-scott
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Eric Diven” wrote in message news:xxxxx@ntfsd…
I’m trying to use IrpTracker to hunt down an issue that results in
undeleteable files. I’m trying to use it at two points, 1) to track the
IRPs at the time the file gets created, written, and closed, and 2) to
see what is happening when I try to delete the file. Unfortunately,
since Windows does so much “stuff” in the background, I’m capturing
way more IRPs than are relevant to my issue. The other problem, is
that the driver I’m having trouble with is a minifilter driver, so
virtually everything goes through it. Even if I could pick it out of
the device tree or give the driver image name, if I understand
IrpTracker correctly, I’m still going to see virtually every IRP.
What would be really helpful would be to be able to filter Irps by the
name of the userland process that begot them with Track Life Of Irps on.
Is there any way to do this or something like this? Are there any other
tricks that I can use to make the output more manageable?
Thanks,
~Eric
Wow, moving off of the boot drive is a phenomenal improvement in the
volume of data to analyze. Thanks! I don’t see the process name in the
log file though. I’m running IrpTracker 2.18, and when I save to a log
file, I get the same columns as in the scrolling display, minus the time
of the IRP. A snippet from the log file:
Call 0x8162AD30-0 \Device\HarddiskVolume2 (0x81BBA688)
PartMgr WRITE NORMAL
Call 0x8162AD30-0 (0x81BBA688) PartMgr
\Device\Harddisk1\DR1 WRITE NORMAL
Comp 0x8162AD30-0 \Device\Harddisk1\DR1 WRITE
CLASSP_VOLUME_VERIFY_CHECKED SUCCESS, Info = 0x1000
CompRoutine 0x8162AD30-0 \Device\HarddiskVolume2 WRITE
NORMAL SUCCESS
CompRoutine 0x8162AD30-0 (0x81B17850) VolSnap WRITE
NORMAL SUCCESS
Is there some option I need to set some where to get the process name in
this too? I’ve read through the help, and didn’t see anything.
Thanks,
~Eric
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Wednesday, September 12, 2007 10:26 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] IrpTracker use guidance please
Hi,
You’re right, it is voluminous and I agree, we need better
filtering/search capabilities However, that doesn’t help you in the
short term…
Some tips which may or may not be useful/obvious:
-
The first thing I do when I have a problem like this is try to repro
the issue on something other than the boot drive. If you’re I/O is the
only I/O going to the drive life is way easier.
-
If you save the output to a file you get the process name there, so
you could scan for the I/Os that way (this might a a bit like looking
for a needle in a haystack though. The only good thing about this
approach is that it’s sure to cure your insomnia).
HTH,
-scott
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
OK, so, I lied 
Upon closer inspection, the process name is only there if you also turn on
the Native API tracking. That won’t show the process name on each individual
IRP line, but it’ll give it to you on the native API line.
-scott
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Eric Diven” wrote in message news:xxxxx@ntfsd…
Wow, moving off of the boot drive is a phenomenal improvement in the
volume of data to analyze. Thanks! I don’t see the process name in the
log file though. I’m running IrpTracker 2.18, and when I save to a log
file, I get the same columns as in the scrolling display, minus the time
of the IRP. A snippet from the log file:
Call 0x8162AD30-0 \Device\HarddiskVolume2 (0x81BBA688)
PartMgr WRITE NORMAL
Call 0x8162AD30-0 (0x81BBA688) PartMgr
\Device\Harddisk1\DR1 WRITE NORMAL
Comp 0x8162AD30-0 \Device\Harddisk1\DR1 WRITE
CLASSP_VOLUME_VERIFY_CHECKED SUCCESS, Info = 0x1000
CompRoutine 0x8162AD30-0 \Device\HarddiskVolume2 WRITE
NORMAL SUCCESS
CompRoutine 0x8162AD30-0 (0x81B17850) VolSnap WRITE
NORMAL SUCCESS
Is there some option I need to set some where to get the process name in
this too? I’ve read through the help, and didn’t see anything.
Thanks,
~Eric
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Wednesday, September 12, 2007 10:26 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] IrpTracker use guidance please
Hi,
You’re right, it is voluminous and I agree, we need better
filtering/search capabilities However, that doesn’t help you in the
short term…
Some tips which may or may not be useful/obvious:
1) The first thing I do when I have a problem like this is try to repro
the issue on something other than the boot drive. If you’re I/O is the
only I/O going to the drive life is way easier.
2) If you save the output to a file you get the process name there, so
you could scan for the I/Os that way (this might a a bit like looking
for a needle in a haystack though. The only good thing about this
approach is that it’s sure to cure your insomnia).
HTH,
-scott
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
Also File Spy is very usefull tool. You can attach it to any FS device (not only to mapped drive). It has also nice filtering abilities. see http://www.zezula.net/