Registry tweaks for attaching to IIS 7 worker process from Visual Studio 2010

One of the common techniques for debugging ASP.NET applications is to attach the Visual Studio IDE debugger to a running IIS 7 worker process.

I have been doing this for so many years that my fingers, without even thinking, press "Ctrl+Alt+p" to bring up the "Attach to Process" dialog (alternatively, you can get to it by "Debug | Attach to process..." menu item)

With Visual Studio 2010 on Windows 7 (IIS7), when you bring up "Attach to Process", it will look like this by default:

Notice that "Show processes from all users" and "Show processes in all sessions" are not selected. That prevents IIS 7 worker process from showing up in the list. (By the way, my finger also remembers to hit "w" to jump to the parts for processes with their names starting with "w")

When you check both "Show processes from all users" and "Show processes in all sessions", w3wp.exe, our IIS 7 worker process, will show up.

However, it is a pain in the neck to press these two check boxes every time I want to debug.

I looked for configuration settings in "Tools | Options" dialog but could not find any. Then, I looked for Registry entries and I found them.

Here is the steps for making these check boxes permanently "checked".

1. Close all of your running instances of Visual Studio. This is important as in-memory values of a running instance will overwrite any new value in the registry. So, close it.

2. Go to HKCU\Software\Micorosoft\VisualStudio\10.0\Debugger, then look for a value called ShowProcessesFromAllSessions and ShowSystemProcesses

3. Change its value from 0 to 1 for both.

Below is to help you find it visually.

4. Now, start Visual Studio and see the effect. Back to "Ctrl+Alt+p" and then "w" workflow!

Enjoy!

IIS says "The process cannot access the file because it is being used by another process"

After I installed a SSL certificate to our IIS 7, any attempt to "Start" the website would result in this error message.

The process cannot access the file because it is being used by another process

I was like... "huh??"

It turned out that our VisualSVN server (a Windows Service process) was the issue. It was using port 443 which was preventing SSL-enabled website to start up.

I used CurrPorts to figure out who was using port 443.
Specify the following lines in its "filter" and you will see a list of processes, with their PID, who have opened port 80 and port 443

include:local:tcp:80
include:local:tcp:443

With the PID value and Task Manager, I found out that VisualSVN server was opening 443, but it was using a different IP address than the one I am using for our game website. What gives?

#1 Change VisualSVN Server Binding to a single IP address

I started VisualSVN GUI and clicked "Configure authentication options..." and in its "Network" tab, I found that "Server Binding" was set to "All IP addresses". That doesn't look right, and there is an alternative option called "These IP addresses", which takes a list of IP addresses, so I switched to it and gave the IP address it was bound to.

Now, I thought it would fix the website start up problem... but No! I was still getting the same "The process cannot access the file because it is being used by another process" error message.

It was clear to me that VisualSVN server process was causing the problem because if I stop the service then I can start the SSL-enabled website without any issue. The problem is that once I start the website, then I wan't able to start VisualSVN.

To fix the problem, I did a couple of things described below. I think the action #3 is actually attributed to fixing the problem, but #2 may also be part of it. I don't feel like undoing neither to just to find out that. I already spent hours on this and don't want break anything...

#2 Configure ListenOnlyList Windows registry subkey properly

This is one of the things described in a Microsoft KB to fix this "The process cannot access..." problem to fix the problem IIS website start up problem.The KB article had basic instructions but didn't have good example, so I ended up using an example from  this short article.

I checked the registry, and our machine did not have ListenOnlyList registry subkey. According to KB article, absence of ListenOnlyList subkey implies that it would operate on "any IP addresses". I am not quite sure what this really implies to my situation, but I wanted to eliminate any "blanket" rules like that, so I created ListenOnlyList subkey and added all of the IPs that this box was using.

#3 Change the port VisualSVN uses to something other than 443

The previous step did not fix the problem. I was still getting the same error message. Then next logical step is to not to use the same port. Luckly, SVN was for private use only and all we wanted was its transmissions were encrypted, so I could use any port. So, I chose another port value for SVN in VisualSVN GUI.

Of course, this causes all existing sandboxes on developers' machines to be invalid. To fix this, all we had to do was to invoke "relocate..." command on developers' machine to map to the new address of the SVN repository, which now needs an explicit port number as part of its URL.

After this, both website and VisualSVN server were running, providing the intended functionality.