Internal exception: Not enough storage is available to process this command.

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

I have separately reported this problem here: #9175 (comment)

Severity Code Description Project File Line Suppression State
Error FS3160 Problem reading assembly 'D:\Users\John.Zabroski\source\panda\trunk\Source\Company.Resources\bin\Debug\net48\WCompany.Resources.dll': The exception has been reported. This internal exception should now be caught at an error recovery point on the stack. Original message: Error opening binary file 'D:\Users\John.Zabroski\source\panda\trunk\Source\Company.Resources\bin\Debug\net48\Company.Resources.dll': Not enough storage is available to process this command.
) Company.FSharp.Legacy D:\Users\John.Zabroski\source\panda\trunk\Source\Company.FSharp.Legacy\Program.fs 1 Active

Severity Code Description Project File Line Suppression State
Error FS0229 Error opening binary file 'D:\Users\John.Zabroski\source\panda\trunk\Source\Company.Resources\bin\Debug\net48\Company.Resources.dll': Not enough storage is available to process this command. Company.FSharp.. Legacy D:\Users\John.Zabroski\source\panda\trunk\Source\Company.FSharp.Legacy\Test.fs 1 Active

What's interesting to me is Visual Studio 2019 uses 470.6 MB with no solution loaded, and I can see in my Task Manager it is using 1530.1MB after the error occurs some time after the solution is loaded. Problem ALWAYS occurs after compiling code. The error never occurs when editing C# code, only when editing F# code. Philip Carter directed me to file the problem here instead of with F#.

---

Original Comments

Visual Studio Feedback System on 5/13/2020, 09:10 PM:

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.

Visual Studio Feedback System on 6/18/2020, 07:44 PM:

I have detected that for the last 35 days, this issue didn't have much product team activity and a very small amount of new votes or comments. Based on this, its severity, and affected area, it’s my experience that this issue is very unlikely to be fixed.

---

Original Solutions

(no solutions)

[abelbraaksma]

I think this already has an answer here? #9175

[jzabroski]

@abelbraaksma No. It's a loop. @cartermp suggested I open that bug report with Visual Studio, and the Visual Studio team then opened this ticket here.

I commented this morning that I think the issue may in fact be an F# issue that occurs when (transitively?) referencing a Resources assembly.

[dsyme]

There is an underlying problem here, but it feels like there's not enough information here to make progress, or even to know the particular kind of memory issue that's at fault. The repro steps we have so far are at #9175 (comment)

Run large F# (FSharpo.Core 4.7.1) and C# mixed use sln via Build Solution, several times, updating code in F# slightly each time. A trivial code update would be to use Resharper Rename refactoring on a C# method, compile, get F# errors due to C# Rename refactoring not peering through to F#, and then manually update those references in F# as well, and recompile. On last recompile, nasal demons emerge.

[dsyme]

@cartermp What should we do with this?

[cartermp]

I don't know why this was duplicated over here by folks, since i did request to have things filed on devcommunity so that diagnostics can be shared. @dsyme there is a dump file and ETL trace here: https://dev.azure.com/devdiv/DevDiv/_search?type=workitem&lp=workitems-Project&text=DeveloperCommunityId%3A1029006&filters=Projects%7BDevDiv%7D&_a=search

Note this comment:

What’s interesting to me is Visual Studio 2019 uses 470.6 MB with no solution loaded, and I can see in my Task Manager it is using 1530.1MB after the error occurs some time after the solution is loaded.

So it's perhaps likely that older VS versions without the big changes we did to rename and find refs could have ballooned memory from 1.5GB to 2.7GB and ultimately caused something to go OOM. But that feels unlikely, unless the F# projects are are larger and contain more code than FSharp.Compiler.Private.dll.

[jzabroski]

@cartermp One of your developers told me that it was a constant string folding optimization implemented naively that causes this issue.

[jzabroski]

@cartermp The comment is here: #8044 (comment)

[cartermp]

The only way to confirm this would be to look at the dump file in the report that was dupe'd to here. It's a reasonable guess though. If it's indeed due to processing resource files and those are read in as a giant string then that would likely do it.

[jzabroski]

Yeah, I admit, it's a conjecture, but I've made a 15+ year career out of being the dude who sees these type of bugs. It's a bizarre skill.

I'm not sure how reliable the dump file is. When I took it, I had a hard time trying to get a dump that "definitely" had the problem. What's strange is it really only happens when I edit a line of F# code. I never run into it when editing C# code in the same project. And developers on the team who never use F# (because they're afraid of it, etc) never have this problem. We also all have identical Visual Studios, configured via the vsconfig file on install.

If this is something you're really serious about solving, I can try to repro it again and submit a new dump, unless @TIHan has already reproduced it. Sadly, we've almost removed all F# from our system as a result of this bug. We just found the whole experience of restarting Visual Studio every 15 minutes to not be worth keeping F#.