Server Application Error on FileStreaming

[DanTheMan]

I am having some trouble with downloads I offer on our website. Here is the setup: I have a directory called downloads which I have secured using IIS so that only admins and ASPNET user can access. With this setup no user can access the folder from the web unless they a. know the username and password of the admin b. validate through my asp.net application. The user authenticates and navigates to a page which displays all downloads they have access to. They click on the link and I run a sub routine that streams the file and allows them to download it. So here is the problem.

 

We keep having problems with Server Application Unavailable. It is random and the only way to fix it is to reboot the box. I have been monitoring traffic through the website, and it isn't very high, and there is little strain on the box, so I cannot figure out what is happening. Also when I check the application log in the event viewer it gives me the error (aspnet_wp.exe (PID: ####) stopped unexpectedly). This is a huge deal for my company and I have no clue what is going on. Any help would be greatly appreciated.

 

 

------------HERE IS MY CODE---------------

 

Public Shared Sub getFile(ByVal FilePath As String, Optional ByVal ContentType As String = "")

If File.Exists(FilePath) Then

Dim myFileInfo As FileInfo

Dim FileSize As Long

 

myFileInfo = New FileInfo(FilePath)

FileSize = myFileInfo.Length

 

HttpContext.Current.Response.Clear()

HttpContext.Current.Response.ClearHeaders()

HttpContext.Current.Response.ClearContent()

 

HttpContext.Current.Response.AppendHeader("Content-Length", FileSize)

HttpContext.Current.Response.ContentType = "application/octet-stream"

HttpContext.Current.Response.AppendHeader("Content-disposition", "attachment; filename=" & myFileInfo.Name)

HttpContext.Current.Response.WriteFile(FilePath)

HttpContext.Current.Response.End()

 

End If

 

End Sub

[Dirty Howi]

dan, morbid i dunno what i am doing really question, does asp.net support

 

try{

}

catch?

 

if so you may wish to couch your code in one or more of those and treat it like a transaction rather than pulling your hair out, of which i personally have very little left.

[DanTheMan]

I modified the code Friday nigth before I left. To be honest with you I am not even sure that the response.write will work in the compiled code because I haven't been able to test it and really didn't care. :) Anyway it seems to have cured the problem, but then again I could be wrong. Now I am wondering if anyone knows why this portion of code that I wrapped into the try catch block would cough, and die? Also I was reading some other posts and noticed that response.redirects to other .aspx can cause this. Has anyone else heard of this happening?

 

 

Public Shared Sub getFile(ByVal FilePath As String, Optional ByVal ContentType As String = "")

If File.Exists(FilePath) Then

Dim myFileInfo As FileInfo

Dim FileSize As Long

 

myFileInfo = New FileInfo(FilePath)

FileSize = myFileInfo.Length

 

HttpContext.Current.Response.Clear()

HttpContext.Current.Response.ClearHeaders()

HttpContext.Current.Response.ClearContent()

 

Try

HttpContext.Current.Response.AppendHeader("Content-Length", FileSize)

HttpContext.Current.Response.ContentType = "application/octet-stream"

HttpContext.Current.Response.AppendHeader("Content-disposition", "attachment; filename=" & myFileInfo.Name)

HttpContext.Current.Response.WriteFile(FilePath)

HttpContext.Current.Response.End()

 

Catch

HttpContext.Current.Response.Write("Error Streaming File" & myFileInfo.Name)

 

End Try

 

End If

 

End Sub

[DanTheMan]

Well, I found out what was wrong in case anyone is interested. It seems that the writeFile uses the virtual memmory. Our customers were downloading so many files that it was eating up all of our available virtual memmory and causing asp.net to shutdown. So, I had to call microsoft and get a tech on the phone to explain the problem. They are sending me a fix that will take care of the large file downloads. Here is a link to the article. http://support.microsoft.com/default.aspx?scid=kb;en-us;821387