Fork me on GitHub
#graalvm
<
2019-06-28
>
sogaiu00:06:52

@rahul080327 @borkdude may be y'all know about this already, but looks like this utility might help to confirm what dlls are actually used by particular processes: https://docs.microsoft.com/en-us/sysinternals/downloads/listdlls

sogaiu00:06:45

from: https://answers.microsoft.com/en-us/windows/forum/windows_10-files/missing-api-ms-win-core-dlls/d99d1368-0f92-43db-bbdb-7d080f1f96e9 > TLDR; They're part of architectural changes to Windows to support multiple devices and system architectures. They shouldn't be used or linked to directly and should not themselves be distributed. Rather apps and programs should make use of MinCore.lib or MinCore_Downlevel.lib. seems to suggest may be the native-image generator should be doing something different than it currently is?

sogaiu02:06:35

i'd like to observe if the following is affecting the tests:

If a DLL with the same module name is already loaded in memory, the system checks only for redirection and a manifest before resolving to the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
does anyone know a good way to find out precisely which dlls are already loaded in memory?

sogaiu03:06:26

using listdlls seems like it could work, but if something doesn't show up in listdlls output (for all processes), does that mean it isn't "loaded in memory"?

sogaiu06:06:32

i just tried starting clj-kondo.exe on a fresh win10 vm in a folder with only mscvr100.dll...it started successfully