Problems when IRP is pend from Filter driver with Anti Virus real time protection

OSR_Community_User · May 21, 2005, 4:23am

Hi,

I have a filter driver on Windows 2000, which pends some IRPs from some
application and then communicates with user mode application about the
request and the user mode application tries to open the file and the filter
driver does not block requests from this application.

In the above case with anti virus real time protection the user mode
application is not able to open file.

Could any one tell what could be the problem.

I think that anti virus is trying to open the file.

Any information is helpful.

Thanks,
Kedar.

OSR_Community_User · May 21, 2005, 4:24am

I am pending IRP_MJ_READ’s in the filter driver.

“kedar” wrote in message news:xxxxx@ntfsd…
> Hi,
>
> I have a filter driver on Windows 2000, which pends some IRPs from some
> application and then communicates with user mode application about the
> request and the user mode application tries to open the file and the
> filter driver does not block requests from this application.
>
> In the above case with anti virus real time protection the user mode
> application is not able to open file.
>
> Could any one tell what could be the problem.
>
> I think that anti virus is trying to open the file.
>
> Any information is helpful.
>
> Thanks,
> Kedar.
>
>

OSR_Community_User · May 22, 2005, 9:36am

Kedar,

Are you having a sharing or access collision? Meaning that the IRP you are
pended ahs been opened with some access and sharing, you then pend this and
the user application tries to open it. The user applications attempt to open
the file may have conflicting share or access and thus the open will fail.

What is the failure code the user application is getting back when it tries
to open the file? You can track this in your filter since you ‘know’ when
the user application is trying to open the file.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of kedar
Sent: Saturday, May 21, 2005 2:22 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Problems when IRP is pend from Filter driver with Anti
Virus real time protection

Hi,

I have a filter driver on Windows 2000, which pends some IRPs from some
application and then communicates with user mode application about the
request and the user mode application tries to open the file and the filter
driver does not block requests from this application.

In the above case with anti virus real time protection the user mode
application is not able to open file.

Could any one tell what could be the problem.

I think that anti virus is trying to open the file.

Any information is helpful.

Thanks,
Kedar.

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

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

OSR_Community_User · May 23, 2005, 1:43am

Hi Pete,

There is no request reaching to Filter driver and the user application goes
to freeze state.

Thanks,
Kedar.

“Peter Scott” wrote in message
news:xxxxx@ntfsd…
>
> Kedar,
>
> Are you having a sharing or access collision? Meaning that the IRP you are
> pended ahs been opened with some access and sharing, you then pend this
> and
> the user application tries to open it. The user applications attempt to
> open
> the file may have conflicting share or access and thus the open will fail.
>
> What is the failure code the user application is getting back when it
> tries
> to open the file? You can track this in your filter since you ‘know’ when
> the user application is trying to open the file.
>
> Pete
>
> Kernel Drivers
> Windows Filesystem and Device Driver Consulting
> www.KernelDrivers.com
> (303)546-0300
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of kedar
> Sent: Saturday, May 21, 2005 2:22 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Problems when IRP is pend from Filter driver with Anti
> Virus real time protection
>
> Hi,
>
> I have a filter driver on Windows 2000, which pends some IRPs from some
> application and then communicates with user mode application about the
> request and the user mode application tries to open the file and the
> filter
> driver does not block requests from this application.
>
> In the above case with anti virus real time protection the user mode
> application is not able to open file.
>
> Could any one tell what could be the problem.
>
> I think that anti virus is trying to open the file.
>
> Any information is helpful.
>
> Thanks,
> Kedar.
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

OSR_Community_User · May 23, 2005, 2:49am

Well, I’m currently solving the similar problem.
Our filter acquires a file lock, then calls lower driver
for IRP_MJ_SET_INFORMATION. The lower driver
seems to communicate with the user mode for some reason.
Because the file is still locked, the deadlock comes.

This may be the same problem as you have - the upper
antivirus filter has acquired some lock and you then
wait for some user mode service. If the service touches
anything that has to do with the locked file (it may be a registry
hive), the deadlock occurs.

