Juan Hoyos

I'm actively investigating a product issue where dumps are not getting collected.

https://dev.azure.com/dnceng-public/public/_build/results?buildId=598100&view=ms.vss-test-web.build-test-results-tab&runId=14495740&resultId=215086&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab @kunalspathak that's from yesterday, the dump sadly didn't get egressed. The method that failed was `Microsoft.CodeAnalysis.CSharp.Syntax.InternalSyntax.Lexer.AddTrivia(Microsoft.CodeAnalysis.CSharp.Syntax.InternalSyntax.CSharpSyntaxNode, Microsoft.CodeAnalysis.Syntax.InternalSyntax.SyntaxListBuilder ByRef)` at IL offset `0x1d`

@missymessa probably this shouldn't be in the "other teams" bucket. This will be a general infra requirement.

I have been thinking about this - but I am not sure dumps uploaded as artifacts is a good idea in internal builds. Those machines are filled with secrets and...

Secrets are usually env settings that get loaded in the msbuild processes that crash. binlogs now get scrubbed - I am hesitant given the history of dumps and secrets.

Also, is this an x64 dump in an Apple silicon host? If so, there's been lldb hosting issues lately in said platform.

@Leonardo-Ferreira In the insights tab or using perfview or WinDBG + SOS you should check what your fragmentation looks like. Also, what does checking the "show dead objects" checkbox show?

You can open that dump in WinDBG on windows - no need to install within the container. You may need a copy of the binaries/pdbs for some metadata/commands. Alternatively dotnet-dump...

`!heap` might not work. But what does `!dumpheap -stat` tell you?

Also, I'd collect a Full dump - in case this is native memory somewhere.