So you try to figure out what could be wrong, which may include the following:

• Debug mode for compilation in web.config. Checked.
• A setting in IIS 7.0 Manager that you’re unfamiliar with. Well, I found a setting for server side debugging in the ASP-section, which existed before. Turning it on didn’t seem to help (why would it?).
• Maybe something with the application pool? There is a mode for “Managed Pipeline Mode”, but setting it to “Classic” didn’t seem to help (as it shouldn’t). Changing the identity of the pool didn’t help either.
• At some point I think I’ve seen something about your account having to be a member of a “debugging” group in your Windows machine. However, there are no such user groups in my local machine. <edit>It seems that this group is not necessary since Visual Studio 2005</edit>
• Also, of course, you have to run Visual Studio 2005 as an administrator, but I’ve done that since the beginning (no need to right click if you set the Properties, Compatability, Run as administrator checkbox for the icon).

I did use Process Explorer to ensure that .net was loaded in w3wp.exe, and sure enough it was.

So I found a note on the web about “Windows Authentication” being used when debugging asp.net. Now I’m not sure if this was the single thing that helped since I tried several things, but after installing “Windows Authentication” in IIS 7.0, the “Managed” code shows up in w3wp.exe and I can attach to it from Visual Studio 2005.

The solution:

• Control Panel
• Programs
• Turn Windows features on or off
• Internet Informaton Services
• World Wide Web Services
• Security
• Check for “Windows Authentication”
• Rebooted computer (just in case – don’t know if it was needed or even if iisreset.exe would have been necessary)

Please write a comment if you’ve had the same problem, and got it solved the same way I did, or if you did something else/more to get it working.

<edit>Although primarily about pressing F5 to automatically attach to w3wp.exe, this blog post talks about what needs to be done.</edit>

An error occurred on the server when processing the URL. Please contact the system administrator.

Hey, that’s me! And then:

Microsoft JET Database Engine error ’80004005′
Unspecified error
/myapp/myscript.asp, line 9

Ok, so I suspected that the first problem was due to the fact that I needed to activate asp scripts in some way. However, turns out it was a new setting for sending the error message to the client (maybe it has existed somewhere before, but I’ve never had to change it). This setting is located in the new IIS Manager:

Features View, ASP, Debugging Properties, Send Errors to Browser

But this only got me to the second error message. And that, I had seen before. It should have something to do with file and directory permissions. Being uncertain about which user IIS 7 actually runs legacy asp scripts as, I used Process Monitor to find the “IUSR” user. But givning that user full permissons to the directory where my.mdb resided didn’t help. So back to Process Monitor – filtering on failed operations from the w3wp.exe process. Ahh! Temporary files. Of course! The OLEDB driver needs access to the system temporary folder to store some files when opening the connection to the database file. And the location for this in Vista is:

C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp

Now, UAC can really drive you mad. I wonder how long I can take it before giving up and turning it off. For security purposes, it is of course great. Then again, I’ve run Windows for a lot of years as a member of the Administrators group, and never had any real security issues. At least not any that I know of…

Pasting “C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp” into the address bar of Explorer will tell you that it doesn’t exist. Well, I didn’t believe Vista so I removed the ending directories until Vista told me that I had to elevate priviliges to get into one of the parent folders. Ok, I did that and now I could get into the full path. Great. A warning that I was changing file permissons on a system directory was all that was standing between me and success – and thankfully that was not an obstacle.

So now I’m running my old asp-scripts until I’ve had the opportunity to convert all projects to asp.net.