BinSkim crashes with out of memory exception on empty _.pdb files

[andriipatsula]

x64 Binskim:

D:\a_work\1\s.gdn\i\nuget\Microsoft.CodeAnalysis.BinSkim.1.9.5\tools\netcoreapp3.1\win-x64\BinSkim.exe

Pool name: NetCore1ESPool-Internal with 16 GB of memory for agents.
The artifacts in the Runtime repository have a size of approximately 4.7 GB (link)

Logs: https://dev.azure.com/dnceng/internal/_build/results?buildId=2211960&view=logs&j=5670356f-8b38-5a32-2003-b78bdacf9625&t=3eba09b0-9fb8-5e1f-ce0b-b3d4e55cfb20&l=8555

[Error] Insufficient memory to continue the execution of the program.
[Error] Fatal error. Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
[Error] System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

For some reason dotnet/runtime's artifacts include empty _.pdb files. The issue is already reported on the Binskim side
Issue in the Runtime repo: dotnet/runtime#89423

[tkapin]

Please make sure that the conclusion is correct, ideally by checking with the tool documentation or authors. If the tool uses extensive memory to scan large number of binaries, it's most probably a bug or an incorrect implementation (e.g., reading all binaries at once). This should be definitely at least reported to the tool authors.

For the Validate SDL on $(repoName)-$(commit) job we need to switch to NetCore1ESPool-Internal-XL pool which has machines with 32 GB of memory."

[andriipatsula]

Linked BinSkim issues:

microsoft/binskim#924

Out of memory exception occurs while inspecting certain binaries during BA2004.EnableSecureSourceCodeHashing rule

microsoft/binskim#881

BinSkim crashes (AccessViolationException) loading Xamarin.Mac.pdb

[andriipatsula]

Example of PDB that causes the issue: runtime.linux-arm.Microsoft.NETCore.ILDAsm.7.0.9-servicing.23320.18.symbols\runtimes\linux-arm\native\_.pdb

[andriipatsula]

The workaround was merged, and changes were flown to the dotnet/runtime repository.