I have searched the forums for hours looking for a good solution to this problem.  I am running DotNetNuke 4.3.4 and am having issues downloading a zip file that is 185 MB.  I have other zip files that are 65MB that it has no problem with, but in particular this 185 MB file always gives a System.OutOfMemoryException.  I can't download it from the Filemanager either.  It is in a secured folder, but I don't think this is related to the problem.  The log for the error when trying to download the file from the FileManager is:

AssemblyVersion: 04.03.04
PortalID: 13
PortalName: Developer Network
UserID: 77
UserName: Samuel
ActiveTabID: 337
ActiveTabName: File Manager
RawURL: /Default.aspx?tabid=337&error=Could+not+find+file+'E%3a%5cWebs%5cDotNetNuke%5cPortals%5c13%5cDownloads%5cDeveloper%5cAltiris+7%5cAltirisSDK_021207.zip.resources'.&content=0
AbsoluteURL: /Default.aspx
AbsoluteURLReferrer: http://portals.altiris.com/Default.aspx?tabid=337&error=Could+not+find+file+'E%3a%5cWebs%5cDotNetNuke%5cPortals%5c13%5cDownloads%5cDeveloper%5cAltiris+7%5cAltirisSDK_021207.zip.resources'.&content=0
UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
DefaultDataProvider: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider
ExceptionGUID: e3c59089-8f3f-4c23-adf0-f4f00d797bcc
InnerException: Exception of type 'System.OutOfMemoryException' was thrown.
FileName:
FileLineNumber: 0
FileColumnNumber: 0
Method: System.IO.BinaryReader.ReadBytes
StackTrace:
Message: DotNetNuke.Services.Exceptions.PageLoadException: Exception of type 'System.OutOfMemoryException' was thrown. ---> System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown. at System.IO.BinaryReader.ReadBytes(Int32 count) at DotNetNuke.Common.Utilities.FileSystemUtils.DownloadFile(PortalSettings settings, Int32 FileId, Boolean ClientCache, Boolean ForceDownload) at DotNetNuke.Modules.Admin.FileSystem.FileManager.lnkDLFile_Command(Object sender, CommandEventArgs e) at System.Web.UI.WebControls.LinkButton.OnCommand(CommandEventArgs e) at System.Web.UI.WebControls.LinkButton.RaisePostBackEvent(String eventArgument) at System.Web.UI.WebControls.LinkButton.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument) at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) at System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) --- End of inner exception stack trace ---
Source:
Server Name: ALID-DNN

I don't believe DNN 4.3.4 has compression or a whitespace filter (I've checked more than once) so I don't see how this can be the problem.  I can't find an executionTimeout in my webconfig if that matters.  Even if it did matter, the page load fails immediately so I don't believe its linked to any timeout.  A open file or save dialog never occurs.  If a normal user were to click on the download link he would see a page that would say:

Server Error in '/' Application

on it.  Its possible that too much caching is occuring and is being saved in memory rather than disk.  I am only an admin on the portal and do not have host priveledges.  I've spoken with the IS team who have host privleges and at the moment they are unwilling to budge on their host settings (including the caching settings).  Hopefully that is not the issue.  I will push again to have them change it.

If anyone has any ideas, I'm all ears.

I can confirm Anthony's comment.  I had the same issue when i was running on 4.3.7 then I upgraded to 4.4.1 and the issue is resolved. 

---

-Mitchel Sellers
Microsoft MVP, ASPInsider, DNN MVP
CEO/Director of Development - IowaComputerGurus Inc.


Visit mitchelsellers.com for my mostly DNN Blog and support forum.

Visit IowaComputerGurus.com for free DNN Modules, DNN Performance Tips, DNN Consulting Quotes, and DNN Technical Support Services

The IS Team got the server back up.  They just did a iisrestart so the problem may rear its ugly head in the future if they don't figure it out.  Also, I can now download that large file even though I've changed nothing.  This really supports the idea that it was low on memory, though that shouldn't matter.  As has been said, the later DNN versions don't store the entire file in memory while its being served.  Perhaps if I knew where that code was I could modify it to be like the current DNN versions.  I might be able to get away with that with the IS team.