VS 2010 - Hangs when debugging ASP.Net 3.5 web application or website

File Name	Submitted By	Submitted On	File Size
556000.zip (restricted)	JoelVarty	5/3/2010	-

Posted by Manimaran on 10/27/2010 at 2:24 AM

I had the same issue after having converted a VS 2008 ASP.NET 3.5 website to VS 2010 ASP.NET 3.5 Website using the built in conversion wizard. This problem was only with this project.

I tried to install the following hotfix and it appears to have fixed the problem. Now, when I go F5, it opens up the browser and the breakpoints are hit as expected.

https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=30738&wa=wsignin1.0

Hope that helps.

Posted by Matt Olson on 9/28/2010 at 11:59 AM

FYI, I opened a new support request and they were finally able to repro this issue. (Though it may not be entirely the same as this one). They said they have fixed it internally but you have to contact Microsoft to get the fix.

The connect bug that was marked as FIXED which may relate to this connect bug is here:

https://connect.microsoft.com/VisualStudio/feedback/details/599221/visual-studio-2010-hangs-after-several-debugging-sessions-with-blank-ie-window

Hopefully if they get enough people calling into support for this fix they will officially release it as a hot fix just like the Find/Replace pixel bug a few weeks ago.

Be sure to reference the above connect bug when calling support.

Posted by MattOARRT on 9/14/2010 at 11:55 AM

I am also experiencing this issue in VS 2010 when developing ASP .NET applications.

I believe this is related to this bug report: https://connect.microsoft.com/VisualStudio/feedback/details/521383/visual-studio-hangs-after-several-asp-net-debugging-sessions?wa=wsignin1.0

It is indicated that IE 8 is what is hanging and Visual Studio 2010 is still responding and this is exactly what I'm experiencing. I just see a white screen like it's about to load in IE, but nothing ever happens. The patch indicated here: https://connect.microsoft.com/VisualStudio/feedback/details/556000/vs-2010-hangs-when-debugging-asp-net-3-5-web-application-or-website#tabs, does not fix the issue for me. I still experiencing hangs after several debugging sessions. and need to close IE, then start debugging again and it is hit or miss when it finally comes up. This has been a huge productivity decline moving to VS 2010 due to this bug.

There are many, many people that are getting this as well. Here is a short list of my 20 seconds of searching, theres probably many, many more:

https://connect.microsoft.com/VisualStudio/feedback/details/574793/vs-2010-hangs-frequently-when-debugging
https://connect.microsoft.com/VisualStudio/feedback/details/574564/debugging-a-web-project-hangs-often
https://connect.microsoft.com/VisualStudio/feedback/details/556129/vs2010-crashes-on-debug-and-or-doesnt-attach-to-iis-on-debug
https://connect.microsoft.com/VisualStudio/feedback/details/551033/vs-net-2010-hangs-on-f5-start-debugging-asp-net-app-on-local-iis

When will that issue be fixed??? The patch released so far does NOT fix it!

Posted by tomotayo on 9/10/2010 at 2:00 AM

There is now a fix released for this bug which is working well for me so far. The fix for this is now available for download and install from https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=30738&wa=wsignin1.0
or
http://code.msdn.microsoft.com/KB2106584

Posted by Microsoft on 8/26/2010 at 11:36 AM

Hello,

The fix for this is now available for download and install from https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=30738&wa=wsignin1.0

or

http://code.msdn.microsoft.com/KB2106584

Best Regards,
Visual Studio Debugger

Note: The fix for this issue was packaged with the fix for another issue, the KB article currently only lists the other issue, but this download does contain both fixes

Posted by MaarekElets on 8/20/2010 at 5:31 AM

It's getting really close to September and you haven't updated us on this bug since late June. I am not able to debug with any dependability since none of the workarounds work 100%. Please at least update us on the progress.

Posted by Ben Demes on 8/10/2010 at 7:42 AM

