SkiaSharp icon indicating copy to clipboard operation
SkiaSharp copied to clipboard

[BUG] Windows App Crash - only on x86 - v3.116 or newer

Open viktorspacil opened this issue 3 months ago • 1 comments

Description

Hi, we delop multiplatform (Windows, macOS) dotnet (9.0) application using Avalonia UI (11.3.6) which loads some DLLs in runtime from subdirectory. One of this DLL use SkiaSharp lib (3.116 or newer) for some image manupulation. When the application is compiled for x64 then everything is ok but when we compile the application for x86 then we are getting app crash (no event log, no dump). In case of x84, when we copy the DLLs from subdirectory to application root directory then the app crash is gone. When we rollback the SkiaSharp nuget to version 2.88.9 then DLLs loading from subdirectory also work as expected (x64, x86). Any ideas?

Code

No repro

Expected Behavior

No app crash

Actual Behavior

App crash

Version of SkiaSharp

3.116.0 (Current)

Last Known Good Version of SkiaSharp

2.88.9 (Previous)

IDE / Editor

Visual Studio (Windows)

Platform / Operating System

Windows

Platform / Operating System Version

Microsoft Windows 11 Pro (ARM CPU), 23H2 (build 22631)

Devices

No response

Relevant Screenshots

No response

Relevant Log Output


Code of Conduct

  • [x] I agree to follow this project's Code of Conduct

viktorspacil avatar Sep 25 '25 20:09 viktorspacil

Triage Summary

Labels will be applied to indicate that the issue involves the SkiaSharp area and relates to reliability on a Windows-Classic platform due to a crash in a .NET application compiled for x86.

This issue is not explicitly mentioned as a regression but indicates unexpected behavior and reliability concerns.

Additional remarks:

  • The issue specifically deals with a crash in a multiplatform .NET application utilizing SkiaSharp for image manipulation, but the labels do not cover backends directly related to Windows x86.
Detailed Summary and Actions

Summary of the triage:

  • The issue pertains to a crash in a .NET application using SkiaSharp on Windows when compiled for x86.
  • It involves a change in behavior linked to different versions of the SkiaSharp library.
  • The problem arises in a Windows x86 environment, which is associated with reliability issues.

Summary of the actions that will be performed:

Action Item Description
Apply Label area/SkiaSharp The issue involves a crash when using SkiaSharp in a .NET application on Windows x86, specifically referencing behavior changes.
Apply Label tenet/reliability The issue describes an application crash in a Windows x86 environment, highlighting reliability problems.
Apply Label os/Windows-Classic The issue pertains to a bug occurring in a classic Windows environment utilizing Win32 APIs, indicating the specific OS context.

This entire triage process was automated by AI and mistakes may have been made. Please let us know so we can continue to improve.

github-actions[bot] avatar Sep 25 '25 20:09 github-actions[bot]

I'm facing the exact same issue. I build my library for netstandard2.0 so I can use it in a legacy net472 solution, as well as in a newer Net8.0 (currently only Windows) based solution.

  • x86 + net472: working
  • x64 + net472: working
  • x86 + Net8.0: ISSUE
  • x64 + Net8.0: working

The process (here my unit tests) is terminated with following exception:

`powershell.exe : The active test run was aborted. Reason: Test host process crashed : Stack overflow. At [...].ps1:3 char:1

  • & powershell -NoProfile -NonInteractive -ExecutionPolicy Bypass -Comm ...
  •   + CategoryInfo          : NotSpecified: (The active test...Stack overflow.    :String) [], RemoteException
      + FullyQualifiedErrorId : NativeCommandError
    
     at SkiaSharp.SkiaApi.sk_bitmap_get_pixel_color(IntPtr, Int32, Int32)
     [...]
     at System.RuntimeMethodHandle.InvokeMethod(System.Object, Void**, System.Signature, Boolean)
     at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(System.Object, IntPtr*)
     at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(System.Object, System.Reflection.BindingFlags)
     at System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
     at System.Reflection.MethodBase.Invoke(System.Object, System.Object[])
     at NUnit.Framework.Internal.Reflect.InvokeMethod(System.Reflection.MethodInfo, System.Object, System.Object[])
     at NUnit.Framework.Internal.MethodWrapper.Invoke(System.Object, System.Object[])
     at NUnit.Framework.Internal.Commands.TestMethodCommand.InvokeTestMethod(NUnit.Framework.Internal.TestExecutionContext)
     at NUnit.Framework.Internal.Commands.TestMethodCommand.RunTestMethod(NUnit.Framework.Internal.TestExecutionContext)
     at NUnit.Framework.Internal.Commands.TestMethodCommand.Execute(NUnit.Framework.Internal.TestExecutionContext)
     at NUnit.Framework.Internal.Execution.SimpleWorkItem+<>c__DisplayClass4_0.<PerformWork>b__0()
     at NUnit.Framework.Internal.ContextUtils+<>c__DisplayClass1_0`1[[System.__Canon, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].<DoIsolated>b__0(System.Object)
     at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
     at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
     at NUnit.Framework.Internal.ContextUtils.DoIsolated(System.Threading.ContextCallback, System.Object)
     at NUnit.Framework.Internal.ContextUtils.DoIsolated[[System.__Canon, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]](System.Func`1<System.__Canon>)
     at NUnit.Framework.Internal.Execution.SimpleWorkItem.PerformWork()
     at NUnit.Framework.Internal.Execution.WorkItem.RunOnCurrentThread()
     at NUnit.Framework.Internal.Execution.WorkItem.Execute()
     at NUnit.Framework.Internal.Execution.ParallelWorkItemDispatcher.Dispatch(NUnit.Framework.Internal.Execution.WorkItem, NUnit.Framework.Internal.Execution.ParallelExecutionStrategy)
     at NUnit.Framework.Internal.Execution.ParallelWorkItemDispatcher.Dispatch(NUnit.Framework.Internal.Execution.WorkItem)
     at NUnit.Framework.Internal.Execution.CompositeWorkItem.RunChildren()
     at NUnit.Framework.Internal.Execution.CompositeWorkItem.PerformWork()
     at NUnit.Framework.Internal.Execution.WorkItem.RunOnCurrentThread()
     at NUnit.Framework.Internal.Execution.WorkItem.Execute()
     at NUnit.Framework.Internal.Execution.TestWorker.TestWorkerThreadProc()
     at System.Threading.Thread+StartHelper.Callback(System.Object)
     at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
     at System.Threading.Thread.StartCallback()
    

Warning: Parameter not found: enable_new_segsearch`

I've checked the bin folder, and all Windows native libraries are in place inside the 'runtimes' folder. Also the suggestion as to copy the libSkiaSharp.dll next to the executable assembly as well has no effect sadly. And I guess the x86 libraries are not broken per se, as they are working fine for net472 => only in combination with Net8 (for ticket owner Net9.0) it seems to be troublesome.

EDIT: Sorry, forgot to mentioned, version 3.119.1 is used.

TomPMoleman avatar Dec 16 '25 12:12 TomPMoleman