Hi,
If someone from McAfee is on this list, I would appreciate if he could
throw some light on this issue. Others are also welcome to take a shot
at this 
In my filter, I do some processing on a file (whenever a file is
opened for writing). I use the shadow device technique, so that I
don’t cause recursion when opening the file with Zw* calls. Everything
works fine, but McAfee starts to behave weirdly once in a while.
Whenever I try to update McAfee (by selecting the update button on its
UI) its service just hangs. Windbg shows that the McAfee driver is
doing a KeWaitForSingleObject in its IRP_MJ_CLOSE dispatch. The hung
thread is in McShield.exe.
Seems to me that something confuses McAfee when it sees a CLOSE on a
fileobject on which it didn’t see a CREATE. This happens because I use
the Shadow device technique and do a ZwClose on the handle I get. This
causes the CLOSE to be sent to the top of the stack.
Has anyone experienced this problem? I am attaching the backtrace:
kd> !thread 81644b30
THREAD 81644b30 Cid 01b4.03a0 Teb: 7ffd6000 Win32Thread: 00000000
WAIT: (UserRequest) KernelMode Non-Alertable
814eae40 SynchronizationEvent
IRP List:
815732f8: (0006,01fc) Flags: 00000404 Mdl: 00000000
814d9c40: (0006,01fc) Flags: 00000884 Mdl: 00000000
8168db58: (0006,0094) Flags: 00000900 Mdl: 81619008
Not impersonating
DeviceMap e10011a8
Owning Process 81bcca00 Image: System
Wait Start TickCount 35101 Ticks: 6015 (0:00:01:00.236)
Context Switch Count 3236
UserTime 00:00:01.0662
KernelTime 00:00:05.0648
Start Address 0x7c810856
Win32 Start Address 0x00416850
Stack Init f5ef5000 Current f5ef42cc Base f5ef5000 Limit f5ef2000 Call 0
Priority 14 BasePriority 13 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr Args to Child
f5ef42e4 804dc6a6 81644ba0 81644b30 804dc6f2 nt!KiSwapContext+0x2e
(FPO: [Uses EBP] [0,0,4])
f5ef42f0 804dc6f2 00000000 814cf5f0 00000000 nt!KiSwapThread+0x46 (FPO: [0,0,0])
f5ef4318 f9e0707e 00000000 00000006 00000000
nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be wrong.
f5ef43ac f9e07950 f5ef43d4 00000004 e11d9308 NaiFiltr+0x307e
f5ef43ec f9e08217 8151f380 814eae40 804e3d77 NaiFiltr+0x3950
f5ef443c 80567391 81bcca00 8151f380 00120089 NaiFiltr+0x4217
f5ef446c 8056753b 81bcca00 814be340 81bb6730
nt!ObpDecrementHandleCount+0x119 (FPO: [Non-Fpo])
f5ef4494 805675ac e1000d10 814be340 000000c4
nt!ObpCloseHandleTableEntry+0x14d (FPO: [Non-Fpo])
f5ef44dc 805675f6 000000c4 00000000 00000000 nt!ObpCloseHandle+0x87
(FPO: [Non-Fpo])
f5ef44f0 f98cf607 800000c4 00000034 00000000 nt!NtClose+0x1d (FPO: [Non-Fpo])
f5ef4514 804df06b 800000c4 f5ef45d4 804dcea6 foo!foo1
f5ef4514 804dcea6 800000c4 f5ef45d4 804dcea6 nt!KiFastCallEntry+0xf8
(FPO: [0,0] TrapFrame @ f5ef4520)
f5ef4590 f98dd500 800000c4 814d9c50 00000000 nt!ZwClose+0x11 (FPO: [1,0,0])
f5ef45d4 f98dccf8 8162e9f8 814d9c50 00000000 foo!foo2
f5ef460c f98dcbcd 8162e9f8 814d9c50 00000000 foo!foo3
f5ef4650 f98dc74e 800000c4 814be340 8173a020 foo!foo4
f5ef4694 f98a6617 800000c4 814be340 8173a020 foo!foo5
f5ef46f0 f98c23dd e1d7e1b8 814d9c50 00000000 foo!foo6
5ef4788 f98c1e01 815e49fc 816c7420 81b9fb08 foo!foo7
f5ef47f8 f98c08ff 815e49fc 816c7420 f5ef4828 foo!foo8
f5ef483c f989cee1 815e49fc 816c7420 815e4c08 foo!foo9
f5ef4880 f98a0a3c 8176f008 815e49fc 816c7420 foo!foo10
f5ef48dc f98a0292 815e49c0 f5ef4920 f5ef4916 foo!foo11
f5ef494c f98a002f 815e49c0 00000000 814d9c50 foo!foo12
f5ef49a0 f989fd7d 8173a020 814d9c40 00000000 foo!foo13
f5ef49b8 f9897d00 8173a020 814d9c40 f5ef4a04 foo!foo14
f5ef49c8 f994b78a 8173a020 814d9c40 814d9c50 foo!foo15
f5ef4a04 804e3d77 8173a020 814d9c40 814d9e18 foo!foo16
f5ef4a14 f9e07c88 814d9c50 815d75e0 81670db8 nt!IopfCallDriver+0x31
(FPO: [0,0,0])
f5ef4a40 f9e08217 8151f380 814d9c40 804e3d77 NaiFiltr+0x3c88
f5ef4b3c 8056386c 81b7a030 00000000 816c8310 NaiFiltr+0x4217
f5ef4bc4 80567c63 00000000 f5ef4c04 00000040
nt!ObpLookupObjectName+0x56a (FPO: [Non-Fpo])
f5ef4c18 80571477 00000000 00000000 00000001
nt!ObOpenObjectByName+0xeb (FPO: [Non-Fpo])
f5ef4c94 80571546 00158c10 00120180 01adfed4 nt!IopCreateFile+0x407
(FPO: [Non-Fpo])
f5ef4cf0 8057167c 00158c10 00120180 01adfed4 nt!IoCreateFile+0x8e
(FPO: [Non-Fpo])
f5ef4d30 804df06b 00158c10 00120180 01adfed4 nt!NtCreateFile+0x30
(FPO: [Non-Fpo])
f5ef4d30 7c90eb94 00158c10 00120180 01adfed4 nt!KiFastCallEntry+0xf8
(FPO: [0,0] TrapFrame @ f5ef4d64)
00000000 00000000 00000000 00000000 00000000 0x7c90eb94
Another interesting thing happens. If you look carefully at the wingbg
output, the Image corresponding to this thread says ‘System’. However
when it had started, the Image corresponding to this thread was
‘McShield.exe’. What could cause this to happen?
I have tested it with another version of McAfee and other AV’s and
haven’t had any problems.
Thanks