System.Drawing.Common-8.0.8 upgrade to 9.0.0 crashes my application

[boennhoff]

.NET version

target: net8.0-windows
installed dotnet sdk: 9.0.100, 8.0.404 & 8.0.206 (for whatever reason I have multiple)

Did it work in .NET Framework?

Yes

Did it work in any of the earlier releases of .NET Core or .NET 5+?

not tested

Issue description

Recently I had warnings about vulnerable package references, so I upgraded all possible Microsoft packages and tested my application thoroughly, when I stumbled over a very strange bug:

Running in a debug session, my application opens one of our forms and as soon as I load data the complete Debug session kills itself without any notice. No break on any exception, no log output, the process is just gone, and VS sits there as if no debug session was started.

Steps to reproduce

After a git bisect I determined the root cause: when changing a csproj file from

<ItemGroup>
  [..]
  <PackageReference Include="System.Drawing.Common" Version="8.0.8" />
  [..]
</ItemGroup>

to

<ItemGroup>
  [..]
  <PackageReference Include="System.Drawing.Common" Version="9.0.0" />
  [..]
</ItemGroup>

the bug appears. In the same commit I also upgraded many other packages from 8.0.* to 9.0.0, like System.Configuration.ConfigurationManager and System.Management, but only with System.Drawing.Common-9.0.0 this bug happens.

We are using System.Drawing.Common mainly for Image manipulation (Resize, etc.) and Bitmap creation, the UI itself is 3rd-party (managed through COM interops) not Windows.Forms.

I am a bit stuck in finding more information on this, or better describing this issue, I am posting here because the NuGet-package links here. Does anyone have an idea on how to find out more?

My workaround is of course, to not upgrade this package, but this can't be the solution in the long-run...

[lonitra]

@boennhoff are you able to provide a call stack for your crash or repro steps? Having these is necessary for our investigation.

[boennhoff]

@lonitra I will try: can you tell me how to get a Stacktrace and a dump, when the .NET runtime crashes? Can this be done within VS? Am I missing a setting, maybe disable "MyCode only"?

About repro: Since our application is an extension to another application that needs to run, I first need to tackle down the problem to the exact call that leads to the crash for an idea on how to reproduce the bug without the external application.

[Zheng-Li01]

@boennhoff please have a try to refer the https://learn.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2022#BKMK_Create_a_dump_file & https://www.youtube.com/watch?v=JBRKZyf7Db4 to collect the dump file when VS crashed.

[boennhoff]

@Zheng-Li01 thanks, but I did not found an obvious way to create a dump on crash during Debug in VS, so I ran it without debugging and attached ProcDump (-ma -t) to create a dump before termination.

I tried to extract some information from it, but to no avail. Since it's a full dump I can't disclose it publicly; how can I share it with Microsoft (~83MiB zipped)?

What I forgot to mention yet is the exit code/termination cause in the Debug output: 0x0..05 Access Violation, it's a simple one-liner

[boennhoff]

I found the culprit, it was a stack overflow in a recursive method in our code. It was triggered by a change in class System.Drawing.Graphics obviously done between 8.0.8 and 9.0.0.

It looks like new/changed internal fields have a type we did not check for yet, passing an object of type Windows.Win32.Graphics.GdiPlus.GpGraphics* was one of the baddies...

The fix was applied to this redacted piece of code:

private void RecursiveMethod(object obj) {
  // collect object info or continue below...
  ...

  // dive into object fields
  var fields = obj.GetType().GetFields(BindingFlags.NonPublic | BindingFlags.Instance);
  foreach (var field in fields) {
    var fieldObject = field.GetValue(obj);
    if (fieldObject != null
        && !field.IsStatic
        && field.FieldType != typeof(IntPtr)
        && field.FieldType != typeof(Pointer)
        && field.FieldType != typeof(void*)  // <-- this line fixed it!
        && field.FieldType != typeof(void)) {
      RecursiveMethod(fieldObject);
    }
  }
}

I also implemented another check for a maximum depth to circumvent such a problem in the future. The method itself feels hacky, and I actually dislike it, but we found no other way around yet.

Either way, shouldn't the reaction of VS be different with problems like this? An Access Violation should not the be the outcome, or should it? Shall I leave this issue open for further analysis (*.dmp upload?) or close it?