Delayed file handle close in Win 7 x64

NTFSD
1

Hello Experts,
I need help with an issue that’s bugging me for some time now.
In a specific case of an application load and exit, there is an open file handle created in the context of NtCreateUserProcess that stays open for minutes after application exit. This is undesirable in our system due to security reasons. This problem does not reproduce on Vista 32-bit. This problem also does not reproduce on Win 7 x64 if the application doesn’t exit immediately on launch. Any hints on what’s causing the file handle to stay open in this case? Any hints on speeding the file handle close?
Thanks in advance,
Vinod Mamtani

Environment:
Windows 7 x64

Stack trace for open handle:
1: kd> kv
Child-SP RetAddr : Args to Child : Call Site
fffff880066826e0 fffff88001040288 : fffffa800489d9f0 fffff880066827e8 fffff8a003c8b280 0000000000000000 : minime!MiniMeFilePostCreateCallback+0x203 [c:\src\snippets\minime\filetrack.c @ 427]
fffff880066827a0 fffff8800103ed1b : fffffa80023ce960 fffffa800489db10 fffffa800233fd40 fffffa800233ff60 : fltmgr!FltpPerformPostCallbacks+0x368
fffff88006682870 fffff8800105e2b9 : fffffa8005164260 fffffa800287f280 fffffa8005164200 fffffa800287fae0 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x39b
fffff88006682900 fffff80002397495 : 0000000000000000 fffffa8002303cc8 0000000000000000 fffff8a0002041e0 : fltmgr!FltpCreate+0x2a9
fffff880066829b0 fffff80002393d38 : fffffa80027339d0 fffff80000000000 fffffa8002303b10 0000000000000001 : nt!IopParseDevice+0x5a5
fffff88006682b40 fffff80002394f56 : 0000000000000000 fffffa8002303b10 fffffa8002882180 fffffa800184f8a0 : nt!ObpLookupObjectName+0x588
fffff88006682c30 fffff8000239685c : fffff8a0039263a8 0000000000000000 fffff88006683100 0000000000000080 : nt!ObOpenObjectByName+0x306
fffff88006682d00 fffff80002382134 : fffff88006683740 00000000001000a1 fffff88006683128 fffff88006683158 : nt!IopCreateFile+0x2bc
fffff88006682da0 fffff800020988d3 : fffff8a0039263a8 fffff880012e77d6 000000000000004c fffff88006683300 : nt!NtOpenFile+0x58
fffff88006682e30 fffff80002094e70 : fffff8000234478c 0000000000000000 fffff88006683a01 fffff88000000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff88006682ea0) fffff88006683038 fffff8000234478c : 0000000000000000 fffff88006683a01 fffff88000000000 fffff88000000000 : nt!KiServiceLinkage fffff88006683040 fffff800020988d3 : 0000000000000000 0000007fffffffff 0000000000000000 0000098000000000 : nt!NtCreateUserProcess+0x2eb fffff88006683b70 0000000077c21dea : 000000007455b9eb 00000000002e37e0 000000000028e8c0 000000000008ead0 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff88006683be0)
000000000008dd38 000000007455b9eb : 00000000002e37e0 000000000028e8c0 000000000008ead0 000000000008ead0 : ntdll!NtCreateUserProcess+0xa
000000000008dd40 00000000745713e7 : 000000000008e268 000000000028e8c0 000000000028ef30 000000000008ead0 : wow64!Wow64NtCreateUserProcess+0x15f
000000000008e130 000000007455cf87 : 000000000008e2f8 000000007efdb000 000000007efdd000 0000000074570bf8 : wow64!whNtCreateUserProcess+0x7ef
000000000008e350 00000000744e2776 : 00000000004fdd2d 0000000074550023 0000000000200246 000000000028e82c : wow64!Wow64SystemServiceEx+0xd7
000000000008ec10 000000007455d07e : 0000000000000000 00000000744e1920 000000000008eea0 0000000077bfecd1 : wow64cpu!TurboDispatchJumpAddressEnd+0x2d
000000000008ecd0 000000007455c549 : 0000000000000000 0000000000000000 0000000074554ac8 000000007ffe0030 : wow64!RunCpuSimulation+0xa
000000000008ed20 0000000077c14956 : 00000000002e3330 0000000000000000 0000000077d02670 0000000077cd5978 : wow64!Wow64LdrpInitialize+0x429
000000000008f270 0000000077c11a17 : 0000000000000000 0000000077c14061 000000000008f820 0000000000000000 : ntdll!LdrpInitializeProcess+0x17e4
000000000008f760 0000000077bfc32e : 000000000008f820 0000000000000000 000000007efdf000 0000000000000000 : ntdll! ?? ::FNODOBFM::string'+0x29220 000000000008f7d0 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`00000000 : ntdll!LdrInitializeThunk+0xe

Open handle:
0: kd> !handle 0 4

PROCESS fffffa8001823840
SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000
DirBase: 00187000 ObjectTable: fffff8a000001980 HandleCount: 512.
Image: System

