Can't delete webapp after creating app_offline.htm

[Sam777]

I was under the impression that creating the app_offline.htm file at the
root of the webapp would cause all handles to be closed so that the app could
be removed. Unfortunately, this isn't the case. One handle remains open.

Debugging shows that it's actually the IIS cache and not ASP.NET that owns
this handle. During IIS shutdown, the handle is closed with the following
stack trace:
ChildEBP RetAddr
0006fbe4 5a403e05 kernel32!CloseHandle
0006fc04 5a4033ca W3CACHE!CDirMonitorEntry::Cleanup+0x52
0006fc14 5a4026b6 W3CACHE!CDirMonitorEntry::Release+0x2e
0006fc1c 5a3aba23 W3CACHE!CACHE_ENTRY::~CACHE_ENTRY+0x17
0006fc28 5a401b9c w3core!UL_RESPONSE_CACHE_ENTRY::`vector deleting
destructor'+0xd
0006fc3c 5a40212e W3CACHE!CACHE_ENTRY::DereferenceCacheEntry+0x2c
0006fc48 647187cd W3CACHE!CACHE_ENTRY_HASH::AddRefRecord+0x40
0006fc74 647188c2 IISUTIL!CLKRLinearHashTable::_Clear+0x6f
0006fc84 5a40346b IISUTIL!CLKRHashTable::Clear+0x1f
0006fc90 5a3af52c W3CACHE!CACHE_MANAGER::FlushAllCaches+0x18
0006fca0 5a3b0167 w3core!W3_SERVER::TerminateCaches+0xc
0006fcb4 5a3bc26b w3core!W3_SERVER::Terminate+0xff
0006ff0c 0100187c w3core!UlW3Start+0x280
0006ff44 01001a23 w3wp!wmain+0x22a
0006ffc0 77e523cd w3wp!wmainCRTStartup+0x12b
0006fff0 00000000 kernel32!BaseProcessStart+0x23

Preventing remote access in the metabase sometimes causes the handle to be
closed:
ChildEBP RetAddr
017ff11c 5a403e05 kernel32!CloseHandle
017ff13c 5a4033ca W3CACHE!CDirMonitorEntry::Cleanup+0x52
017ff14c 5a4026b6 W3CACHE!CDirMonitorEntry::Release+0x2e
017ff154 5a3aba23 W3CACHE!CACHE_ENTRY::~CACHE_ENTRY+0x17
017ff160 5a401b9c w3core!UL_RESPONSE_CACHE_ENTRY::`vector deleting
destructor'+0xd
017ff174 5a40212e W3CACHE!CACHE_ENTRY::DereferenceCacheEntry+0x2c
017ff180 6470ff02 W3CACHE!CACHE_ENTRY_HASH::AddRefRecord+0x40
017ff1a0 6470ffaf IISUTIL!CLKRLinearHashTable::_DeleteNode+0x1f
017ff1d8 6470fdf5 IISUTIL!CLKRLinearHashTable::_DeleteIf+0xa5
017ff1fc 5a401f7f IISUTIL!CLKRHashTable::DeleteIf+0x4c
017ff218 5a402f06
W3CACHE!CTypedHashTable<CACHE_HINT_HASH,CACHE_HINT _ENTRY,unsigned short
*,CLKRHashTable>::DeleteIf+0x2b
017ff464 5a40350f W3CACHE!OBJECT_CACHE::DoMetadataInvalidationFlush+ 0x5e
017ff474 5a403948 W3CACHE!CACHE_MANAGER::HandleMetadataInvalidation+ 0x2d
017ff480 5a3c32a6 W3CACHE!W3CacheDoMetadataInvalidation+0x24
017ff4a0 5a3b1839 w3core!W3_SITE::HandleMetabaseChange+0x92
017ff53c 5a3b1b37 w3core!W3_SERVER::HandleMetabaseChange+0x8c
017ff558 5a3b1bb7 w3core!W3_SERVER::MetabaseChangeNotification+0x62
017ff568 6471f6ed w3core!MB_LISTENER::SynchronizedSinkNotify+0x16
017ff588 77c70f3b IISUTIL!MB_BASE_NOTIFICATION_SINK::SinkNotify+0x39
017ff5a8 77ce23f7 RPCRT4!Invoke+0x30

