UnhandledException after updating Windows to latest version.

[teixeiranh]

UnhandledException
Oops, glnk crashed! Please include the following information
if you plan to contact the developers:
Could not load file or assembly 'Microsoft,lnk,
Version=6.1 .O.Ot Culture—neutral,
PublicKeyToken=31 bf3856ad364e35 or one of its
dependencies. This assembly is built by a runtime newer than
the currently loaded runtime and cannot be loaded.
Stack Trace:
at glnk.Root..ctor0
at glnk.Program.MainO in
32

[naatumach]

I also started seeing this issue after the latest windows update.

Windows version -
Edition Windows 11 Home
Version 24H2
Installed on ‎8/‎9/‎2025
OS build 26100.6584
Serial number PF5QFT82
Experience Windows Feature Experience Pack 1000.26100.234.0

Two updates were installed -
2025-09 Cumulative Update for .NET Framework 3.5 and 4.8.1 for Windows 11, version 24H2 for x64 (KB5064401)
2025-09 Cumulative Update for Windows 11 Version 24H2 for x64-based Systems (KB5065426) (26100.6584)

[jzapps-ctrl]

I am getting the same issue. How can we get to resolve this issue. GINK is the best software out here. PLEASE HELP.

[Hash-D25]

getting the same error

[astanin]

Yes, it appears that this issue is the result of the recent Windows update with

• 2025-09 Cumulative Update for Windows 11 Version 24H2 for x64-based Systems (KB5065426) (26100.6584)

And according to crash.txt, it is related to Microsoft.Ink library

Could not load file or assembly 'Microsoft.Ink, Version=6.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

Stack Trace:
   at gInk.Root..ctor()
   at gInk.Program.Main() in D:\Dev\gInk.git\src\Program.cs:line 32

I would like to add that the fork of gInk (ppInk) has a similar problem: pubpub-zz#351 and one of the comments suggests uninstalling Windows Update KB5065426.

