ThreadAbortException in ASP.Net 4 leaking file handle?

3
votes

Ocassionally if our file server is slow and the page doesn't finish by its timeout ASP.Net will hit it with a ThreadAbortException. If that happens inside the Win32Native.CreateFile it's leaving the file handle locked until we do iisreset.

Is this a flaw in .NET? Is there anything we can do about this short of bad ideas like raising the timeout to some giant number... I don't think ThreadAbort.Reset would help because the damage is already done and I don't even have the file handle returned from FileStream to close it myself.

at Microsoft.Win32.Win32Native.CreateFile(String lpFileName, Int32 dwDesiredAccess, FileShare dwShareMode, SECURITY_ATTRIBUTES securityAttrs, FileMode dwCreationDisposition, Int32 dwFlagsAndAttributes, IntPtr hTemplateFile)

at Microsoft.Win32.Win32Native.SafeCreateFile(String lpFileName, Int32 dwDesiredAccess, FileShare dwShareMode, SECURITY_ATTRIBUTES securityAttrs, FileMode dwCreationDisposition, Int32 dwFlagsAndAttributes, IntPtr hTemplateFile)

at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath)

at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)

at System.IO.FileStream..ctor(String path, FileMode mode)

2
.netmultithreadingexception-handlingthread-safetyresource-leak

2 Answers

1
votes

It looks like you submitted this question to Microsoft Connect also and didn't update here with their answer:

http://connect.microsoft.com/VisualStudio/feedback/details/739044/threadabortexception-in-asp-net-4-during-new-filestream-leaking-file-handle

Here is the response from Microsoft:

Performing long running operations in synchronous requests in ASP.NET is not recommended. If you're hitting the timeout period, you can choose to simply increase the configured request timeout or change to using asynchronous requests, which don't timeout during the execution of the asynchronous operations, and hence don't throw thread abort exceptions.

I guess thread abort (or any asynchronous exception for that matter), can and will do this eventually.

But it appears the framework will use SafeFileHandle internally in opening the file, so it should be closed by the garbage collector when it leisurely gets around to it.

0
votes

Are you closing the file properly in your code by having close in your finally clause or by using the using approach?