What is the best, reliable way to make IIS release this handle? An older
version of the webapp that ran in ASP.NET 1.1 had a FileSystemWatcher that
unloaded the AppDomain when a certain file was created. This worked but I
can't find out which change between the two caused the change in behaviour.

[Steven Cheng[MSFT]]

Hi Sam,

Welcome to ASPNET newsgroup.
Regarding on the can not delete webapp problem you mentioned, I' m not
quite sure about the "handle" yo mentioned, is it your custom Httphandler
components or any other file handle or assembly that is locked by the IIS
so that you can not remove? Generally the aspx page files will not be
opened as exclusive ,also the private bin assemblies will be shadow copied
to temp dir without any locking issue... Is the items being locked used in
your application through some particular means?

Also, for App_offline.htm file, it is generated file used by VS.NET IDE
when copying site , this file can only prevent any sequential request to
the web application(where the app_offline.htm is put) be redirect to the
offline.htm so as to prevent runtime processing any further request during
the copying website....... So I don't think it'll help release any
resource which is being used already...

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
--------------------
| Thread-Topic: Can't delete webapp after creating app_offline.htm
| thread-index: AcX0LoRC8cgVFrWiSOivg93WgQv11Q==
| X-WBNR-Posting-Host: 32.112.128.18
| From: =?Utf-8?B?U2FtNzc3?= <sa****@nospam.nospam>
| Subject: Can't delete webapp after creating app_offline.htm
| Date: Mon, 28 Nov 2005 07:15:07 -0800
| Lines: 57
| Message-ID: <A9**********************************@microsoft.co m>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSF TNGXA03.phx.gbl
| Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.aspnet:361256
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| I was under the impression that creating the app_offline.htm file at the
| root of the webapp would cause all handles to be closed so that the app
could
| be removed. Unfortunately, this isn't the case. One handle remains open.
|
| Debugging shows that it's actually the IIS cache and not ASP.NET that
owns
| this handle. During IIS shutdown, the handle is closed with the
following
| stack trace:
| ChildEBP RetAddr
| 0006fbe4 5a403e05 kernel32!CloseHandle
| 0006fc04 5a4033ca W3CACHE!CDirMonitorEntry::Cleanup+0x52
| 0006fc14 5a4026b6 W3CACHE!CDirMonitorEntry::Release+0x2e
| 0006fc1c 5a3aba23 W3CACHE!CACHE_ENTRY::~CACHE_ENTRY+0x17
| 0006fc28 5a401b9c w3core!UL_RESPONSE_CACHE_ENTRY::`vector deleting
| destructor'+0xd
| 0006fc3c 5a40212e W3CACHE!CACHE_ENTRY::DereferenceCacheEntry+0x2c
| 0006fc48 647187cd W3CACHE!CACHE_ENTRY_HASH::AddRefRecord+0x40
| 0006fc74 647188c2 IISUTIL!CLKRLinearHashTable::_Clear+0x6f
| 0006fc84 5a40346b IISUTIL!CLKRHashTable::Clear+0x1f
| 0006fc90 5a3af52c W3CACHE!CACHE_MANAGER::FlushAllCaches+0x18
| 0006fca0 5a3b0167 w3core!W3_SERVER::TerminateCaches+0xc
| 0006fcb4 5a3bc26b w3core!W3_SERVER::Terminate+0xff
| 0006ff0c 0100187c w3core!UlW3Start+0x280
| 0006ff44 01001a23 w3wp!wmain+0x22a
| 0006ffc0 77e523cd w3wp!wmainCRTStartup+0x12b
| 0006fff0 00000000 kernel32!BaseProcessStart+0x23
|
| Preventing remote access in the metabase sometimes causes the handle to
be
| closed:
| ChildEBP RetAddr
| 017ff11c 5a403e05 kernel32!CloseHandle
| 017ff13c 5a4033ca W3CACHE!CDirMonitorEntry::Cleanup+0x52
| 017ff14c 5a4026b6 W3CACHE!CDirMonitorEntry::Release+0x2e
| 017ff154 5a3aba23 W3CACHE!CACHE_ENTRY::~CACHE_ENTRY+0x17
| 017ff160 5a401b9c w3core!UL_RESPONSE_CACHE_ENTRY::`vector deleting
| destructor'+0xd
| 017ff174 5a40212e W3CACHE!CACHE_ENTRY::DereferenceCacheEntry+0x2c
| 017ff180 6470ff02 W3CACHE!CACHE_ENTRY_HASH::AddRefRecord+0x40
| 017ff1a0 6470ffaf IISUTIL!CLKRLinearHashTable::_DeleteNode+0x1f
| 017ff1d8 6470fdf5 IISUTIL!CLKRLinearHashTable::_DeleteIf+0xa5
| 017ff1fc 5a401f7f IISUTIL!CLKRHashTable::DeleteIf+0x4c
| 017ff218 5a402f06
| W3CACHE!CTypedHashTable<CACHE_HINT_HASH,CACHE_HINT _ENTRY,unsigned short
| *,CLKRHashTable>::DeleteIf+0x2b
| 017ff464 5a40350f W3CACHE!OBJECT_CACHE::DoMetadataInvalidationFlush+ 0x5e
| 017ff474 5a403948 W3CACHE!CACHE_MANAGER::HandleMetadataInvalidation+ 0x2d
| 017ff480 5a3c32a6 W3CACHE!W3CacheDoMetadataInvalidation+0x24
| 017ff4a0 5a3b1839 w3core!W3_SITE::HandleMetabaseChange+0x92
| 017ff53c 5a3b1b37 w3core!W3_SERVER::HandleMetabaseChange+0x8c
| 017ff558 5a3b1bb7 w3core!W3_SERVER::MetabaseChangeNotification+0x62
| 017ff568 6471f6ed w3core!MB_LISTENER::SynchronizedSinkNotify+0x16
| 017ff588 77c70f3b IISUTIL!MB_BASE_NOTIFICATION_SINK::SinkNotify+0x39
| 017ff5a8 77ce23f7 RPCRT4!Invoke+0x30
|
| What is the best, reliable way to make IIS release this handle? An older
| version of the webapp that ran in ASP.NET 1.1 had a FileSystemWatcher
that
| unloaded the AppDomain when a certain file was created. This worked but
I
| can't find out which change between the two caused the change in
behaviour.
|

