Vignesh's Weblog - An Intermittent blog with scraps of ASP.NET\IIS information

"System.Security.SecurityException: Security error" error message when the virtual directory points to a remote share in ASP.NET

2007-08-15T21:41:00Z

This issue is documented in http://support.microsoft.com/?id=320268. I recently worked on issue where the customer was using a virtual directory in IIS 6.0 that points to a remote share to host a Microsoft ASP.NET-based application. The remote share was on a 3rd party NAS device (NetApp Filer). The actual error message was

Server Error in '/XYZ' Application.

Security Exception

Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.

Exception Details: System.Security.SecurityException: Request for the permission of type 'System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[SecurityException: Request for the permission of type 'System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.]

System.Reflection.Assembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase) +0

System.Reflection.Assembly.GetType(String name, Boolean throwOnError) +12

System.Web.Compilation.BuildResultCompiledType.GetPreservedAttributes(PreservationFileReader pfr) +73

System.Web.Compilation.PreservationFileReader.ReadFileInternal(VirtualPath virtualPath, String preservationFile, Int64 hashCode) +630

System.Web.Compilation.PreservationFileReader.ReadBuildResultFromFile(VirtualPath virtualPath, String preservationFile, Int64 hashCode) +79

System.Web.Compilation.DiskBuildResultCache.GetBuildResult(String cacheKey, VirtualPath virtualPath, Int64 hashCode) +71

System.Web.Compilation.BuildManager.GetBuildResultFromCacheInternal(String cacheKey, Boolean keyFromVPP, VirtualPath virtualPath, Int64 hashCode) +166

System.Web.Compilation.ApplicationBuildProvider.GetGlobalAsaxBuildResult(Boolean isPrecompiledApp) +65

System.Web.Compilation.BuildManager.CompileGlobalAsax() +51

System.Web.Compilation.BuildManager.EnsureTopLevelFilesCompiled() +462

Version Information: Microsoft .NET Framework Version:2.0.50727.832; ASP.NET Version:2.0.50727.832

Even after following the resolution section in http://support.microsoft.com/?id=320268 we were still getting the same error. To isolate the issue I had the customer create another network share on a Windows Server and then apply KB 320268. We were sucessfully able to browse to the ASP.NET application. Nice trick right? :)

At this point it's very easy to convince the customer that the issue is with a 3rd party product and redirect them to the 3rd party for further assitance before closing out the case. I got the feeling that the customer could sense that this was coming but I wasn't ready to give up yet.

After a lot more digging...we found that the NetApp Filer was having two hostnames but a single IP adress.........

Eureka!

The next logical thing to do??

In step 6 while adding a new code group type in the IP adress of the NAS Device instead of the hostname.

Replace file:////\\computername\sharename\* with file:////\\<IPAdress>\sharename\*

Until next time...Cheers!

Compiler Error Message: CS0016: Could not write to output file 'c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\MyApp\fadda49e\bbdb0b87\eqdatzch.dll' -- 'Access is denied.'

2007-02-08T23:10:00Z

What I like about the above error message is the part which says 'Access is denied.' These are some of the easiest issues to fix!! Right?? Well in most cases 'Yes'. All you have to usually do is give the Process Account or Impersonating thread identity required NTFS access to the resource. The reason I like working here in PSS is because you get to work on issues which will blow your mind (EVERYDAY). Most customers would have already Googled for a solution and tried an extensive list of things trying to fix the issue. If they haven't already done that, then they are calling because the WebSite is down and the business impact $$$$$$$$ is "HUGE".

In this case the customer was of the former type. He had tried everything to fix the issue but to no avail. To give you a little background on the issue, the Web Server was a Windows 2003 SP1 server(IIS 6.0) running an ASP.NET WebService. The App used to work fine until it threw the above error. According to the customer, the only way to recover from the problem was to repeatedely reboot the machine and the error would go away. I had never heard of anything like this before. Neither have the 3 Engineers who worked on this issue before engaging me to have a go at the problem heard of anything like this. The typical way to troubleshoot this problem would be to verify that all the permissions and policies were in place as per the knowledge base article Process and request identity in ASP.NET: http://support.microsoft.com/kb/317012 .

The AppPool identity was the default "Network Service" account. After verifying kb317012 a dozen times we were still getting the error. The bizzare part was that "Network Service" account had Full Control on "c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files" folder but running Filemon would still show Access Denied for the "Network Service" account on "c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files" folder. The Engineers had tried various way to troubleshoot the problem. They tried changing the AppPool Identity to a domain account but this resulted in the same error and Filemon now showed Access Denied for the domain account. This is about when I came in and I requested the customer to allow us to view his desktop via a Live Meeting.

Working here for over 2 yrs has taught me never to trust anyone, especially customers. In this case I didn't trust my fellow Engineers as well so I went through all the same troubleshooting steps they had done (I dont like making assumptions without hard facts). This dosen't go down too well with customers as nobody wants to try the same steps repeatedely, if you already know its not going to help. While I was checking the NTFS permissions for the Network Service account on "C:\Windows\Temp" something caught my EYE and I made sure I took a PRINTSCREEN so that I can share this information with you :)

