Hello,
I have found an issue of (probably) ZoneAlarm, version 7.0.483.
When someone opens the file \System Volume Information\tracking.log,
the thread who called NtCreateFile hangs. It is not a system-wide
deadlock, and the application can be killed in process manager.
If someone from ZoneLabs can contact me, I can give more
information. It is also possible that it’s a problem in NTFS itself,
as the operation performed by klif.sys (query name twice and then
pass through) might be quite common in minifilters.
-
Operating system was WinXP SP3, installed in VMWARE
-
Happens on clean new volume, as well as on system volume
-
It’s very well reproducible, but only happens on the file
“\System Volume Information\tracking.log”
-
It doesn’t happen when I disable the driver “klif.sys”
This minifilter is installed with multiple security products,
like ZoneAlarm or Kaspersky AV.
-
Initiated by user-mode call of NtCreateFile
(tested with FileTest.exe running under LocalSystem account):
-
DesiredAcces = GENERIC_READ | SYNCHRONIZE
-
FileName = “??\E:\System Volume Information\tracking.log”
-
FILE_ATTRIBUTE_NORMAL
-
FILE_SHARE_READ
-
FILE_OPEN
-
FILE_SYNCHRONOUS_IO_NONALERT
-
This call causes ntfs!NtfsFsdCreate to be called three times,
first and second as result of klif.sys calling FltGetFileNameInformation,
third as the actual file open.
Call sequence is this:
- NtfsFsdCreate
± NtfsCommonCreate
±- NtfsOpenExistingPrefixFcb
±-- NtfsOpenAttributeInExistingFile
±— NtfsOpenExistingAttr
±---- NtfsBreakBatchOplock
±----- FsRtlCheckOplock
The deepest function called, FsRtlCheckOplock, returns 1. As a result,
NtfsBreakBatchOplock returns STATUS_PENDING, which is propagated up to
NtfsFsdCreate. After return, the thread hangs in this call from
NtfsFsdCreate:
Status = KeWaitForSingleObject(&CompletionContext.Event,
Executive,
Irp->RequestorMode,
TRUE,
NULL);
The event is never set, and the thread is hung until the process
is killed.
L.
This is likely a case of poor hooking practices. Somebody a few weeks ago
reported he could not even attach to remote filesystems if this thing was
running because according to him klif.sys always was “first”. Read Skywings
article for an in depth review of all klif’s hacks to see if this may give
you a clue:
http://www.uninformed.org/?v=4&a=4
Download
http:///www.resplendence.com/hookanalyzer
to see what SSDT hooks this software has installed. ZoneAlarm used to hook
NtCreateFile among others but not sure if that is still the case.
In Windbg use !drvobj \filesystem\xxx to see what driver or dispatch entry
points this thing has overwritten that point in the address range of this
driver. I am on my way developing a software which gives a good summary of
most hacks a driver could make use of (including SSDT, dispatch entry
points, driver entry points, import table hacks, object type initializers,
prologue patching and more), unfortunately it’s not ready yet.
//Daniel
“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
Hello,
I have found an issue of (probably) ZoneAlarm, version 7.0.483.
When someone opens the file \System Volume Information\tracking.log,
the thread who called NtCreateFile hangs. It is not a system-wide
deadlock, and the application can be killed in process manager.
If someone from ZoneLabs can contact me, I can give more
information. It is also possible that it’s a problem in NTFS itself,
as the operation performed by klif.sys (query name twice and then
pass through) might be quite common in minifilters.
- Operating system was WinXP SP3, installed in VMWARE
- Happens on clean new volume, as well as on system volume
- It’s very well reproducible, but only happens on the file
“\System Volume Information\tracking.log”
- It doesn’t happen when I disable the driver “klif.sys”
This minifilter is installed with multiple security products,
like ZoneAlarm or Kaspersky AV.
- Initiated by user-mode call of NtCreateFile
(tested with FileTest.exe running under LocalSystem account):
- DesiredAcces = GENERIC_READ | SYNCHRONIZE
- FileName = “??\E:\System Volume Information\tracking.log”
- FILE_ATTRIBUTE_NORMAL
- FILE_SHARE_READ
- FILE_OPEN
- FILE_SYNCHRONOUS_IO_NONALERT
- This call causes ntfs!NtfsFsdCreate to be called three times,
first and second as result of klif.sys calling FltGetFileNameInformation,
third as the actual file open.
Call sequence is this:
+ NtfsFsdCreate
± NtfsCommonCreate
±- NtfsOpenExistingPrefixFcb
±-- NtfsOpenAttributeInExistingFile
±— NtfsOpenExistingAttr
±---- NtfsBreakBatchOplock
±----- FsRtlCheckOplock
The deepest function called, FsRtlCheckOplock, returns 1. As a result,
NtfsBreakBatchOplock returns STATUS_PENDING, which is propagated up to
NtfsFsdCreate. After return, the thread hangs in this call from
NtfsFsdCreate:
Status = KeWaitForSingleObject(&CompletionContext.Event,
Executive,
Irp->RequestorMode,
TRUE,
NULL);
The event is never set, and the thread is hung until the process
is killed.
L.
It’s been a while, but still I don’t know what is a ‘not poor hooking’ at
that level …
Some of us wanted to re-achitect… And that is why I went to NCC held in
2002/3…
What could I have done when ‘someone gets a boss with background in Web
development and wants to have status report twice a day’? – Just run
away, and stay clear …
I would surely be interested in your product, just for the kick of it …
Let us know when you are ready …
-pro
This is likely a case of poor hooking practices. Somebody a few weeks ago
reported he could not even attach to remote filesystems if this thing was
running because according to him klif.sys always was “first”. Read
Skywings
article for an in depth review of all klif’s hacks to see if this may give
you a clue:
http://www.uninformed.org/?v=4&a=4
Download
http:///www.resplendence.com/hookanalyzer
to see what SSDT hooks this software has installed. ZoneAlarm used to hook
NtCreateFile among others but not sure if that is still the case.
In Windbg use !drvobj \filesystem\xxx to see what driver or dispatch entry
points this thing has overwritten that point in the address range of this
driver. I am on my way developing a software which gives a good summary of
most hacks a driver could make use of (including SSDT, dispatch entry
points, driver entry points, import table hacks, object type initializers,
prologue patching and more), unfortunately it’s not ready yet.
//Daniel
“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> Hello,
>
> I have found an issue of (probably) ZoneAlarm, version 7.0.483.
> When someone opens the file \System Volume Information\tracking.log,
> the thread who called NtCreateFile hangs. It is not a system-wide
> deadlock, and the application can be killed in process manager.
>
> If someone from ZoneLabs can contact me, I can give more
> information. It is also possible that it’s a problem in NTFS itself,
> as the operation performed by klif.sys (query name twice and then
> pass through) might be quite common in minifilters.
>
> - Operating system was WinXP SP3, installed in VMWARE
>
> - Happens on clean new volume, as well as on system volume
>
> - It’s very well reproducible, but only happens on the file
> “\System Volume Information\tracking.log”
>
> - It doesn’t happen when I disable the driver “klif.sys”
> This minifilter is installed with multiple security products,
> like ZoneAlarm or Kaspersky AV.
>
> - Initiated by user-mode call of NtCreateFile
> (tested with FileTest.exe running under LocalSystem account):
>
> - DesiredAcces = GENERIC_READ | SYNCHRONIZE
> - FileName = “??\E:\System Volume Information\tracking.log”
> - FILE_ATTRIBUTE_NORMAL
> - FILE_SHARE_READ
> - FILE_OPEN
> - FILE_SYNCHRONOUS_IO_NONALERT
>
> - This call causes ntfs!NtfsFsdCreate to be called three times,
> first and second as result of klif.sys calling
> FltGetFileNameInformation,
> third as the actual file open.
>
> Call sequence is this:
>
> + NtfsFsdCreate
> ± NtfsCommonCreate
> ±- NtfsOpenExistingPrefixFcb
> ±-- NtfsOpenAttributeInExistingFile
> ±— NtfsOpenExistingAttr
> ±---- NtfsBreakBatchOplock
> ±----- FsRtlCheckOplock
>
> The deepest function called, FsRtlCheckOplock, returns 1. As a result,
> NtfsBreakBatchOplock returns STATUS_PENDING, which is propagated up to
> NtfsFsdCreate. After return, the thread hangs in this call from
> NtfsFsdCreate:
>
> Status = KeWaitForSingleObject(&CompletionContext.Event,
> Executive,
> Irp->RequestorMode,
> TRUE,
> NULL);
>
> The event is never set, and the thread is hung until the process
> is killed.
>
> L.
>
>
>
>
>
> —
> 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@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>