[Sam777]

Hi.

Regarding on the can not delete webapp problem you mentioned, I' m not
quite sure about the "handle" yo mentioned, is it your custom Httphandler
components or any other file handle or assembly that is locked by the IIS
so that you can not remove?
It's a native file handle open on the root directory of the webapp e.g.
c:\inetpub\wwwroot\webapp. This prevents us from deleting the directory
which means our uninstaller has to warn the user that they have to manually
remove files which is pretty ugly.

Generally the aspx page files will not be
opened as exclusive ,also the private bin assemblies will be shadow copied
to temp dir without any locking issue... Is the items being locked used in
your application through some particular means?
Our webapp is 100% managed code and the app domain has been shutdown (by
app_offline.htm) so I can't see how our code could be locking anything.

Also, for App_offline.htm file, it is generated file used by VS.NET IDE
when copying site , this file can only prevent any sequential request to
the web application(where the app_offline.htm is put) be redirect to the
offline.htm so as to prevent runtime processing any further request during
the copying website....... So I don't think it'll help release any
resource which is being used already...

Our uninstaller is generating the file - Visual Studio is not involved.
Scott says that the file should remove locks so that maintenance can be
performed - http://weblogs.asp.net/scottgu/archi...06/426755.aspx

Do you know what logic is used to determine whether the
w3core!W3_SERVER::MetabaseChangeNotification function is called when the
metabase is updated e.g. denying access to pages?