I can confirm I have also seen this issue. A 3.5 application using impersonation. Debugging worked fine in 2008. MattBrooks work around is working for me.

Posted by Microsoft on 6/29/2010 at 10:34 AM

Hello,

We are in the process of testing and releasing the fix for this issue. We will post the download location for the hotfix when it is available.

Best Regards,
Visual Studio Debugger

Posted by vitch on 5/26/2010 at 6:15 AM

Sorry for the noise! MattBrooks' workaround did work for me! I needed to restart IIS after changing the relevant permissions...

I'd still be interested to know when a real fix is available though - the current workaround isn't exactly secure!

Posted by vitch on 5/26/2010 at 6:09 AM

Some further information:

I tried the workaround of adding the impersonated user to the administrators group and this didn't appear to help. I can't try the other workaround as the "Attach to process" option isn't available in the express editions.

Posted by vitch on 5/26/2010 at 6:06 AM

I am having what I think is a very similar problem. I am using Visual Web Developer 2010 Express on a .NET 3.5 project running on a local install of IIS 5 on XP. When I hit debug VS builds the project and then totally hangs. If I update the project to target .NET 4 then I can debug successfully. I can also debug successfully from Visual Web Developer 2008 Express (which I was using until this point).

I am very keen to check out 2010 and the new features it offers but this is preventing it (unfortunately updating the project to .NET 4 is not an option). Is this the same problem reported here? If so then how do I go about getting a fix. If not, should I submit a more detailed bug report somewhere else?

Posted by Microsoft on 5/14/2010 at 5:04 PM

Thank you everyone that contributed dumps and feedback, especially thank you Mark, your project reproduced the issue for us, and let is discover what in the website is causing the problem. We have all of the information that we currently need, and are currently working on a solution.

What is happening is that in some cases IIS is loading a .NET 4.0 component into IIS even though the site is running a .NET 2.0-3.5 (CLR v2) application. This confuses the debugger, and the debugger tries to debug with the .NET 4.0 engine.

Anyone blocked by this can try the workaround mentioned above (although we are still working with the IIS team to determine why this workaround prevents the problem--it may not in all cases) or temporarily upgrading the site you need to debug to .NET 4.0 will prevent the problem.

Best Regards,
Andrew Hall
Visual Studio Debugger

Posted by mbiewer on 5/14/2010 at 7:54 AM

Andrew, Actually I meant Uploaded, not downloaded. Thanks, Mark

Posted by mbiewer on 5/14/2010 at 7:53 AM

Andrew, the name of the file I downloaded was DebuggerDemo.zip. Thanks, Mark

Posted by mbiewer on 5/14/2010 at 7:53 AM

Andrew, I was able to strip down a project that was duplicating the issue. I've sent a zipped copy of the project to the location you've identified. Load the project in Visual Studio as an IIS application using .NET 3.5. Set default.aspx as the start page. Press F5. The default.aspx page should load. Close the browser window and press F5 again. Visual Studio 2010 consistently hangs on my machine after this second attempt. Killing Visual Studion and IISRESET allow me to attempt again. I've posted other information on 5/11/2010 that identifies my operating environment, if needed. Thanks, Mark

Posted by Ian.B on 5/14/2010 at 6:28 AM

Andrew,
I uploaded a dump named iboldenNetportal.7z. This files contains a dump of VS when it hangs during debug. I am not able to upload our project due to its nature. I will help in anyway I can otherwise.

Windows 7
VS 2010
.NET 4.0
TargetFramework 3.5
Using impersonation
Application Pool - Integrated Framework v2.0

When I add the user I use for impersonation to the local Administrators group I am able to debug (see Matt Brooks workaround)

Ian

Posted by Microsoft on 5/13/2010 at 7:32 PM

Hello,

We apologize for this issue, and have determined what is going wrong inside Visual Studio that causes this behavior; we are working on a solution. One thing that would be helpful for us is to understand what it is about the applications you are debugging that is causing the particular behavior in IIS that results in the Visual Studio debugger hanging.