IMHO is not safe to call usermode in the IRP
dispatch handlers except IRP_MJ_CREATE handler.
If you waiting for user mode within READ path, it might be the
same scenario.

I would also like to know other’s opinions,
with considering above described situation.

If you would be willing, you may expose the deadlock crash
dump, I would like to download it and look at it.

L.

OSR_Community_User · May 23, 2005, 10:45am

Hi,

I am not seeing any crash here.

Thanks,
Kedar.
“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> Well, I’m currently solving the similar problem.
> Our filter acquires a file lock, then calls lower driver
> for IRP_MJ_SET_INFORMATION. The lower driver
> seems to communicate with the user mode for some reason.
> Because the file is still locked, the deadlock comes.
>
> This may be the same problem as you have - the upper
> antivirus filter has acquired some lock and you then
> wait for some user mode service. If the service touches
> anything that has to do with the locked file (it may be a registry
> hive), the deadlock occurs.
>
> IMHO is not safe to call usermode in the IRP
> dispatch handlers except IRP_MJ_CREATE handler.
> If you waiting for user mode within READ path, it might be the
> same scenario.
>
> I would also like to know other’s opinions,
> with considering above described situation.
>
> If you would be willing, you may expose the deadlock crash
> dump, I would like to download it and look at it.
>
> L.
>
>

OSR_Community_User · May 23, 2005, 11:19am

Kedar,

It is quite easy to determine the deadlock if you have a debugger attached.
I would suggest you do this to determine exactly what is causing the lock in
the system.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of kedar
Sent: Monday, May 23, 2005 8:44 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Problems when IRP is pend from Filter driver with Anti
Virus real time protection

Hi,

I am not seeing any crash here.

Thanks,
Kedar.
“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> Well, I’m currently solving the similar problem.
> Our filter acquires a file lock, then calls lower driver
> for IRP_MJ_SET_INFORMATION. The lower driver
> seems to communicate with the user mode for some reason.
> Because the file is still locked, the deadlock comes.
>
> This may be the same problem as you have - the upper
> antivirus filter has acquired some lock and you then
> wait for some user mode service. If the service touches
> anything that has to do with the locked file (it may be a registry
> hive), the deadlock occurs.
>
> IMHO is not safe to call usermode in the IRP
> dispatch handlers except IRP_MJ_CREATE handler.
> If you waiting for user mode within READ path, it might be the
> same scenario.
>
> I would also like to know other’s opinions,
> with considering above described situation.
>
> If you would be willing, you may expose the deadlock crash
> dump, I would like to download it and look at it.
>
> L.
>
>

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

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

OSR_Community_User · May 25, 2005, 3:15am

> I am not seeing any crash here.

I know. I meant that you may crash the system manually
using the “Ctrl+ScrollLock” method.

To achieve this, you have to switch the feature on using
this registry file:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters]
“CrashOnCtrlScroll”=dword:00000001

Import this file into the registry and reboot. Then,
any time when you hit right Ctrl and Scroll lock twice,
the keyboard driver will call the KeBugCheck
function. The generated crash dump (if set)
maybe used for crash dump analysis
(at least I analyze deadlocks this way).

L.

OSR_Community_User · May 25, 2005, 10:08am

Hi Ladislav Zezula,

How to detect the dead lock once the crash is obtained?

Thanks,
Kedar.
“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
>> I am not seeing any crash here.
>
> I know. I meant that you may crash the system manually
> using the “Ctrl+ScrollLock” method.
>
> To achieve this, you have to switch the feature on using
> this registry file:
>
> Windows Registry Editor Version 5.00
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters]
> “CrashOnCtrlScroll”=dword:00000001
>
> Import this file into the registry and reboot. Then,
> any time when you hit right Ctrl and Scroll lock twice,
> the keyboard driver will call the KeBugCheck
> function. The generated crash dump (if set)
> maybe used for crash dump analysis
> (at least I analyze deadlocks this way).
>
> L.
>
>

OSR_Community_User · May 25, 2005, 11:36am