Kernel handle table at fffff8a002124000 with 512 entries in use

…

0874: Object: fffffa80022435a0 GrantedAccess: 00000080 Entry: fffff8a002bfd1d0
Object: fffffa80022435a0 Type: (fffffa800184f8a0) File
ObjectHeader: fffffa8002243570 (new version)
HandleCount: 1 PointerCount: 15
Directory Object: 00000000 Name: \Program Files\App1\abcdef.exe {HarddiskVolume1}

…

Close handle:
0: kd> kv
Child-SP RetAddr : Args to Child : Call Site
fffff880061b08e0 fffff80002390471 : fffffa8001823840 fffffa8000000000 fffff8a000001980 0000000000000000 : nt!ObpDecrementHandleCount+0xf3
fffff880061b0960 fffff80002390a34 : 0000000000000874 fffffa8001823840 fffff8a000001980 0000000000000874 : nt!ObpCloseHandleTableEntry+0xb1
fffff880061b09f0 fffff800020988d3 : fffffa8002238b60 fffff880061b0ac0 fffff800022356f0 0000000000000000 : nt!ObpCloseHandle+0x94
fffff880061b0a40 fffff80002094e70 : fffff8000237e67e 0000000000000001 fffff800022356f0 fffff800022356f0 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880061b0a40) fffff880061b0bd8 fffff8000237e67e : 0000000000000001 fffff800022356f0 fffff800022356f0 fffff800022356d0 : nt!KiServiceLinkage fffff880061b0be0 fffff80002080ee6 : fffffa8004cc7110 0000000000000000 fffff80061626453 fffff880061b0ca8 : nt!AelReleaseCacheExeMessageAttributes+0x3a fffff880061b0c10 fffff8000201bb90 : 0000000000000000 0000000000000001 0000000000000000 fffffa8002238b60 : nt!ApphelpServiceFreeWorkItem+0x36 fffff880061b0c40 fffff800020a3a21 : fffff800020341f8 fffff80002236658 fffffa8002238b60 fffff80002236658 : nt! ?? ::FNODOBFM::string’+0x53013
fffff880061b0c70 fffff80002336cce : 0000000000000000 fffffa8002238b60 0000000000000080 fffffa8001823840 : nt!ExpWorkerThread+0x111
fffff880061b0d00 fffff8000208afe6 : fffff8000220be80 fffffa8002238b60 fffffa80021e0040 0000000000000000 : nt!PspSystemThreadStartup+0x5a
fffff880061b0d40 0000000000000000 : fffff880061b1000 fffff880061ab000 fffff880061b09a0 0000000000000000 : nt!KxStartSystemThread+0x16

2

>> In a specific case of an application load and exit, there is an open file handle created in the context of

NtCreateUserProcess that stays open for minutes after application exit. This is undesirable in our system due to
security reasons.

This is how Windows works, the file is held by Cc due to cache maps for it still existing and not discarded by the Cc’s garbage collector.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

3

Thanks Maxim for your quick response!

An interesting thing is that this problem does not reproduce on Vista. This problem also does not reproduce with other apps under similar scenario on Win 7 x64. It seems that there is something unique about this app that’s triggering such behavior in the NT cache manager.

I understand that a Windows component may implement garbage collection and have references to an object as appropriate but it doesn’t seem right for this behavior to be visible to an application. For instance, if our security application attempts an exclusive handle on this file, it will fail due to an outstanding handle by the garbage collector. This behavior will pose a number of compatibility issues.

Thoughts?
Vinod Mamtani

4

I believe that the AEL stuff has to do with application compatibility, so
you could try looking at that to see if that explains the difference (i.e.
is the app running in compatibility mode?).

For instance, if our security application attempts an exclusive handle on
this file, it will fail due to an outstanding handle by the >garbage
collector.

So I can bypass your security application by just leaving a handle open to
my malicious file?

-scott

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

wrote in message news:xxxxx@ntfsd…

Thanks Maxim for your quick response!

An interesting thing is that this problem does not reproduce on Vista. This
problem also does not reproduce with other apps under similar scenario on
Win 7 x64. It seems that there is something unique about this app that’s
triggering such behavior in the NT cache manager.

I understand that a Windows component may implement garbage collection and
have references to an object as appropriate but it doesn’t seem right for
this behavior to be visible to an application. For instance, if our security
application attempts an exclusive handle on this file, it will fail due to
an outstanding handle by the garbage collector. This behavior will pose a
number of compatibility issues.

Thoughts?
Vinod Mamtani

5

Thanks Scott. I’ll look into the application compatibility with AEL…

On the security side, we provide security in layers and I’ll be the first to admit that it’s not perfect.
We control the visibility and location of files as well as process execution on our systems. So in this case, an outstanding open handle triggers our detection mechanism that is more like an annoyance.

Thanks again for your help. You guys truly are a savior for people who pose their issues on these forums.

6

Cool! The compatibility thing worked!