Skip to main content

Don't "Attach to Process" from a second Visual Studio window

Just don't.

I just spent the last few hours debugging an extremely irritating issue with Visual Studio and attempting to attach to my local IIS.

First, some context: I use Visual Studio as two windows to make the most use out of two monitors. I have the main VS window, the one with the menu bar and all the buttons, open full screen on the left monitor with a few code tabs in it. On the right/primary monitor, I have a code tab pool window, that I pulled out from the main VS window, set full screen with the solution explorer and a few other tool windows anchored to the side.

Back to the story. Late yesterday afternoon, while debugging some things on a site running on my local IIS, I noticed that my Visual Studio seemed to lock up when I went to attach to the W3WP.exe process. It's happened once or twice before, so I force closed VS and tried it again. It worked the next time, so I continued my work and ignored the anomaly for the time being. towards the end of the day, it happened twice more in a row, and since it was already past time to head home for the day, I decided to leave it overnight and see if it was just a slowness issue. If so, I could debug it in the morning and find a way around it.

Next morning, my VS is still attempting to connect to IIS. I didn't really expect it to succeed over night, but I expected at least some sort of window complaining that the IIS process was no longer available or something. I killed VS one more time and attempted it again. Same thing, dead locked. I pulled open the Task Manager and ran the "Analyze Wait Chain" option from the context menu and it said that my devenv.exe was currently stuck waiting on Network I/O. So I decided to disable my network adapter and try it again. That way, any network request would fail and it would hopefully attach right away. I'm not sure why it would be attempting any network requests while attaching to a process, but it seemed like something to try.

I opened the Network and Sharing Center from the little notification pool, went to the adapter settings, disabled it, and then left that screen open while I went to the other Visual Studio window to attempt attaching again,, selecting the process to attach to, acknowledging I selected the right one, OK, OK, OK, just let me attach. This time, it worked without a problem. Queue the confused frustration. I killed the debugging,  re-enabled the adapter, went back to Visual Studio, and attempted to attach again. Nope. Frozen again. I repeated this at least half a dozen more times, same result every time.

Did you spot the problem? I'll give you a hint: New windows typically open on the primary monitor.

As part of my testing, I fell victim to the red herring of the Wait Chain Analysis. I believed Windows when it said the network IO is what was causing Visual Studio to hang. And my testing seemed to back that up. Disabling the adapter allowed it to connect, re-enabling it caused it to lock up again. I had no idea what caused that to happen, or even how or why they would be related, but all my testing seemed to validate that theory.

I started gathering some logs and decided to close out my secondary Visual Studio window so I could keep track of everything I had open better. This time, every test succeeded, network adapter or not. I noticed two things that ultimately helped me figure it out: the "are you sure" dialog never came open when the attach attempt failed, and the secondary window would reload in order to add in the debugging tool frames into the window.

Using these two observations, I had a crazy thought: What if the secondary window reload is loading over the dialog? If seemed insane that that would happen, or that that could even still be an issue in modern applications, so I tested. I left the network adapter enabled and attempted to attach while the main VS window was active. Success. Next, I resized the secondary VS window to be very small and tried it again. No "are you sure" dialog, and the lockup still happened. Somehow, the secondary window must be causing the issue.

I next tested several combinations of opening windows, minimizing, closing, attaching, detaching, rebooting, updating, etc, etc. In the end, it seems that a secondary Visual Studio window does not play nice with dialogs. Every time I initiates the attach from the main VS window, it would connected without a problem. No matter what I did when attempting to initiate an attach from a secondary VS window, it would always lock up.

I have no idea why this is a thing, why Visual Studio can't properly handle two windows being open, or why dialogs still break things in such interesting and imaginative ways.

It's frustrating. It's confusing. It shouldn't have happened. In the future, if you ever need to attach to a process from Visual Studio, save yourself this headache and double check that you have the main VS window active.


Popular posts from this blog

Happy Holidays, Catching up before the New Year, and Family Visits

So, I'm a few posts behind. I hope you'll all forgive me for taking some time off to spend with family and friends throughout the holiday season. After my last post on the way down to South Carolina to visit my parents, brother, and as many friends as I could, I have been quite busy. First, I brought my mom back up to Maryland with us to visit for a couple weeks following Thanksgiving. We had a good time and she very much enjoyed her stay. The trip to Union Station so she could catch her train taking her back was a little sad, but surprisingly Union Station is a seriously awesome Metro/Amtrak/Marc station. It felt very much like a mall or a large airport. There were three levels with food, shopping, souvenir shops, and more. It was quite something else. Not to mention it was decked out in lights for the holidays so it looked even more amazing. So, to catch everyone up on what's been going on, what is going on, and what will be going on: Since the last post, I am now g

Let's get this started

If you can read this then I guess I've set up the DNS records and account settings correctly. This first post comes to you, as I'm sure many of them will, from my Android device. I hope to use this blog to help with keeping my myriad projects I have in line as well as to keep track of ideas for new projects I'd like to take on once I have some additional room on my plate. I'll keep this short so it doesn't burn through your attention span (and mine). ;p I like to build things, be them digital or physical. I like to consider myself on the path to becoming a great code ninja. Although I have been trained in the coding arts, as with any great skill, it takes time, effort, and much, much practice to hone those abilities. From time to time I'll take on a project that involves creating something tangible. Those projects are a little more varied than my digital ones. My current list contains items as strange as building a kayak and a couch. I'll wrap up thi

Helpouts, Meetups, and the Mirror-Quickstart

Earlier this week I had my introductory interview with the Helpouts crew to verify the skills that I claim to have and to get an overall feel for how the system works and what to expect from a Helpout. I think the system will be very useful and I look forward to both providing Helpouts and utilizing them to learn new things. I asked if Helpouts would be able to utilize Glass, and at current it does not, but Helpouts hasn't launched yet, so anything can change. I received confirmation that my Helpouts listing has been approved yesterday and that it will be one of the first available when Helpouts goes live. They also said that they would be sending me a few invitation codes for friends and family to practice prior to the launch date, so if any one is interested in helping me practice or if you need any Tech assistance, let me know. Thursday I attended a meetup co-hosted by  +Antonio Zugaldia  of Silica Labs and  +GDG Washington DC . It was informative and interesting. Antonio c