Start with “!locks” in WinDBG (using “!analyze -v” doesn’t help much in
this instance, although it does refer you to a nice KB article that says
“to prevent this crash in the future, don’t crash the system manually.”)
For XP and W2K3 I find that “!stacks” is sometimes helpful as well in
finding potential threads.

The goal is to find the threads that are not progressing, but should be,
and figure out why they aren’t progressing.

Oh, in this SPECIFIC case you might also find “!apc” might yield useful
information. I see this happen sometimes when someone pends an I/O
operation at APC_LEVEL or with special kernel APCs disabled, either of
which means the pended I/O operation will not be completed.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of kedar
Sent: Wednesday, May 25, 2005 10:07 AM
To: ntfsd redirect
Subject: Re:[ntfsd] Re:Problems when IRP is pend from Filter driver with
Anti Virus real time protection

Hi Ladislav Zezula,

How to detect the dead lock once the crash is obtained?

Thanks,
Kedar.
“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
>> I am not seeing any crash here.
>
> I know. I meant that you may crash the system manually
> using the “Ctrl+ScrollLock” method.
>
> To achieve this, you have to switch the feature on using
> this registry file:
>
> Windows Registry Editor Version 5.00
>
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameter
s]
> “CrashOnCtrlScroll”=dword:00000001
>
> Import this file into the registry and reboot. Then,
> any time when you hit right Ctrl and Scroll lock twice,
> the keyboard driver will call the KeBugCheck
> function. The generated crash dump (if set)
> maybe used for crash dump analysis
> (at least I analyze deadlocks this way).
>
> L.
>
>

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

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

OSR_Community_User · May 25, 2005, 3:21pm

!locks only shows ERESOURCE locks, not events.

!process 0 7 is a way to go (note: it is long over the serial port).

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

----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, May 25, 2005 7:35 PM
Subject: RE: [ntfsd] Re:Problems when IRP is pend from Filter driver with Anti
Virus real time protection

Start with “!locks” in WinDBG (using “!analyze -v” doesn’t help much in
this instance, although it does refer you to a nice KB article that says
“to prevent this crash in the future, don’t crash the system manually.”)
For XP and W2K3 I find that “!stacks” is sometimes helpful as well in
finding potential threads.

The goal is to find the threads that are not progressing, but should be,
and figure out why they aren’t progressing.

Oh, in this SPECIFIC case you might also find “!apc” might yield useful
information. I see this happen sometimes when someone pends an I/O
operation at APC_LEVEL or with special kernel APCs disabled, either of
which means the pended I/O operation will not be completed.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of kedar
Sent: Wednesday, May 25, 2005 10:07 AM
To: ntfsd redirect
Subject: Re:[ntfsd] Re:Problems when IRP is pend from Filter driver with
Anti Virus real time protection

Hi Ladislav Zezula,

How to detect the dead lock once the crash is obtained?

Thanks,
Kedar.
“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
>> I am not seeing any crash here.
>
> I know. I meant that you may crash the system manually
> using the “Ctrl+ScrollLock” method.
>
> To achieve this, you have to switch the feature on using
> this registry file:
>
> Windows Registry Editor Version 5.00
>
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameter
s]
> “CrashOnCtrlScroll”=dword:00000001
>
> Import this file into the registry and reboot. Then,
> any time when you hit right Ctrl and Scroll lock twice,
> the keyboard driver will call the KeBugCheck
> function. The generated crash dump (if set)
> maybe used for crash dump analysis
> (at least I analyze deadlocks this way).
>
> L.
>
>

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

You are currently subscribed to ntfsd as: xxxxx@osr.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: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · May 26, 2005, 12:37am

> !locks only shows ERESOURCE locks, not events.

Yes. To Kedar: If the deadlock is caused by held resources,
the way t find a deadlock is quite fast. If not, I recommend to
remember what process is hung and the list all processes.
Then you can list all thread of a process with their call stack
and try to figure out which one is hung and why.
Look for threads with stack going through your filter.

