You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 8, 2019. It is now read-only.
If your Visual Studio has this extension installed/enabled and you are debugging an experimental Visual Studio instance (because you are developing an extension) then hitting a breakpoint in the debuggee (in the experimental instance) causes the debugger (your Visual Studio) to hang.
Possible cause
I haven't investigated the problem but the root cause is very likely to be the following:
This extension periodically discovers all Visual Studio instances running on the machine and queries info about them via COM in the VSWindowTitleChanger.PackageGlobals.GetVSMultiInstanceInfo() function. This happens in order to provide the multiple_instances and multiple_instances_same_ver variables for the expression evaluator.
When another instance is blocked (e.g.: a debugged experimental instance) then the title changer extension in our main debugger Visual Studio blocks/hangs on querying info about the debugged/breakpointed experimental instance.
Bug Reports
This "bug" has been reported by several people. E.g.:
Reported by stavn:
I get a hanging VS 2015 if I try to debug a VS extension when this extension is enabled.
Steps to repro:
Prerequisite: Visual Studio Extensibility tools installed (you can do that in a later step)
Start VS (referred to as the debugger instance)
Create a new VSIX Project from the C# template
Add a new Custom Command from C# template
Run the project
An experimental debugee VS instance will start
In debugee instance choose Tools|Invoke Command1
-> The debugee instance crashes, and the debugger instance appear frozen until the debugee instance is killed.
Disabling this extension removes the problem
If you have trouble reproducing this I will happily provide you with more info.
Reported by Tom Montgomery:
This is a great extension as I have many projects open that have the same solution name, and this really helps me keep track.
However, I have one problem that has taken quite a bit of tracking down, and it seems to be caused by this extension. If I'm debugging my own extension, and a breakpoint is hit, then both my working VS and the experimental VS hang. The only way out is for me to kill the experimental VS from task manager.
I sometimes get this dialog "Microsoft Visual Studio is waiting for a response from 'experimental instance'. This may be because 'experimental instance' is busy and unable to respond at this time."
If you do get time to work on the extension again, could you try and see if this issue is fixable? It'd be much appreciated.
The text was updated successfully, but these errors were encountered:
Symptom
If your Visual Studio has this extension installed/enabled and you are debugging an experimental Visual Studio instance (because you are developing an extension) then hitting a breakpoint in the debuggee (in the experimental instance) causes the debugger (your Visual Studio) to hang.
Possible cause
I haven't investigated the problem but the root cause is very likely to be the following:
This extension periodically discovers all Visual Studio instances running on the machine and queries info about them via COM in the
VSWindowTitleChanger.PackageGlobals.GetVSMultiInstanceInfo()
function. This happens in order to provide themultiple_instances
andmultiple_instances_same_ver
variables for the expression evaluator.When another instance is blocked (e.g.: a debugged experimental instance) then the title changer extension in our main debugger Visual Studio blocks/hangs on querying info about the debugged/breakpointed experimental instance.
Bug Reports
This "bug" has been reported by several people. E.g.:
Reported by stavn:
Reported by Tom Montgomery:
The text was updated successfully, but these errors were encountered: