Why is ASP.NET failing due to permissions on GAC?

Question

I'm trying to run an ASP.NET 2.0 application on an XP machine. As far as I know, everything is configured correctly. However, I receive the following message:

Server Application Unavailable

And two events appear in the Application event log each time:

aspnet_wp.exe (PID: 3352) stopped unexpectedly.

Failed to execute the request because the ASP.NET process identity does not have read permissions to the global assembly cache. Error: 0x80070005 Access is denied.

Previously, ASP.NET applications worked fine on this machine.

I've tried the following steps, with no luck:

• I've granted read permissions on the site home directory to the ASPNET account
• I've reinstalled ASP.NET 2.0 using aspnet_regiis -i
• I've granted permissions to the ASPNET account using aspnet_regiis -ga <my machine name>\ASPNET
• I've granted read permissions to the GAC to the ASPNET account using CACLS %WINDIR%\assembly /e /t /p <my machine name>\ASPNET:R
• I've set the ASP.NET version for the site to 2.0 within IIS

I'm not sure what else I can do!

---

Using Process Monitor led me directly to the problem. Many thanks to Mun for the tip.

It was quite an obscure issue: I had previously used the assembly binding log viewer (fuslogvw.exe) and set it to log all binds to disk using the custom path option. However, the ASPNET account did not have permissions to that custom path. So, reverting to using the default path resolved the issue. Granting read/write permissions on that custom path to the ASPNET account also works, as does disabling bind logging.

Answer 1

Here are the necessary permissions: http://msdn.microsoft.com/en-us/library/kwzs111e.aspx

More info: http://support.microsoft.com/default.aspx?kbid=811320

The commands you've run should be enough, but it's worth checking :)

Answer 2

You might also find Process Monitor useful for troubleshooting these types of problems. If you set-up a filter to show all activity containing aspnet_wp.exe, it should show you which files it's attempting to access, allowing you to update the permissions accordingly.

Answer 3

We used to have this problem with ASP.NET because when Visual Studio created its temporary copy of the assemblies the indexing service would start scanning them for viruses, and this would occasionally cause an 'access denied' message because the debugger would be trying to open a shared file. Telling the indexing service to not index the temp assemblies directory solved the problem.