I'm having the same problem in the same environment (IIS7, Vista64). The memory profiler runs fine, as does the performance profiler when it runs against a web application hosted in Cassini. The problem is specific to IIS7 and occurs no matter how simple (or complex) the website is that I am trying to profile. The internal server error occurs regardless of whether I profile on the original port or on an unused port.
The hostablewebcore event log entry just points back to itself and is no help. There is no "Environment" registry value to delete.
I've unsuccessfully tried a number of access-control and security-related workarounds, including temporarily disabling my firewall and all anti-virus software. Here's a rundown of what customer service suggested and what I tried.
- Run the Windows Registry Editor (regedit.exe)
- Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC- Delete the value called "Environment"
There wasn't an Environment value in the registry, nothing to delete...
What you may want to do is make sure that the account ('Network Service', by default') running your application pool has permissions to the "Temporary ASP .NET Files" folder, including subdirectories. The hidden cause of this problem, when it happens, is that your app pool's account also needs full control over the "c:\windows\temp" folder. (http://social.msdn.microsoft.com/Forums ... 46870d8a4/)
I created an ACL that explicitly granted the app-pool account (NETWORK SERVICE) full access to the following folders (and their subfolders): c:\windows\Microsoft.Net\Framework\ v2.0.50727\Temporary ASP.NET Files, c:\windows\temp, and %temp%. No change.
You may also find your 'Network Service' account no longer has the permissions necessary to run sites, after installing Ants Profiler. To temporarily fix the problem run the App Pool under the 'Local System' account.
I changed the app pool to run under the Local System account and then went back and rechecked the ACLs to ensure that SYSTEM had full access to the folders used by ASP.NET. No change.
You could try using the ASPNET_REGIIS.exe utility that comes with the .NET Framework. It can automatically assign all the permissions for ASP .NET to an account, including the metabase and temporary files folder. You can run this from the command prompt:
%systemroot%\microsoft.net\framework\v2.0.50727\aspnet_regiis -ga "NT Authority\Network Service"
I restored the App-pool account to Network Service and ran the above command. It completed successfully, but there was no change.
We also think that what may have happened to your IIS installation is that some files and folders may have the ACLs set up explicitly for the SYSTEM account. Although this has never happened before, you may want to try emptying out your .NET Framework's "Temporary ASP .NET Files" folder and see if that gets it working for you.
I cleared out the temporary asp.net files folder, recycled the app pool, restarted IIS. No change
I can't figure out where the temporary copy of applicationHost.config gets created either. A post in another thread (http://www.red-gate.com/messageboard/viewtopic.php?t=8574) mentioned that the local copy of applicationHost.config generated by the profiler before starting a profiling session on an IIS-hosted website is called tmp{something}.config and that this temporary config file is created in %USERPROFILE%\AppData\Local\Red Gate\ANTS Performance Profiler 4. That temporary config file copy never gets created on my machine, and I know that the profiler has write access to the appdata\local\ANTS Performance Profiler 4 folder because it creates a logfile in that folder every time it runs. (Those logfiles don't contain any additional clues or stack traces either.) I also tested to see if I could manually make a copy of applicationHost.config file, and that worked OK, so there are no file-protection problems on that config file or on its containing folder. / comments
- Community
- ANTS Performance Profiler Previous Versions
- HTTP Error 500.0 - Internal Server Error
I'm having the same problem in the same environment (IIS7, Vista64). The memory profiler runs fine, as does the performance profiler when it runs against a web application hosted in Cassini. The p...
0 votes
