1

I have a java application (tomcat-app) using a JNI connection to a C-library in the background. In a very random way this java application crashs. I saw in the system events, that is crashed based on ntdll.dll, which is a system library in Windows/System32.

Can somebody tell me, what functions ntdll.dll offers, for what is it used for and why java needs this ntdll.dll?

I have used Google for finding a solution, but this crash can occur on nearly all Windows-Systems, i combination of a lot of applications (it seems that it is not just a windows-java problem). The standard solution was to reinstall/update the system and/or applications. But is there an explication, why this ntdll.dll makes so much trouble?

Do you think, that it would help, if i put a ntdll.dll in a higher version into the java directory or the directory of the c-library, so that java or c-lib can take this newer version, instead of the Windows/System32-version?

Thanks a lot for your advices.

Alex
  • 161
  • 1
  • 13
  • 2
    `ntdll.dll` loaded in all processes without any exception. and your crash absolute unrelated to `ntdll.dll` – RbMm Jun 13 '18 at 18:05
  • Given `ntdll.dll` is used on multiple millions of installations successfully, and your (presumably home-grown) JNI app is used multiple orders of magnitude fewer installations, what are the odds of a random fault being in `ntdll.dll` as opposed to your own application? Given that `ntdll.dll` does things like memory management, it's likely failing on land mines your code introduces into the process memory space via something like heap or stack corruption. – Andrew Henle Jun 16 '18 at 17:41

2 Answers2

2

ntdll is a low level windows system api which provides hundreds of windows api functions like memory management, loading DLLs and system-exceptions.

You must not use a different version than the one on your system as it is tightly coupled / integral part of the windows operating system version you are running on.

Without further information it is hard to tell what the problem might be, but maybe you are using an incorrect calling convention in the JNI wrapper which leads to an imbalanced stack.

wech
  • 91
  • 5
  • More likely it's just simple heap corruption. – Andrew Henle Jun 16 '18 at 17:42
  • You must not use a different version other than the one on the environment because system call indexes change (for Nt*/Zw* exports - which are for same stub by the way). Occasionally, changes to Ldr*, Rtl*, etc. – ImmortaleVBR Jul 16 '18 at 21:40
0

It seems, that the JNI calls were correct (we have used an external library, which has used JNI). Furthermore we have found a workaround for this problem. A functional update of Windows has raised the version of ntdll.dll. This has solved the problem; crashes of java.exe never appeared again.

Alex
  • 161
  • 1
  • 13