Open FlexFitByNat opened 2 months ago
Do you have output from the .NET Install Tool in the .NET Runtime tab on the console? Moving this as it might also have to do with the way the analyzing process is called.
Do you have output from the .NET Install Tool in the .NET Runtime tab on the console?
I have nothing on the .NET Runtime tab on the console. Any suggestions on what I should try?
Please attach our log file(s). Our log files are located alongside VS Code logs. If you want to find them manually, navigate here: Linux: ~/.config/Code/logs Mac: ~/Library/Application Support/Code/logs/ Windows: c:\Users\USER\AppData\Roaming\Code\logs\
Then find the folder created at the time you experienced the bug in the logs folder. From there, go to window1 -> exthost -> ms-dotnettools.vscode-dotnet-runtime. The log file should be located in this folder.
Note: The window folder may change depending on how many VS Code windows you have open; if our extension is running in the 2nd window, it'd be in a folder called window2.
Please attach our log file(s). Our log files are located alongside VS Code logs. If you want to find them manually, navigate here: Linux: ~/.config/Code/logs Mac: ~/Library/Application Support/Code/logs/ Windows: c:\Users\USER\AppData\Roaming\Code\logs\
Then find the folder created at the time you experienced the bug in the logs folder. From there, go to window1 -> exthost -> ms-dotnettools.vscode-dotnet-runtime. The log file should be located in this folder.
Note: The window folder may change depending on how many VS Code windows you have open; if our extension is running in the 2nd window, it'd be in a folder called window2.
Awesome! Here it is! Thank you so much for helping! :)
DotNetAcquisition-ms-dotnettools.vscode-dotnet-runtime-1714400550548.txt
Please attach our log file(s). Our log files are located alongside VS Code logs. If you want to find them manually, navigate here: Linux: ~/.config/Code/logs Mac: ~/Library/Application Support/Code/logs/ Windows: c:\Users\USER\AppData\Roaming\Code\logs\ Then find the folder created at the time you experienced the bug in the logs folder. From there, go to window1 -> exthost -> ms-dotnettools.vscode-dotnet-runtime. The log file should be located in this folder. Note: The window folder may change depending on how many VS Code windows you have open; if our extension is running in the 2nd window, it'd be in a folder called window2.
Awesome! Here it is! Thank you so much for helping! :)
DotNetAcquisition-ms-dotnettools.vscode-dotnet-runtime-1714400550548.txt
FYI: Running on a Mac
Thank you, based on this we have gotten at least somewhere in the initiation phase, but we never got invoked. So VS Code is having trouble activating. It may be the runtime extension, it may not be. If you could share what you saw with the extension bisect pointing to our extension being an issue, thatd be helpful.
For some more info, if you go to help -> toggle developer tools -> console, what is it you see in the console? Be sure to redact any private data.
@FlexFitByNat Thanks for your help, we'd appreciate a bit more info requested below to help you further :) Namely I want to see whats in your console.
every time the extention is loaded visual studio dosent work dotnet/vscode-dotnet-runtime#1773
This is what I see when running the bisect.
Thank you for helping :)
I don't see anything suspect in that unfortunately, but yeah it does appear its our extension, and there is some problem on arm64. I will probably have to try to get a repro.
2 more questions if I may, does this occur for you on version 2.0.2 and 2.0.1? You can install other versions on the extension tab.
Thank you for helping :)
I don't see anything suspect in that unfortunately, but yeah it does appear its our extension, and there is some problem on arm64. I will probably have to try to get a repro.
2 more questions if I may, does this occur for you on version 2.0.2 and 2.0.1? You can install other versions on the extension tab.
I currently have V 2.0.3. Should try other versions?
Yes! I am a bit suspect of something we added in 2.0.2 or 2.0.1. It would be helpful to see if they work for you or not and it might provide a temporary workaround.
Yes! I am a bit suspect of something we added in 2.0.2 or 2.0.1. It would be helpful to see if they work for you or not and it might provide a temporary workaround.
I tried downgrading to v 2.0.2, 2.0.1, 2.0.0 and had no luck! Same thing keeps happening. FYI: I restarted VS Code.
Sorry it's still not working! :( I'll have to try to get a VM to repro it
I appreciate your back and forth with me!
I appreciate your back and forth with me!
Thank you for helping. I hope to hear from you soon!
Type: Bug
When attempting to debug my app in Visual Studio Code using any bedugging platform, the "Analyzing" process gets stuck in an infinite loading loop. This issue occurs frequently but doesn't follow a consistent pattern. Even after attempting various troubleshooting steps, including uninstalling and reinstalling VS Code, the problem persists. Occasionally, restarting the Mac temporarily resolves the issue, but this is not a reliable solution.
Steps to Reproduce:
Open Visual Studio Code. Attempt to debug app. Observe that the "Analyzing" process remains stuck in a loading state indefinitely.
Expected Behavior: The "Analyzing" process should complete successfully, allowing debugging of the app without any interruptions.
Actual Behavior: The "Analyzing" process stays loading indefinitely, preventing successful debugging of the app.
Additionally: Using the Extension Bisect tool helped pinpoint the root cause, revealing that the "ms-dotnettools.vscode-dotnet-runtime" extension is responsible for the error.
Extension version: 2.0.3 VS Code version: Code 1.88.1 (Universal) (e170252f762678dec6ca2cc69aba1570769a5d39, 2024-04-10T17:42:52.765Z) OS version: Darwin arm64 23.4.0 Modes:
System Info
|Item|Value| |---|---| |CPUs|Apple M1 Pro (10 x 24)| |GPU Status|2d_canvas: enabledcanvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
video_decode: enabled
video_encode: enabled
webgl: enabled
webgl2: enabled
webgpu: enabled| |Load (avg)|1, 2, 2| |Memory (System)|16.00GB (0.34GB free)| |Process Argv|--crash-reporter-id 6d97e4a6-e46f-4d57-8734-27ca6a366866| |Screen Reader|no| |VM|0%|
A/B Experiments
``` vsliv368:30146709 vspor879:30202332 vspor708:30202333 vspor363:30204092 vswsl492cf:30256860 vscod805cf:30301675 binariesv615:30325510 vsaa593:30376534 py29gd2263:31024239 c4g48928:30535728 azure-dev_surveyone:30548225 2i9eh265:30646982 962ge761:30959799 pythongtdpath:30769146 welcomedialogc:30910334 pythonidxpt:30866567 pythonnoceb:30805159 asynctok:30898717 pythontestfixt:30902429 pythonregdiag2:30936856 pyreplss1:30897532 pythonmypyd1:30879173 pythoncet0:30885854 2e7ec940:31000449 pythontbext0:30879054 accentitlementsc:30995553 dsvsc016:30899300 dsvsc017:30899301 dsvsc018:30899302 cppperfnew:31000557 d34g3935:30971562 fegfb526:30981948 bg6jg535:30979843 ccp2r3:30993541 dsvsc020:30976470 pythonait:31006305 gee8j676:31009558 showvideoc:31016891 chatpanelt:31018789 dsvsc021:30996838 724cj586:31013169 pythoncenvpt:31022790 ```