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.

Comments

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

Getting Fit, Glass and Relax, and Hacking Habits

A few weeks back  +Noble Ackerson  recommended a book that sounded interesting, but I didn't really want to spend the money on it at the time. That book was "The Power of Habit, by Charles Duhigg". Well, I received some Play Store gift card over the last few weeks due to being awesome at work and decided to pick it up. I haven't quite finished it yet, but I can without a doubt say that it will make you look at things in an entirely different way. You'll begin to recognize all the habits that you have and even the habits that your company has. The things that we do every day without knowing and without even questioning. It's astounding. One of the key aspects of the book though is that if you know and understand a habit, you can change it. I've started to utilize what the book details about habits to accomplish a few things that I've realized I want to do. First, I plan on utilizing the habit forming routines to get to the point that I exercise every

Galaxy Nexus Multimedia Dock

First off, I apologize for the delay. I've had some things come up, the least of which being my HDD crashing, and side projects have been pushed back and around a bit lately. Anyway, now on to what  you all came for: The Galaxy Nexus dock mod. Completed Nexus S to Galaxy Nexus modified Dock Nexus S Dock box Nexus S dock contents: The dock and a micro USB power supply I started out with a standard, Samsung branded, Nexus S Multimedia Desktop Dock (Model: ECR-D1A3BEGSTA ). Inside this box is the dock itself, which is comfortably heavy so you don't have to worry about it sliding too much, and the power plug, which goes straight from a US wall outlet to a micro USB port, no standard 5V outlet on this one. The first thing you'll notice is that there are no visible screws to remove to aid in its disassembly. This gives the dock a very nice, clean look and, unfortunately, also makes it a bit of a headache to get in to. Not to worry though, if you have a razor