!process 0 7 is a way to go (note: it is long over the serial port).

It is qute long even with a crash dump. It is necessary
to reserve some amount of time to analyze deadlock -
don’t expect that there is a simple way how to find
cause of a deadlock.

As I remember, my first analyze of a deadlock was quite
fast, because I knew which process hung first and the deadlock
was caused by held resources. So I was lucky, hopefully
you’ll be lucky too.

Again, if you’ll be willing to share the crash dump (or even
symbols for your filter driver), I would like to look at it,
because I’m still looking for the answer to question
“Is it safe to wait for user mode in an IRP dispatch handler
except IRP_MJ_CREATE ?”

L.

OSR_Community_User · June 2, 2005, 8:29am

Hi Pete,

I am using !threads and !stack command from Windbg but not able to go ahead
with the information that it gives.

Could you please give me any pointers on how to find out the deadlock?

Thanks,
Kedar,
“Peter Scott” wrote in message
news:xxxxx@ntfsd…
>
> Kedar,
>
> It is quite easy to determine the deadlock if you have a debugger
> attached.
> I would suggest you do this to determine exactly what is causing the lock
> in
> the system.
>
> Pete
>
> Kernel Drivers
> Windows Filesystem and Device Driver Consulting
> www.KernelDrivers.com
> (303)546-0300
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of kedar
> Sent: Monday, May 23, 2005 8:44 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Problems when IRP is pend from Filter driver with Anti
> Virus real time protection
>
> Hi,
>
> I am not seeing any crash here.
>
> Thanks,
> Kedar.
> “Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
>> Well, I’m currently solving the similar problem.
>> Our filter acquires a file lock, then calls lower driver
>> for IRP_MJ_SET_INFORMATION. The lower driver
>> seems to communicate with the user mode for some reason.
>> Because the file is still locked, the deadlock comes.
>>
>> This may be the same problem as you have - the upper
>> antivirus filter has acquired some lock and you then
>> wait for some user mode service. If the service touches
>> anything that has to do with the locked file (it may be a registry
>> hive), the deadlock occurs.
>>
>> IMHO is not safe to call usermode in the IRP
>> dispatch handlers except IRP_MJ_CREATE handler.
>> If you waiting for user mode within READ path, it might be the
>> same scenario.
>>
>> I would also like to know other’s opinions,
>> with considering above described situation.
>>
>> If you would be willing, you may expose the deadlock crash
>> dump, I would like to download it and look at it.
>>
>> L.
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

OSR_Community_User · June 2, 2005, 8:51am

Kedar,

In the thread dump, are you seeing any threads which are suspiciously
blocking on a resource?

Have you tried the !locks command?

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of kedar
Sent: Thursday, June 02, 2005 6:28 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Problems when IRP is pend from Filter driver with Anti
Virus real time protection

Hi Pete,

I am using !threads and !stack command from Windbg but not able to go ahead
with the information that it gives.

Could you please give me any pointers on how to find out the deadlock?

Thanks,
Kedar,
“Peter Scott” wrote in message
news:xxxxx@ntfsd…
>
> Kedar,
>
> It is quite easy to determine the deadlock if you have a debugger
> attached.
> I would suggest you do this to determine exactly what is causing the lock
> in
> the system.
>
> Pete
>
> Kernel Drivers
> Windows Filesystem and Device Driver Consulting
> www.KernelDrivers.com
> (303)546-0300
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of kedar
> Sent: Monday, May 23, 2005 8:44 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Problems when IRP is pend from Filter driver with Anti
> Virus real time protection
>
> Hi,
>
> I am not seeing any crash here.
>
> Thanks,
> Kedar.
> “Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
>> Well, I’m currently solving the similar problem.
>> Our filter acquires a file lock, then calls lower driver
>> for IRP_MJ_SET_INFORMATION. The lower driver
>> seems to communicate with the user mode for some reason.
>> Because the file is still locked, the deadlock comes.
>>
>> This may be the same problem as you have - the upper
>> antivirus filter has acquired some lock and you then
>> wait for some user mode service. If the service touches
>> anything that has to do with the locked file (it may be a registry
>> hive), the deadlock occurs.
>>
>> IMHO is not safe to call usermode in the IRP
>> dispatch handlers except IRP_MJ_CREATE handler.
>> If you waiting for user mode within READ path, it might be the
>> same scenario.
>>
>> I would also like to know other’s opinions,
>> with considering above described situation.
>>
>> If you would be willing, you may expose the deadlock crash
>> dump, I would like to download it and look at it.
>>
>> L.
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.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@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · June 2, 2005, 9:16am

