1

Since the update before last to AWS Toolkit, when running Visual Studio 2022 with AWS Toolkit installed and enabled, the entire PC grinds to crawl.

Specifically, physical memory use shoots up to 99%, there's a huge amount of continuous disk activity and CPU use rises to around 50%. This renders the entire system completely unusable (think, two minute delay between clicking and something happening). Oddly, nothing appears in the process list in Task Manager that accounts for either the levels of memory or CPU use. It feels like a monumental memory leak but really I've no idea what's going on.

I've tried completely uninstalling and reinstalling VS and uninstalling, deleting the AWS Toolkit folder in "Users...etc." and reinstalling the Toolkit. Everything is fully up-to-date.

As I say, this has happened since the update before last. It's strange that it isn't mentioned anywhere that I can find on the internet and it's difficult to imagine that such a serious issue would only happen to me.

So, has this happened to anyone else and does anyone have a fix? I wanted to raise a support case on AWS Console but I only have a basic account so am unable to do so.

Chris Christou
  • 88
  • 2
Robot Head
  • 396
  • 3
  • 16
  • 1
    Hey! Have you verified that downgrading fixes the issue? If so, please log a [Github issue](https://github.com/aws/aws-toolkit-visual-studio/issues) and meanwhile, I'd recommend using the `dotnet aws deploy` CLI command to minimise as much disruption as possible to your workflow – Ermiya Eskandary Dec 20 '22 at 17:19
  • Good question. I haven't tried downgrading as there's no way to do it via the extension browser. After a bit of digging, however, I've discovered that you can manually change the version number in the download link here [link](https://marketplace.visualstudio.com/items?itemName=AmazonWebServices.AWSToolkitforVisualStudio2022) and you get that version. I'll try it later and see what happens. – Robot Head Dec 20 '22 at 17:55
  • No worries; the more information the better for the devs to debug as if it was really widespread, I'd expect to see a couple of Github issues.... Also, take a wander in `%localappdata%\AWSToolkit\logs\visualstudio` as well and see if you can find anything useful – Ermiya Eskandary Dec 20 '22 at 17:57
  • Okay, I've tried downgrading from 1.38 to 1.36 and for good measure 1.35. I get the same problem. I've also tried opening a few different projects and found that it only happens with AWS projects open. It doesn't happen with, say, a WinForms project. Also, once I've killed the devenv.exe task the system only partially recovers. It oesn't seem to fully recover until I kill MSBuild.exe (which I'm not even sure should be running at all if all I've done is open a project). Something very screwy's going on here. I've tried deleting the bin/obj folders and reopening a project - makes no difference. – Robot Head Dec 21 '22 at 10:31
  • 1
    On a whim I just tried deleting the .vs folder and, although it went mental for a minute after opening a project, it settled down and it seems okay now. !?!? Edit: I suspect actually it was the "[project name]\v17" folder inside the .vs folder that was the culprit, which would explain why the problem happened with the AWS Toolkit extension enabled (v17 seems to be some internal name for it or something (e.g. the VSIX package is called "AWSToolkitPackage.v17.vsix"). I don't really understand it though. – Robot Head Dec 21 '22 at 10:43
  • Might have been a cache issue - glad you got it sorted1 – Ermiya Eskandary Dec 21 '22 at 12:10
  • I spoke too soon I'm afraid. I just tried to publish a project and had to hit the reset button after half an hour. Now it's back to how it was. From trying to kill various tasks it seems like something's up with MSBuild, but how it interacts with AWS Toolkit I don't understand. I'm going to pick through the drive and delete anything AWS-related and anything MSBuild cache-y. – Robot Head Dec 21 '22 at 18:35
  • Just this project or all others? What version of .NET? I’ve known deploys to stall because of packages before so keen to know your file structure. – Ermiya Eskandary Dec 21 '22 at 19:47
  • Any AWS Lambda project. Some use .NET Core 3.1, some .NET 6. I get the same issue in both cases. They are relatively simple projects with just one .cs file and a few NuGet packages including those necessary to work with AWS. This is driving me up the wall! I've deleted a tonne of crap from the c drive and apart from freeing up a dozen gig on my precious SSD it hasn't helped. Additionally, VS now crashes every time I open a project, but works on the second try. I'm giving up for today and having my dinner. I'm going to submit an issue on the extension via Git Hub tomorrow. – Robot Head Dec 21 '22 at 20:11
  • 1
    I've finally got around to posting a bug on Github: [link](https://github.com/aws/aws-toolkit-visual-studio/issues/314) – Robot Head Jan 17 '23 at 19:45

1 Answers1

1

This issue has been resolved (see https://github.com/aws/aws-toolkit-visual-studio/issues/314#issuecomment-1401060605 for more details).

The system in question is running Windows 7. At some point .NET 7 was installed onto it (possibly as a result of a Visual Studio update). .NET 7 does not support Windows 7, and dotnet publish commands started to produce internal errors, and is taking a long time to complete. The AWS Toolkit's Lambda publishing features are built on top of the dotnet CLI commands, which is how the degradation was noticed.

This can be mitigated by installing an older version of .NET (like .NET 6) and telling the dotnet tooling to use a specific version of .NET instead of the latest detected version.

From https://learn.microsoft.com/en-us/dotnet/core/tools/global-json:

The global.json file allows you to define which .NET SDK version is used when you run .NET CLI commands. Selecting the .NET SDK version is independent from specifying the runtime version a project targets. The .NET SDK version indicates which version of the .NET CLI is used.

Add a global.json file to the same folder as your project or solution with the contents shown below, referring to the .NET SDK version you want to use (the example below uses 6.0.300)

{
  "sdk": {
    "version": "6.0.300"
  }
}
Chris Christou
  • 88
  • 2