Continue to check the failed tests

[masesdevelopers]

Some tests fails for other reason than the previous: specifically under windows and with JDK 17. Looking at the available dumps, sometime there is an access violation during preparation of the KNetSerialization class. However, trying to reproduce the issue locally, the exception is not raised; between GitHub and local test the differences are:

• OS: Windows Server for GitHub, Windows Desktop in local
• JDK: locally tested only with a Temurin JDK 17
• .NET 6/8: both at latest version

It is possible to highlight that KNetReplicator never raises such exception and the exception is not raised from the same test even if the order of execution is always the same.

Originally posted by @masesdevelopers in #243 (comment)

[masesdevelopers]

After some runs using both last published version and last build version of JNet/KNet it is possible to highlight that:

• Test fails always on Windows, i.e. windows-latest GitHub image
• Few time fails the tests with KNetReplicator: an example is at https://github.com/masesgroup/KEFCore/actions/runs/9778745372/job/26996474265
• Other failures happen when a JDK 17 is in use: most one with Zulu, but other one are reported too; the failures in general reports the following callstack (here the source job):

The last pc belongs to native nmethod (printed below).
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 2983  java.lang.Class.getDeclaredMethods0(Z)[Ljava/lang/reflect/Method; java.base@17.0.10 (0 bytes) @ 0x00000292d69090e3 [0x00000292d69090a0+0x0000000000000043]
J 1419 c1 java.lang.Class.privateGetDeclaredMethods(Z)[Ljava/lang/reflect/Method; java.base@17.0.10 (64 bytes) @ 0x00000292ceff01dc [0x00000292ceff0040+0x000000000000019c]
j  java.lang.Class.getDeclaredMethods()[Ljava/lang/reflect/Method;+20 java.base@17.0.10
v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0xffffffffffffffff

which ends in the native call getDeclaredMethods0 which accepts only a boolean parameter. So the expectation is that something is wrong at the hearth of the JVM itself.
The same

The last pc belongs to native nmethod (printed below).
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 2971  java.lang.Class.getDeclaredMethods0(Z)[Ljava/lang/reflect/Method; java.base@17.0.11 (0 bytes) @ 0x0000022db91a5063 [0x0000022db91a5020+0x0000000000000043]
J 1388 c1 java.lang.Class.privateGetDeclaredMethods(Z)[Ljava/lang/reflect/Method; java.base@17.0.11 (64 bytes) @ 0x0000022db188255c [0x0000022db18823c0+0x000000000000019c]
j  java.lang.Class.getDeclaredMethods()[Ljava/lang/reflect/Method;+20 java.base@17.0.11
v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0xffffffffffffffff

within a Corretto 17