This may work as a temporary workaround, but according to MS (https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-24h2#august-2025) this update fixes streaming and screen capture performance issues which have been common since August. So this fix may be important to many gInk users who use it while streaming or doing screen captures.

Another workaround is using PowerToys ZoomIt screen annotations, which can be mapped to the same keyboard shortcut as gInk (by default ZoomIt annotations activate on Ctrl+2). ZoomIt is less user friendly, and switching pens in ZoomIt is only possible through keyboard shortcuts (R, G, B, P for colors, E to erase all, Ctrl-Z to undo, T/Esc to type, Tab/Shift/Ctrl to draw ellipses/lines/rectangles, Ctrl+MouseWheel to change pen size, MouseWheel to zoom).

[Shubham-vish]

Please provide proper fix for this issue, or provide where should I make changes in code inorder to fix it, Pleae add some suggestions.

[atsbomb]

Getting the same error.

[SiliconXu]

Same issue here. Does anyone know how to fix this? I use gInk a lot and this drives me crazy /(ㄒoㄒ)/~~

[yang-example]

Yes, it appears that this issue is the result of the recent Windows update with

• 2025-09 Cumulative Update for Windows 11 Version 24H2 for x64-based Systems (KB5065426) (26100.6584)

And according to crash.txt, it is related to Microsoft.Ink library

Could not load file or assembly 'Microsoft.Ink, Version=6.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

Stack Trace:
   at gInk.Root..ctor()
   at gInk.Program.Main() in D:\Dev\gInk.git\src\Program.cs:line 32

I would like to add that the fork of gInk (ppInk) has a similar problem: pubpub-zz#351 and one of the comments suggests uninstalling Windows Update KB5065426.

This may work as a temporary workaround, but according to MS (https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-24h2#august-2025) this update fixes streaming and screen capture performance issues which have been common since August. So this fix may be important to many gInk users who use it while streaming or doing screen captures.

Another workaround is using PowerToys ZoomIt screen annotations, which can be mapped to the same keyboard shortcut as gInk (by default ZoomIt annotations activate on Ctrl+2). ZoomIt is less user friendly, and switching pens in ZoomIt is only possible through keyboard shortcuts (R, G, B, P for colors, E to erase all, Ctrl-Z to undo, T/Esc to type, Tab/Shift/Ctrl to draw ellipses/lines/rectangles, Ctrl+MouseWheel to change pen size, MouseWheel to zoom).

Tried ZoomIt, the only inconvenience is the lack of a real eraser. Here is a similar tool https://github.com/dynamo07/easy_draw, which I hope can be a workaround.

[teixeiranh]

Yes, it appears that this issue is the result of the recent Windows update with

• 2025-09 Cumulative Update for Windows 11 Version 24H2 for x64-based Systems (KB5065426) (26100.6584)

And according to crash.txt, it is related to Microsoft.Ink library

Could not load file or assembly 'Microsoft.Ink, Version=6.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

Stack Trace:
   at gInk.Root..ctor()
   at gInk.Program.Main() in D:\Dev\gInk.git\src\Program.cs:line 32

I would like to add that the fork of gInk (ppInk) has a similar problem: pubpub-zz#351 and one of the comments suggests uninstalling Windows Update KB5065426.
This may work as a temporary workaround, but according to MS (https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-24h2#august-2025) this update fixes streaming and screen capture performance issues which have been common since August. So this fix may be important to many gInk users who use it while streaming or doing screen captures.
Another workaround is using PowerToys ZoomIt screen annotations, which can be mapped to the same keyboard shortcut as gInk (by default ZoomIt annotations activate on Ctrl+2). ZoomIt is less user friendly, and switching pens in ZoomIt is only possible through keyboard shortcuts (R, G, B, P for colors, E to erase all, Ctrl-Z to undo, T/Esc to type, Tab/Shift/Ctrl to draw ellipses/lines/rectangles, Ctrl+MouseWheel to change pen size, MouseWheel to zoom).

Tried ZoomIt, the only inconvenience is the lack of a real eraser. Here is a similar tool https://github.com/dynamo07/easy_draw, which I hope can be a workaround.

Have you tried "easy_draw"?

[yodaphone]

same problem here. i tried easy-draw, it good, but prefer zoomit. it does have an erase mapped to key E & has a ton of more features.

i would love to have gink back though

[yodaphone]

Ok, asked chatGPT for a fix, here is the output

You’ve hit a .NET Security Transparency crash that started showing up after recent Windows 11 (24H2) / late-2025 updates changed how the legacy Microsoft.Ink COM/interop assembly behaves. The call Microsoft.Ink.DrawingAttributes.set_Color(...) is now treated as a native call from security-transparent code, which .NET disallows—hence:

“Methods must be security critical or security safe-critical to call native code.”

This exact failure is being reported for ppInk/gInk after the latest Windows update ([GitHub]1), and dev threads point to 24H2 shipping a different Microsoft.Ink.dll (recompiled against newer .NET), which tightens transparency rules and produces MethodAccessException/UnhandledException in apps that weren’t annotated for it. ([Stack Overflow]2)

What to do (quickest first)

1) Unblock the app files (if “downloaded”/network-zoned).
Sometimes the runtime treats zoned files as partially trusted.

• Right-click the EXE and DLLs → Properties → Unblock (if present).

• Or PowerShell:

  Unblock-File -Path "C:\Tools\ppInk\*.exe"
  Unblock-File -Path "C:\Tools\ppInk\*.dll"

2) Add a tiny app-config to enable the legacy CAS policy (workaround).
Create a file next to ppInk.exe named ppInk.exe.config with exactly this content:

<?xml version="1.0"?>
<configuration>
  <runtime>
    <NetFx40_LegacySecurityPolicy enabled="true"/>
  </runtime>
</configuration>

This flips the runtime to the legacy security policy, which allows transparent code to reach the Microsoft.Ink native calls (a common mitigation for these transparency regressions). ([Microsoft Learn]3)

Note: This is a compatibility switch. It’s safe as a stop-gap, but it’s deprecated long-term (Microsoft docs). If performance matters, remove it once ppInk releases a fix. ([Microsoft Learn]3)

3) Make sure you’re fully updated (or roll back the offending update).
Several Windows 11 24H2 issues were resolved in later cumulative updates; installing the latest non-security cumulative for your build (or updating to 25H2) can undo regressions introduced by earlier 24H2 packages. If you recently installed a specific KB (reports mention KB5063878 around September 2025) and the issue started immediately after, either install a newer cumulative or temporarily uninstall that quality update from Settings → Windows Update → Update history → Uninstall updates. ([Microsoft Learn]4)

4) (If you build from source) developer-side fixes.
If you compile ppInk yourself, the durable fix is to:

• Mark the interop boundary as [SecuritySafeCritical] or set assembly security rules to Level1 to re-enable v2 transparency behavior, then rebuild. These are standard remedies for transparent→native transitions. ([Microsoft Learn]5)

Why this matches your crash

• The GitHub issue you linked shows the same stack and message for ppInk post-update (Windows 11, August/September 2025 timeframe). ([GitHub]1)
• Community threads confirm Microsoft.Ink in 24H2 now triggers MethodAccessException unless legacy policy or safe-critical annotations are used. ([Stack Overflow]2)
• Microsoft’s config switch is the documented knob to restore legacy CAS behavior for impacted apps. ([Microsoft Learn]3)

---

If you want, I can draft the ppInk.exe.config for you with the exact path you’re running from, and give you a one-liner PowerShell to create it in place.

[fakirsu]

Mark the interop boundary as [SecuritySafeCritical] or set assembly security rules to Level1 to re-enable v2 transparency behavior, then rebuild. These are standard remedies for transparent→native transitions. ([Microsoft Learn]5)

Has anyone managed to make this idea work?