I have discovered that I have to have my Java Agent configured in the .cfg file for it to happen:
[JavaOptions] java-option=-javaagent:$APPDIR\libs\MyAgent.jar The agent is needed in my real app only to get an instance of the Instrumentation interface. In my test code, where I have reproduced this, it is never used. My test app just takes a URL and fetches it via a HttpURLConnection with setInstanceFollowRedirects(false) so I can capture the new location. If you are still having trouble reproducing I will have the code cleaned up for the bug report soon... Regards, Scott > On Sep 21, 2021, at 12:12 PM, Andy Herrick <andy.herr...@oracle.com> wrote: > > I thought I could create a reproduction scenario by using an app with > "-splash:<image file>" arg then moving the jre as you did, but I have not yet > been able make it fail. > > /Andy > > On 9/21/2021 11:43 AM, Scott Palmer wrote: >>> On Sep 21, 2021, at 11:40 AM, Alan Bateman <alan.bate...@oracle.com> wrote: >>> >>> On 21/09/2021 15:54, Andy Herrick wrote: >>>> I found the problem in >>>> open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp >>>> >>>> we call SetDllDirectory() with the path to the bin dir in the default >>>> runtime directory, not the actual runtime directory. >>>> >>>> since on Windows we never use other than the default runtime location - we >>>> had not seen a problem, but is bug I will file and fix. >>>> >>> Good to see that you found it quickly. However I'm puzzled as why >>> initializingEncoding wasn't called, I would have expected the VM to blow up >>> during early startup. Would you have cycles to dig into that a bit more in >>> case something has been masked, like for example an exception being >>> swallowed. Running with -Xlog:exceptions might reveal something. >> >> Do you have a case that reproduces the issue? >> >> Scott