> Have you tried the !locks command?

If not, do it, and especially look for threads and resources that are
cross-held and waited for. I mean look for the case when
ThreadA holds resourceA and waits for ResourceB,
ThreadB holds resourceB and waits for ResourceA.

L.

OSR_Community_User · June 2, 2005, 9:57am

Hi,

The following the is the output of !locks when I used.

kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks…

Resource @ savrt (0xb7b03040) Shared 1 owning threads
Threads: 813e98a0-01<*>
KD: Scanning for held locks…

Resource @ 0x8209a340 Shared 1 owning threads
Threads: 8209e8a3-01<*> *** Actual Thread 8209E8A0
KD: Scanning for held locks…

Thanks,
Kedar.

“kedar” wrote in message news:xxxxx@ntfsd…
> Hi,
>
> I have a filter driver on Windows 2000, which pends some IRPs from some
> application and then communicates with user mode application about the
> request and the user mode application tries to open the file and the
> filter driver does not block requests from this application.
>
> In the above case with anti virus real time protection the user mode
> application is not able to open file.
>
> Could any one tell what could be the problem.
>
> I think that anti virus is trying to open the file.
>
> Any information is helpful.
>
> Thanks,
> Kedar.
>
>

OSR_Community_User · June 2, 2005, 11:28am

It does not seem, at first look, that there is a tracked resource deadlock.
Remember that the !locks command will only dump information on system
tracked lock structures such as ERESOURCES.

When you dump the threads from Windbg, do you notice any that are blocked in
your filter driver? One way to see this is perform a !process 0 7, which
will dump everything, then search for your driver name the reported
information.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of kedar
Sent: Thursday, June 02, 2005 7:55 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Problems when IRP is pend from Filter driver with Anti
Virus real time protection

Hi,

The following the is the output of !locks when I used.

kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks…

Resource @ savrt (0xb7b03040) Shared 1 owning threads
Threads: 813e98a0-01<*>
KD: Scanning for held locks…

Resource @ 0x8209a340 Shared 1 owning threads
Threads: 8209e8a3-01<*> *** Actual Thread 8209E8A0
KD: Scanning for held locks…

Thanks,
Kedar.

“kedar” wrote in message news:xxxxx@ntfsd…
> Hi,
>
> I have a filter driver on Windows 2000, which pends some IRPs from some
> application and then communicates with user mode application about the
> request and the user mode application tries to open the file and the
> filter driver does not block requests from this application.
>
> In the above case with anti virus real time protection the user mode
> application is not able to open file.
>
> Could any one tell what could be the problem.
>
> I think that anti virus is trying to open the file.
>
> Any information is helpful.
>
> Thanks,
> Kedar.
>
>

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

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

Kiran_Joshi · June 3, 2005, 2:21am

Do !process 0 7. This will dump all the process and threads along with the
thread call stack… Search for suspicious threads that are waiting on
various resources… See who is holding those locks and why.
-Kiran

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of kedar
Sent: Thursday, June 02, 2005 7:25 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Problems when IRP is pend from Filter driver with Anti
Virus real time protection

Hi,

The following the is the output of !locks when I used.

kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks…

Resource @ savrt (0xb7b03040) Shared 1 owning threads
Threads: 813e98a0-01<*>
KD: Scanning for held locks…

Resource @ 0x8209a340 Shared 1 owning threads
Threads: 8209e8a3-01<*> *** Actual Thread 8209E8A0
KD: Scanning for held locks…

