This will disable system cores - are there any places where we hook up the runtimes coredump features like we do for the coreclr style tests? I am not aware of any, and they shouldn't be as bad in terms of size. Those could let us still get dumps reasonably.

I did not find that for libraries tests.

I did query for dump uploads from runtime/non-libraries tests which I believe use createdump and they still look in the 6 GB range?

WorkItems
| where QueueName startswith "osx.1200.amd64"
| where Started > ago(10d)
| join (Files | where FileName startswith "core" ) on WorkItemId
| join kind=inner Jobs on JobId
| project
  Queued,
  WorkItemFriendlyName, ExitCode, QueueName,
  PhaseName = tostring(parse_json(Properties)["System.PhaseName"]),
  Pipeline = tostring(parse_json(Properties).DefinitionName),
  FileName,
  SizeBytesLong,
  Source,
  Build = tostring(parse_json(Properties).BuildNumber)
| where Pipeline == "runtime"
| where PhaseName !startswith("libraries")
| order by Queued desc

There's two things: we should remove this https://github.com/dotnet/runtime/blob/512a9ffcb8aa99ffc25fac76dc0c431543e45ba9/src/tests/Common/Coreclr.TestWrapper/CoreclrTestWrapperLib.cs#L223 and yeah, we are using --with-heap. That's pretty much grab everything in the managed process. It gives us the best results, but if the size is too large maybe we should consider dropping to --normal or --triage to at least get stacks.

It would be great if the libraries tests could automatically wrap in coredump. I can't remember ever needing a dump from any process other than the test process (or possibly a child). So we could leave system dumps off at that point.

Also update here and set DbgMiniDumpType, I expect:

Filed #65422