KB5063878 and Microsoft.Ink exception

You’re hitting a System.MethodAccessException from .NET’s Code Access Security (CAS) when your tool starts, specifically involving Microsoft.StylusInput and Microsoft.Ink. This kind of error usually happens when a security-transparent method tries to call a native or unsafe method, and .NET’s security model blocks it. The tricky part is that your project has been working fine for 8 years, but likely a recent .NET Framework update or Windows update tightened the security rules for CAS.

Here’s the situation in human terms: the framework is saying, “Hey, this old method wants to do something unsafe, and I can’t just let it go without marking it properly.” But you don’t want to resurrect or heavily modify the old code.

Practical ways to handle this without rewriting everything:

Target an older .NET Framework version (if possible)

Many of these CAS restrictions were relaxed in older versions.

  If your tool currently runs on, say, **.NET 4.8**, you might try **running it on 4.6 or 4.5**, if feasible.
  
  **Use the `LegacyCasPolicy` setting**
  
     In your app.config, add:
     
     ```
     <configuration>

<runtime> <NetFx40_LegacySecurityPolicy enabled="true"/> </runtime> </configuration> ```

        This can allow the old CAS behavior without touching the code.
        
        **Run the app as full trust**
        
           If this is a desktop app, make sure it’s **not running in partial trust** or via a network share. Full-trust execution usually bypasses this exception.
           
           **Shim the problem with a small wrapper**
           
              If you really want a minimal intervention, you can create a **small helper assembly** marked as **security-critical** that calls the native methods and leaves the rest of your old code untouched.
              

TL;DR (developer-to-developer version): Your old code worked fine until .NET tightened security rules. The easiest fixes are either enable legacy CAS policy in your config, run the app fully trusted, or target an older .NET Framework. That way, you can avoid touching the decades-old code and still get the tool running.

If you want, I can write a ready-to-use app.config snippet that will likely fix this immediately without any code changes.

Same problem here.

Problem fixed after uninstalled KB5065426.

Many companies are having the same or a similar issue:

https://developercommunity.visualstudio.com/t/SecurityException-in-MicrosoftInkInkOv/10958778?wt.mc_id=DT-MVP-4039781&viewtype=all

Just to give a bit more perspective on this subject. In our case, the failing application was targeted as .NET Framework 3.5 and the error that we first got after KB installation was much more surprising:

Caused by: No se puede cargar el archivo o ensamblado 'Microsoft.Ink, Version=6.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' ni una de sus dependencias. Este ensamblado se creó con un tiempo de ejecución más reciente que el tiempo de ejecución cargado actualmente y no se puede cargar.

Which basically states that Microsofts.Ink assembly "changed" with the update and was built with a newer 'minimum' runtime. The funny thing is that going to a pre-KB machine, assembly version was the same, 6.1.0.0, but file just changed.

So, in the end, we have a kind of 'nighmare' loop situation:

• NET 3.5 -> assembly doesn't load, as was rebuild with higher prerequisites...
• NET 4.0+ -> security constraints from CAS don't let it work (as shown in previous comments). And legacy settings don't work either, at least in our scenario.

Having to upgrade software to a higher framework, taking into account that 3.5 is supposed to be LTS, is not a reasonable approach. And, just for you to know, we tried that just to check, and it didn't work either. Looks like the problem comes from Microsoft.Ink Assembly itself:

Caused by: Error cuando el método transparente en seguridad 'Microsoft.Ink.Tablets.get_Count()' intentó llamar a código nativo a través del método 'Microsoft.Ink.IInkTablets.get_Count()'. Para llamar a código nativo, los métodos deben ser críticos para la seguridad o críticos para la seguridad y disponibles desde código transparente.

Above error (after upgrading the framework) basically tells (if we are not wrong), that Microsoft.Ink was doing something CAS didn´t like... is this correct?

The only rational approach here would be to release a new KB restoring previous assembly file (or a correct one), IMHO.

Looking forward to check how this ends...