Thanks,
Kedar.

“kedar” wrote in message news:xxxxx@ntfsd…
> Hi,
>
> I have a filter driver on Windows 2000, which pends some IRPs from
> some application and then communicates with user mode application
> about the request and the user mode application tries to open the file
> and the filter driver does not block requests from this application.
>
> In the above case with anti virus real time protection the user mode
> application is not able to open file.
>
> Could any one tell what could be the problem.
>
> I think that anti virus is trying to open the file.
>
> Any information is helpful.
>
> Thanks,
> Kedar.
>
>

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

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

OSR_Community_User · June 3, 2005, 7:14am

Hi,

The following the is the output of !locks !irpfind and !thread commands in
windbg when I pend the IRP with symantec anti virus real time protection on.

And I see the IRP that we pened in the IRP list of the lock and in the stack
I see both symatec driver and our filter driver.

Could any one give me more understanding of this windbg results.

kd> !locks

**** DUMP OF ALL RESOURCE OBJECTS ****

KD: Scanning for held
locks…

Resource @ savrt (0xf0094040) Shared 1 owning threads

Threads: 82026300-01<*>

KD: Scanning for held locks…

Resource @ 0x81fe6aa8 Shared 1 owning threads

Threads: 822cb663-01<*> *** Actual Thread 822cb660

Resource @ 0x81f93040 Shared 1 owning threads

Threads: 822cb663-01<*> *** Actual Thread 822cb660

KD: Scanning for held locks.

Resource @ 0x82000730 Shared 1 owning threads

Threads: 822ca023-01<*> *** Actual Thread 822ca020

3002 total locks, 4 locks currently held

kd> !locks -v f0094040

Resource @ savrt (0xf0094040) Shared 1 owning threads

Threads: 82026300-01<*>

THREAD 82026300 Cid 08c4.08f0 Teb: 7ffd6000 Win32Thread: 00000000
WAIT: (Executive) KernelMode Non-Alertable

82002fec NotificationEvent

IRP List:

82880e28: (0006,01d8) Flags: 40000900 Mdl: 81f87240

82ac6e28: (0006,01d8) Flags: 40000884 Mdl: 00000000

Not impersonating

DeviceMap e2fb1df0

Owning Process 81b7c630 Image: wmplayer.exe

Wait Start TickCount 8513 Ticks: 3785 (0:00:00:59.140)

Context Switch Count 4

UserTime 00:00:00.0000

KernelTime 00:00:00.0000

Start Address 0x7c810856

Win32 Start Address 0x77c3a341

Stack Init eed86000 Current eed854ec Base eed86000 Limit eed83000 Call
0

Priority 11 BasePriority 8 PriorityDecrement 2 DecrementCount 16

ChildEBP RetAddr

eed85504 804dc6a6 nt!KiSwapContext+0x2e (FPO: [EBP 0xeed85538] [0,0,4])

eed85510 804dc6f2 nt!KiSwapThread+0x46 (FPO: [0,0,0])

eed85538 8057e0b3 nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])

eed85560 80571dc2 nt!IopSynchronousServiceTail+0xc6 (FPO: [Non-Fpo])

eed85608 804df06b nt!NtReadFile+0x580 (FPO: [Non-Fpo])

eed85608 804ddcb2 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @
eed85634)

eed856a4 f00cbc43 nt!ZwReadFile+0x11 (FPO: [9,0,0])

WARNING: Stack unwind information not available. Following frames may be
wrong.

eed856ec f009a0f6 savrt+0x3dc43

eed85740 f009a55e savrt+0xc0f6

e1772e40 e1879268 savrt+0xc55e

f007b86c f0080d00 0xe1879268

f0082150 ffffeb28 SYMEVENT!SYMEvent_GetVMDataPtr+0x4560

e8f18b56 00000000 0xffffeb28

1 total locks, 1 locks currently held

kd> !irp 82ac628

082ac628: Could not read Irp

kd> !irp 82ac6e28

Irp is active with 10 stacks 9 is current (= 0x82ac6fb8)

