This issue has a corresponding ticket on Developer Community. Please vote and comment there to make sure your voice is heard.
[regression] [worked-in:16.4.6]
I have a project that has a global.json file in the root indicating that version 3.1.100 of the .NET Core SDK should be used. A compatible version of that SDK comes with VS 16.4.0. After upgrading VS to 16.5.0 and attempting to open my project, the IDE hangs indefinately. After some trial and error, dotnet --list-sdks revealed that no compatible .NET Core SDK was installed for 3.1.1xx. After installing .NET Core SDK 3.1.101, VS 16.5.0 opened the project successfully. This is likely because my machine was using the VS specific version of that SDK and it got upgraded, which I understand.
The issue is that the IDE hangs when opening the project. It would be great if an error indicating the issue could be displayed. A bonus would be to pop the installer to install the missing SDK.
Original Comments
Roi Chen [MSFT] on 3/18/2020, 10:21 PM:
Thank you for taking the time to log this issue!
I’ve tried to reproduce and investigate using the description, and attachments already provided. Unfortunately those aren’t enough and more information is needed in order to investigate it further.
The easiest way to provide all the information is to use the Visual Studio Feedback Tool. This will ensure that we collect the needed information for you without worrying about what to provide (recording, dump file or ETL trace).
Since this issue is now marked as Need More Info, that workflow is enabled in the Feedback Tool:
• Open Visual Studio Feedback tool.
• Click the banner letting you know that you have problems requesting your attention.
• Click this problem from the list
• Click “View their request and respond” from the problem details banner
• Add a comment, in the Attachments/Record: click Start Recording
• When the Steps Recorder tool appears, perform the steps that reproduce the problem.
• When you’re done, choose the Stop Record button.
• Wait a few minutes for Visual Studio to collect and package the information that you recorded.
• Submit. You will be able to see the comment on Developer Community. For security reasons, your files come directly to us and don’t appear on Developer Community.
For the full instructions, please see: https://docs.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio-2017?view=vs-2017#when-further-information-is-needed-need-more-info . For information about what data is collected, see https://docs.microsoft.com/en-us/visualstudio/ide/developer-community-privacy?view=vs-2017#data-we-collect
Get performance issues fixed quicker, please see https://docs.microsoft.com/en-us/visualstudio/ide/how-to-increase-chances-of-performance-issue-being-fixed?view=vs-2019.
We look forward to hearing from you!
Craig Treasure (ANALOG) [MSFT] on 4/6/2020, 09:17 AM:
Adding repro recording.
Visual Studio Feedback System on 3/31/2020, 06:28 PM:
We will close this report in 14 days because we don’t have enough information to investigate further. To keep the problem open, please provide the requested details.
Visual Studio Feedback System on 4/9/2020, 02:54 AM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
Yuanyuan Dong [MSFT] on 4/9/2020, 03:50 AM:
Dear Craig,
Thank you for your information! For us to investigate this further, could you please provide a dump file?
You are able to get the dump file with the following steps:
1.Start the 32-bit task manager (C:\Windows\SysWOW64\Taskmgr.exe).
2. Repro the issue, and wait about 10 seconds
3. Right click on devenv.exe, and press “Create dump file”. Then please attach this file.
We look forward to hearing from you!
Craig Treasure (ANALOG) [MSFT] on 4/9/2020, 09:57 AM:
I've attached the requested dump file.
Visual Studio Feedback System on 4/10/2020, 04:23 AM:
Thanks a lot to report the issue. Because our team didn't reproduce this issue directly, it would be critical to use the dump file to find out the what happened. Unfortunately, the earlier dump file was a 64bit process dump, which doesn't work with WinDBG SOS commands. I reviewed the instruction from Yuanyuan earlier, which is mostly correct. However, one key thing missing is that if you have task manager opened, executing the WOW version of the taskmgr will reuse the window, and still left you to use 64bit task manager. The instruction works with people don't use task manager much, but I believe it hits the problem on you. The better way is to run WOW taskmgr once, and close the window, and rerun it to ensure you get the 32bit one. After that, you can create dump file with the task manager.
If you can help to capture a new dump, it will be very helpful for us to find out what happened. Sorry for the gap in the original instruction.
Thanks
Craig Treasure (ANALOG) [MSFT] on 4/28/2020, 08:42 AM:
Sure. Can we get the item back in a state where I can submit diagnostics again?
Craig Treasure (ANALOG) [MSFT] on 5/11/2020, 09:22 AM:
This issue has a corresponding ticket on Developer Community. Please vote and comment there to make sure your voice is heard.
[regression] [worked-in:16.4.6] I have a project that has a
global.json
file in the root indicating that version3.1.100
of the .NET Core SDK should be used. A compatible version of that SDK comes with VS 16.4.0. After upgrading VS to 16.5.0 and attempting to open my project, the IDE hangs indefinately. After some trial and error,dotnet --list-sdks
revealed that no compatible .NET Core SDK was installed for 3.1.1xx. After installing .NET Core SDK 3.1.101, VS 16.5.0 opened the project successfully. This is likely because my machine was using the VS specific version of that SDK and it got upgraded, which I understand.The issue is that the IDE hangs when opening the project. It would be great if an error indicating the issue could be displayed. A bonus would be to pop the installer to install the missing SDK.
Original Comments
Roi Chen [MSFT] on 3/18/2020, 10:21 PM:
Thank you for taking the time to log this issue!
I’ve tried to reproduce and investigate using the description, and attachments already provided. Unfortunately those aren’t enough and more information is needed in order to investigate it further.
The easiest way to provide all the information is to use the Visual Studio Feedback Tool. This will ensure that we collect the needed information for you without worrying about what to provide (recording, dump file or ETL trace).
Since this issue is now marked as Need More Info, that workflow is enabled in the Feedback Tool:
• Open Visual Studio Feedback tool.
• Click the banner letting you know that you have problems requesting your attention.
• Click this problem from the list
• Click “View their request and respond” from the problem details banner
• Add a comment, in the Attachments/Record: click Start Recording
• When the Steps Recorder tool appears, perform the steps that reproduce the problem.
• When you’re done, choose the Stop Record button.
• Wait a few minutes for Visual Studio to collect and package the information that you recorded.
• Submit. You will be able to see the comment on Developer Community. For security reasons, your files come directly to us and don’t appear on Developer Community.
For the full instructions, please see: https://docs.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio-2017?view=vs-2017#when-further-information-is-needed-need-more-info . For information about what data is collected, see https://docs.microsoft.com/en-us/visualstudio/ide/developer-community-privacy?view=vs-2017#data-we-collect
Get performance issues fixed quicker, please see https://docs.microsoft.com/en-us/visualstudio/ide/how-to-increase-chances-of-performance-issue-being-fixed?view=vs-2019.
We look forward to hearing from you!
Craig Treasure (ANALOG) [MSFT] on 4/6/2020, 09:17 AM:
Adding repro recording.
Visual Studio Feedback System on 3/31/2020, 06:28 PM:
We will close this report in 14 days because we don’t have enough information to investigate further. To keep the problem open, please provide the requested details.
Visual Studio Feedback System on 4/9/2020, 02:54 AM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
Yuanyuan Dong [MSFT] on 4/9/2020, 03:50 AM:
Dear Craig,
Thank you for your information! For us to investigate this further, could you please provide a dump file?
You are able to get the dump file with the following steps:
1.Start the 32-bit task manager (C:\Windows\SysWOW64\Taskmgr.exe).
2. Repro the issue, and wait about 10 seconds
3. Right click on devenv.exe, and press “Create dump file”. Then please attach this file.
We look forward to hearing from you!
Craig Treasure (ANALOG) [MSFT] on 4/9/2020, 09:57 AM:
I've attached the requested dump file.
Visual Studio Feedback System on 4/10/2020, 04:23 AM:
Thank you for sharing your feedback! Our teams prioritize action on product issues with broad customer impact. See details at: https://docs.microsoft.com/en-us/visualstudio/ide/report-a-problem?view=vs-2019#faq. In case you need answers to common questions or need assisted support, be sure to use https://visualstudio.microsoft.com/vs/support/. We’ll keep you posted on any updates to this feedback.
Lifeng Lu [MSFT] on 4/10/2020, 05:17 PM:
Hey, Craig,
Thanks a lot to report the issue. Because our team didn't reproduce this issue directly, it would be critical to use the dump file to find out the what happened. Unfortunately, the earlier dump file was a 64bit process dump, which doesn't work with WinDBG SOS commands. I reviewed the instruction from Yuanyuan earlier, which is mostly correct. However, one key thing missing is that if you have task manager opened, executing the WOW version of the taskmgr will reuse the window, and still left you to use 64bit task manager. The instruction works with people don't use task manager much, but I believe it hits the problem on you. The better way is to run WOW taskmgr once, and close the window, and rerun it to ensure you get the 32bit one. After that, you can create dump file with the task manager.
If you can help to capture a new dump, it will be very helpful for us to find out what happened. Sorry for the gap in the original instruction.
Thanks
Craig Treasure (ANALOG) [MSFT] on 4/28/2020, 08:42 AM:
Sure. Can we get the item back in a state where I can submit diagnostics again?
Craig Treasure (ANALOG) [MSFT] on 5/11/2020, 09:22 AM:
(private comment, text removed)
Original Solutions
(no solutions)