RESOLUTION
===========
If you notice clearly, the "C:\Windows\Temp" location is not a folder but a Mounted Drive. If you then click the Security Tab for "C:\Windows\Temp" you can see the Network Service account present with FULL CONTROL. Instinct tells me that this may be related to the issue so the next logical step would be to isolate the problem and see if changing the "C:\Windows\Temp" helps.

I changed the values of the TMP and TEMP System Environment variables to point to "C:\TEMP" instead of "C:\Windows\Temp" and this resolved the issue.

IIRC they had the "C:\Windows\Temp" location set up as a mounted drive to store huge number of files there which were getting writin by some other application. Somehow ASP.NET didnt like it.

Now you might still wonder, why do we get the error if all the permissions seem to be in place?? As much as I would have liked, I couldn't invesitigate further since we already had an acceptable solution as it is not worth the time and effort to find out why mounted volumes are causing the issue.

A WAP project opens up as a WEBSITE in VS2005 if the webinfo file is present in the content folder

2006-11-02T12:28:00Z

SCENARIO
==========
Customer migrates his asp.net 1.1 app to asp.net 2.0 app using VS2005 and WAP. He then started working on it. A month ago he created a backup of the application by copying the entire content folder onto a different drive. D:\Backup\appname.One not so fine day he decides to rollback the changes to his current project C:\inetpub\wwwroot\appname so he copied all the files in D:\Backup\appname to C:\inetpub\wwwroot\appname.

Now when he opens the project in VS2005, it opens as a website instead of a WAP project which is undesirable as the views are different.

I found that the .webinfo file was causing the issue. Deleting the .webinfo file resolved the issue. Now the WAP project opens as a WAP project. I am unsure why or how the webinfo file creaped into the project folder because creating a new WAP project does not include the webinfo file.

See a similar issue documented in You cannot open ASP.NET Web application project after deployment
http://support.microsoft.com/kb/830611/en-us?spid=3041&sid=147

How to change the default TempFile upload location for the ASP.NET 2.0 FileUpload control?

2006-10-25T07:40:00Z

We used to see a lot memory related issues with File uploading in ASP.NET 1.1 as ASP.NET loads the whole file in memory before saving the file to disk. In ASP.NET 2.0 you can use the FileUpload control which buffers the file on disk while it is being uploaded. This is a great improvement as it does not kill your worker process memory, however if you do not have sufficient space on your disk “C:\” drive then it's likely that you will start seeing those infamous System.OutOfMemoryException's errors again. So the question is where does ASP.NET temporarily buffer the file before it stores it to disk?

Dumping out the HttpRawUploadedContent from a memory dump, I can see that the file is buffered in the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\fileupload20\d909613c\d78e07ba\uploads files folder and is called f-zqaz-r.post

0:008> !do 017c3fbc

Name: System.Web.HttpRawUploadedContent+TempFile

MethodTable: 68a870e0

EEClass: 68a87070

Size: 20(0x14) bytes

GC Generation: 0

(C:\WINDOWS\assembly\GAC_32\System.Web\2.0.0.0__b03f5f7f11d50a3a\System.Web.dll)

Fields:

MT Field Offset Type VT Attr Value Name

7a754a14 4000fb0 4 ...empFileCollection 0 instance 017c4944 _tempFiles

790fa3e0 4000fb1 8 System.String 0 instance 017c54e4 _filename

790fe3c8 4000fb2 c System.IO.Stream 0 instance 017c55f8 _filestream

0:008> !do 017c54e4

Name: System.String

MethodTable: 790fa3e0

EEClass: 790fa340

Size: 262(0x106) bytes

GC Generation: 0

(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)

String: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\fileupload20\d909613c\d78e07ba\uploads\f-zqaz-r.post

If you want to change the default location, The tempDirectory attribute of the <compilation> element allows you to specify the directory to use for temporary file storage during compilation. The default is an empty string (""). In the case of an empty string, and if the current process has the required access permissions, the files are stored in the %FrameworkInstallLocation%\ Temporary ASP.NET Files directory.

For more details on <compilation> element see http://msdn2.microsoft.com/en-us/s10awwz0.aspx

I tested this by creating a folder called “D:\TempFileFolder” and modifying the web.config to <compilation debug="false" tempDirectory="D:\TempFileFolder"/> . The path specified for the files to be uploaded was D:\Uploads. Now running the application uploads the file to D:\uploads and all the temporary files are stored in “D:\TempFileFolder”

Running Filemon you can see the sequence of Disk Access by aspnet_wp.exe. At the end you will notice

“10172 5:27:39 AM aspnet_wp.exe:5636 DELETE D:\TempFileFolder\fileupload2.0\c45dc80b\4a2ce08b\uploads\rcrwfuj5.tmp SUCCESS” which I believe is the buffered file which is deleted after it has been written to D:\uploads.

So if you run into a situation where there is not enough disk space on the default "C:\...." Drive as the C:\ drive is continuously accessed by your web app while users are uploading files, you can change the tempDirectory attribute to a different drive or path of your choice.