No Mdl Thread 82026300: Irp stack trace.

cmd flg cl Device File Completion-Context

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 10 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 e0 81f741f8 82040cd8 f84e6190-81ad4410 Success Error Cancel

\Driver\SymEvent fsfd!CompletionRoutine

Args: eed85a88 01000064 00070080 00000000

[0, 0] 0 0 8210f478 82040cd8 00000000-00000000

\FileSystem\fsfd

Args: eed85a88 01000064 00070080 00000000

kd> !thread 82026300

THREAD 82026300 Cid 08c4.08f0 Teb: 7ffd6000 Win32Thread: 00000000 WAIT:
(Executive) KernelMode Non-Alertable

82002fec NotificationEvent

IRP List:

82880e28: (0006,01d8) Flags: 40000900 Mdl: 81f87240

82ac6e28: (0006,01d8) Flags: 40000884 Mdl: 00000000

Not impersonating

DeviceMap e2fb1df0

Owning Process 81b7c630 Image: wmplayer.exe

Wait Start TickCount 8513 Ticks: 3785 (0:00:00:59.140)

Context Switch Count 4

UserTime 00:00:00.0000

KernelTime 00:00:00.0000

Start Address 0x7c810856

Win32 Start Address 0x77c3a341

Stack Init eed86000 Current eed854ec Base eed86000 Limit eed83000 Call 0

Priority 11 BasePriority 8 PriorityDecrement 2 DecrementCount 16

ChildEBP RetAddr Args to Child

eed85504 804dc6a6 82026370 82026300 804dc6f2 nt!KiSwapContext+0x2e (FPO:
[EBP 0xeed85538] [0,0,4])

eed85510 804dc6f2 00000103 00000000 82880e28 nt!KiSwapThread+0x46 (FPO:
[0,0,0])

eed85538 8057e0b3 00000000 00000000 00000200 nt!KeWaitForSingleObject+0x1c2
(FPO: [Non-Fpo])

eed85560 80571dc2 8210f478 00000103 82002f90
nt!IopSynchronousServiceTail+0xc6 (FPO: [Non-Fpo])

eed85608 804df06b 00000298 00000000 00000000 nt!NtReadFile+0x580 (FPO:
[Non-Fpo])

eed85608 804ddcb2 00000298 00000000 00000000 nt!KiFastCallEntry+0xf8 (FPO:
[0,0] TrapFrame @ eed85634)

eed856a4 f00cbc43 00000298 00000000 00000000 nt!ZwReadFile+0x11 (FPO:
[9,0,0])

WARNING: Stack unwind information not available. Following frames may be
wrong.

eed856ec f009a0f6 81b90f80 f009a070 eed8575c savrt+0x3dc43

eed85740 f009a55e 81b90f80 00003f80 f009a070 savrt+0xc0f6

e1772e40 e1879268 f007b420 e1b69160 f007b424 savrt+0xc55e

f007b86c f0080d00 f0080da0 f007c7a0 f0080df0 0xe1879268

f0082150 ffffeb28 082444f6 56097401 00296be8
SYMEVENT!SYMEvent_GetVMDataPtr+0x4560

e8f18b56 00000000 00000000 00000000 00000000 0xffffeb28

Thanks,

Kedar.

OSR_Community_User · June 3, 2005, 9:38am

Kedar,

This is still not saying much without further analysis. As I and others
recommended, perform a !process 0 7 command and search all threads which
could be blocking. The thread below is definitely waiting for a read to
complete but it doesn’t show who is keeping the read from completing.

BTW - Don’t post all the information from the above command to the list. If
you want, only post the threads which ‘seem’ to be suspicious.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of kedar
Sent: Friday, June 03, 2005 5:12 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Problems when IRP is pend from Filter driver with Anti
Virus real time protection

Hi,

The following the is the output of !locks !irpfind and !thread commands in
windbg when I pend the IRP with symantec anti virus real time protection on.

And I see the IRP that we pened in the IRP list of the lock and in the stack

I see both symatec driver and our filter driver.