I have recently had the same experience going from WinXP to Win7 in our dev environment and had have exactly the same grief with some of our legacy apps. Here's how I fixed it.
To be clear, our Classic ASP website makes calls off to our in-house VB6 .dlls and it was these .dll files that I wanted to be able to step into and debug.
Enable 32-bit applications
In the Application Pools section, right click on the website's application pool and select 'Advanced Settings'.
ASP Authentication
As @GregWoods has suggested, check the authentication details of the website in IIS, As follows:
- Anonymous Authentication – DISABLED
- ASP.Net Impersonation – DISABLED
- Basic Authentication – ENABLED
- Forms Authentication – DISABLED
- Windows Authentication – ENABLED
Run the VB6 application inside the Visual Basic IDE and open a web browser; navigate to the website and when the code enters the external VB6 .dll, the Visual Basic 6 environment should now stop on the breakpoints set in your code. Ta da.
A step more??
I also wanted to be able to debug the actual Classic ASP pages themselves from within VS2010 or VS2012... which is entirely possible too, but there's an extra step to add to this list, simply to instruct IIS to :
In IIS, click on the website that created earlier and in the Features view, click on ‘ASP’.
Expand the ‘Debugging Properties’ option group.
Change the ‘Enable Client-side Debugging’ to ‘True’.
Change the ‘Enable Server-side Debugging’ to ‘True’.
Click ‘Apply’ to save. (Top right corner of the Actions pane).
Then, in order to make Visual Studio stop on a breakpoint, you have to Attach to Process:
Go to the 'TOOLS' menu, and select 'Attach to Process...'
Change the 'Attach to' option to 'Automatic: Native code'
Select the 'w3wp.exe' process and click 'Attach'.
Now, when you open the website in your chosen browser and nabigate to your website, IIS and VS2010/VS2012 will work in conjunction and Visual Studio will stop on any break points.
Hope this helps you.