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.
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
Post a Comment