Thanks,
Sam.

[Steven Cheng[MSFT]]

Hi Sam,

Thanks for your response.
Since the application is hosted in IIS, the IIS's virtual dir is controled
by IIS manager so I think it is possible that some certain native handle is
held by the IIS to reference the virutal dir. Also, the app_offline.htm is
used for VS.NET IDE to make aspnet request stop being processed by asp.net
runtime, no document about it'll have effect on the IIS's management on the
virtual dir's physical folder..... Generally for deleting application
virtual directory, we're recommended to use the IIS's metabase interfaces
such as ADSI to remove th virtual directory instead of directly deleting
physical directory....

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)


--------------------
| Thread-Topic: Can't delete webapp after creating app_offline.htm
| thread-index: AcX04MKUu6jqAcIpS3exc+oZod/kAQ==
| X-WBNR-Posting-Host: 32.112.128.18
| From: =?Utf-8?B?U2FtNzc3?= <sa****@nospam.nospam>
| References: <A9**********************************@microsoft.co m>
<eh**************@TK2MSFTNGXA02.phx.gbl>
| Subject: RE: Can't delete webapp after creating app_offline.htm
| Date: Tue, 29 Nov 2005 04:31:02 -0800
| Lines: 39
| Message-ID: <67**********************************@microsoft.co m>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFT NGXA03.phx.gbl
| Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.aspnet:361452
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| Hi.
|
| > Regarding on the can not delete webapp problem you mentioned, I' m not
| > quite sure about the "handle" yo mentioned, is it your custom
Httphandler
| > components or any other file handle or assembly that is locked by the
IIS
| > so that you can not remove?
|
| It's a native file handle open on the root directory of the webapp e.g.
| c:\inetpub\wwwroot\webapp. This prevents us from deleting the directory
| which means our uninstaller has to warn the user that they have to
manually
| remove files which is pretty ugly.
|
|
| > Generally the aspx page files will not be
| > opened as exclusive ,also the private bin assemblies will be shadow
copied
| > to temp dir without any locking issue... Is the items being locked
used in
| > your application through some particular means?
|
| Our webapp is 100% managed code and the app domain has been shutdown (by
| app_offline.htm) so I can't see how our code could be locking anything.
|
|
| > Also, for App_offline.htm file, it is generated file used by VS.NET
IDE
| > when copying site , this file can only prevent any sequential request
to
| > the web application(where the app_offline.htm is put) be redirect to
the
| > offline.htm so as to prevent runtime processing any further request
during
| > the copying website....... So I don't think it'll help release any
| > resource which is being used already...
|
| Our uninstaller is generating the file - Visual Studio is not involved.
| Scott says that the file should remove locks so that maintenance can be
| performed - http://weblogs.asp.net/scottgu/archi...06/426755.aspx
|
| Do you know what logic is used to determine whether the
| w3core!W3_SERVER::MetabaseChangeNotification function is called when the
| metabase is updated e.g. denying access to pages?
|
| Thanks,
| Sam.
|

[Sam777]

We've decided to stop investigating this and just shutdown the app pool prior
to uninstallation.

Thanks,
Sam.

[Jim Katz]

Actually, we've seen a bit of this problem. When we use VS IDE to Publish a
Website using FTP, the app_offline.htm is not deleted after the successful
publish. When we try to remove it using FTP console, we see Access denied,
probably because IIS still has the file opened. Attempts to delete the file
using a local console also fail, AccessDenied.

--
Senior Developer
"Sam777" wrote:

We've decided to stop investigating this and just shutdown the app pool prior
to uninstallation.

Thanks,
Sam.