Would it be possible for you to collect a dump without heap of the IIS process (w3wp.exe) when you hit this hang? (instructions for collecting dumps can be found here: http://blogs.msdn.com/debugger/archive/2009/12/30/what-is-a-dump-and-how-do-i-create-one.aspx)

You can upload the dump file to the following workspace (you may want to zip it to reduce the size):
URL: https://sftus.one.microsoft.com/choosetransfer.aspx?key=c844293f-0228-4b12-aaf6-efb6fd1fcd02
Password: #]{Gg$j]WD

Also, if it would be possible for anyone to upload their project that produces this problem that would be helpful as well. Zipped projects can be uploaded to the workspace mentioned above, which is secure and uploaded files are only accessible by Microsoft.

Best Regards,
Andrew Hall
Visual Studio Debugger

Posted by Ian.B on 5/13/2010 at 12:01 PM

I found this work MattBrooks workaround to be effective. I too am using impersonation. I added the domain login to the local admin group and am able to debug repeatedly.

Thanks Matt!

~Ian

Posted by Ian.B on 5/13/2010 at 11:18 AM

This is really tough to work with, constantly having to shut VS 2010 from task manager. Restarting IIS, then VS, just to debug. Rough, we depend on VS to work. Acts like it cannot attach to process or never detaches from the previous debugging session.

Posted by M_Brooks on 5/13/2010 at 2:25 AM

This problem seems to be related to IMPERSONATION. That is, when the ASP.NET web application config file contains the IDENTITY element: <identity impersonate="true" userName="MYDOMAIN\DOMAINASPNET" password="********"/>

Please note that in my case the impersonated 'DOMAINASPNET' account is a windows domain account.

As a temporary workaround I've added the domain account to the local ADMINISTRATORS group on my computer. This seems to solve the problem after a VS2010 restart and IIS reset.

It would be good if the appropriate team could respond with the minimum set of permissions required for this workaround, as leaving this account as a local administrator is not ideal.

Posted by Microsoft on 5/11/2010 at 3:30 PM

If any one can provide us a sample project and repro steps showing the problem, it can help us to trace the problem down and provide solutions much quicker. You can email me at xinqiu at microsoft dot com to arrange the logistics.

Thank you very much

xinqiu
Web Development Tools

Posted by mbiewer on 5/11/2010 at 11:36 AM

I am experiencing the same problem. Running Vista 64-bit. Visual Studio 2010 Ultimate. Opening .NET 3.5 Web Apps running under IIS. Using Visual SourceSafe 2005 for source control. I have not tried converting them to .NET 4.0. Was initially unable to debug at all. Disabled IntelliTrace debugger and the debugger started working. However, now the IDE will hang after 1 or 2 debugging sessions. Steps are Press F5 to start debugging and the output window shows it Building directory for each of the folders in my App. When it gets to the last folder it just hangs.

Posted by Bastiaan Molsbeck on 5/5/2010 at 7:04 AM

I can reproduce this problem when pressing F5 (Start Debugging) in my solution, but only when all the projects do NOT have to be rebuilt. Visual Studio 2010 goes directly into debugging mode (which is correct), but then my studio hangs...

Posted by KerryKOttawa on 5/4/2010 at 6:22 AM

Update: changed the project back to 4.0 and it now works fine. So perhaps there's a setting/property that's causing the problem when you change back to 3.5.

For now we will work with it in 4.0 but we need to be able to change it back to 3.5 before we release to our clients.

Thanks

Posted by JoelVarty on 5/4/2010 at 6:16 AM

The new workspace provided allowed me to upload the dump file. Now just waiting for a response...

Posted by Microsoft on 5/4/2010 at 2:42 AM

Thanks for reporting the issue.
In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided.

It may help if you provide us with a mini dump file and call stack. You can use the following steps to get a mini dump file:
1. Start Visual Studio.
2. Start another instance of VS.
3. In the second instance click Tools | Attach to Process...
4. In the list of processes locate devenv.exe.
5. Click Select... and explicitly choose 'Native' and 'Managed' code.
6. Click OK and OK to close Select dialog and Attach to Process dialog.
7. Go back to the first instance of VS and repro the crash\hang.
8. Upon the crash\hang, control should go to the second instance of VS.
9. In the second instance click Debug | Save Mini Dump (without heap).

If you are running the VB profile you will not see the Save Dump As menu item. To add this menu item:
a. Select Tools -> Customize
b. Select the Commands tab
c. Select Debug from the “Menu bar” dropdown
d. Click “Add Command…”
e. Select Debug from the Categories list.
f. Find the “Save Dump As” entry in the Commands window.
g. Click OK (the “Save Dump As…” command is added to the top of the Debug menu).
h. Click “Close”

You can get detailed steps about how to get the dump file and call stack at http://blogs.msdn.com/debugger/archive/2009/12/30/what-is-a-dump-and-how-do-i-create-one.aspx

Please copy the Call stack to a txt and compress the [dump file and Call stack txt file] to a zip. Name ()

You can use the following workspace to upload the file:
https://sftasia.one.microsoft.com/ChooseTransfer.aspx?key=f6dc6cf6-e588-4ad1-885a-dfbf13099afc
Password:O{33!aUh{iG2

It would be greatly appreciated if you could provide us with that information as quickly as possible. If we do not hear back from you within 7 days, we will close this issue.

Thanks again for your efforts and we look forward to hearing from you.
Visual Studio Product Team

Posted by Will WM on 5/4/2010 at 1:57 AM

Seeing this issue as well, even after a complete reformat and reinstallation of Windows 7 Enterprise (x86).

More info here:
https://connect.microsoft.com/VisualStudio/feedback/details/556129/vs2010-crashes-on-debug-and-or-doesnt-attach-to-iis-on-debug

Posted by SnowyNomad on 5/3/2010 at 1:26 PM

We can also repro this issue, on several developer boxes. We also converted a solution to 2010 and targeted 4 then changed it back to 3.5. I have a feeling that something that was left from a VS 2008 installation might be causing the problem. Two developers that recently reformatted their boxes have it working.

Posted by KerryKOttawa on 5/3/2010 at 10:29 AM

One note that might be a clue: when we upgraded the solution, VS asked to change the web project only to 4.0 and I said yes, but later went and changed it back to 3.5.

Posted by KerryKOttawa on 5/3/2010 at 10:01 AM

Also having this issue since upgrading to VS2010. I have a dump file but cannot attach it here (times out) & the workspace/password is not working.

Let me know if there is another way to upload the files.

Thanks

Posted by JoelVarty on 5/3/2010 at 6:07 AM

The supplied workspace wouldn't allow me to log in. I have attached the zip file with the call-stack and the dump to this bug.

Posted by Microsoft on 5/3/2010 at 1:50 AM

Thanks for reporting the issue.
In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided.

It may help if you provide us with a mini dump file and call stack. You can use the following steps to get a mini dump file:
1. Start Visual Studio.
2. Start another instance of VS.
3. In the second instance click Tools | Attach to Process...
4. In the list of processes locate devenv.exe.
5. Click Select... and explicitly choose 'Native' and 'Managed' code.
6. Click OK and OK to close Select dialog and Attach to Process dialog.
7. Go back to the first instance of VS and repro the crash\hang.
8. Upon the crash\hang, control should go to the second instance of VS.
9. In the second instance click Debug | Save Mini Dump (without heap).

If you are running the VB profile you will not see the Save Dump As menu item. To add this menu item:
a. Select Tools -> Customize
b. Select the Commands tab
c. Select Debug from the “Menu bar” dropdown
d. Click “Add Command…”
e. Select Debug from the Categories list.
f. Find the “Save Dump As” entry in the Commands window.
g. Click OK (the “Save Dump As…” command is added to the top of the Debug menu).
h. Click “Close”

You can get detailed steps about how to get the dump file and call stack at http://blogs.msdn.com/debugger/archive/2009/12/30/what-is-a-dump-and-how-do-i-create-one.aspx

Please copy the Call stack to a txt and compress the [dump file and Call stack txt file] to a zip. Name (556000.zip)

You can use the following workspace to upload the file:
https://sftasia.one.microsoft.com/choosetransfer.aspx?key=f94877cb-88c5-4e03-90c9-7d40d0e87b48
Password: LU!KGbAgM[UmW

It would be greatly appreciated if you could provide us with that information as quickly as possible. If we do not hear back from you within 7 days, we will close this issue.

Thanks again for your efforts and we look forward to hearing from you.
Visual Studio Product Team

Posted by Microsoft on 5/1/2010 at 4:03 AM

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)

Posted by Peter Mourfield on 5/11/2010 at 11:39 AM

Here's a workaround that helped me:

Go to Debug->Attach to Process. If the 'Attach To' box says 'Automatic: Native code' then click the 'Select...' button. In the 'Select Code Type' dialog change the option from 'Automatically determine the type of code to debug' to 'Debug these code types' and choose ONLY the options for you project. For me this was 'Managed (v2.0, v1.1, v1.0)'. Click OK. Then click Cancel in the 'Attach to Process' dialog.

At this point I'm now able to do F5 Debugging.

I hope this helps!

Posted by M_Brooks on 5/13/2010 at 2:26 AM

This problem seems to be related to IMPERSONATION. That is, when the ASP.NET web application config file contains the IDENTITY element: <identity impersonate="true" userName="MYDOMAIN\DOMAINASPNET" password="********"/>

As a temporary workaround I've added the domain account to the local ADMINISTRATORS group on my computer. This seems to solve the problem after a VS2010 restart and IIS reset.

Posted by Steve Mol on 7/25/2010 at 6:07 AM

I'm not sure if this is my problem, but at least I am experiencing something similar.

I have found that if I select a page without much going on (like maybe just a couple of controls) and press F5, I am much more successful in getting the project to run. Then, once it is running, I switch to the page I am really trying to debug.

Posted by MattOARRT on 9/14/2010 at 12:09 PM

I also believe this may be due to the # of controls on the page. Some sort of race condition? Anyways like Steve Mol if I pick a dummy page without anything on it, it works well, then navigate to the page I really wanted to debug that may have 20 + controls on it and things work that way. Still a huge productivity decline! Help MS!

Posted by MattOARRT on 9/14/2010 at 12:10 PM

Also, I don't have Identity impersonation flags in my web.config file so MattBrooks suggestion does not apply to me.

Posted by kontr0l on 3/31/2011 at 9:26 AM

Had this same issue in Visual Studio 2008 just start happening out of nowhere. VS2008 would hang right after launching the debugger every time and only on one project - all my other projects would debug fine. Spent over 6 hrs trying to figure out what the heck was wrong (reinstalled VS, reinstalled SP1, recreated the solution, recreated the entire project, cleaned out temp files, etc). None of the workarounds above worked or applied to my project either.

Finally out of desperation I simply moved the project to a new directory and it started working! Have no idea why and am skeptical as to how permanent of a solution it will be but hope this helps someone else...

Posted by Tadeusz on 8/18/2011 at 12:59 PM

The fix provided in this issue did not help me. What did help me was to completly remove the c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\ folder, create it again and add full permissions to System, Administrators, Users, IIS_IUSRS and TrustedInstaller. I don't know if they are all needed - probably not. I also deleted *.suo files and left the fix installed.

VS 2010 - Hangs when debugging ASP.Net 3.5 web application or website by JoelVarty