When building OpenJDK on Windows using "--with-native-debug-info=external", the resulting debug symbols are saved in files located in the same folder as the corresponding executable or library and named by swapping the extension ".exe" or ".dll" for a ".pdb" one (or "diz" if option "--with-native-debug-info=zipped" is used).

Although it is a common convention, this has the unfortunate side effect of producing colliding paths in the event of an exe and a dll file sharing the same target folder and file name, save for the extension.
In OpenJDK this is the case for "bin\java.exe" and "bin\java.dll" (resolve to the same "bin\java.pdb" for their symbols), as well as "jimage.exe/jimage.dll" and "jpackage.exe/jpackage.dll".
This means both set of debug information cannot naturally coexist while strictly adhering to the rule.
(NB: Builds for unix-like platforms are not affected by this, due to a/ the fact that libraries and launchers are not located in the same folder, b/ the radical for executables and libraries typically differ, e.g. java / libjava)

It is generally admitted that the debug symbols for the libraries are more useful than those for the launchers, so specific build logic has been added to ensure those symbols are always prioritized.
As a result, symbol files for java.exe, jpackage.exe and jimage.exe are left out of all build images of OpenJDK.

One way to avoid that is to adopt a naming strategy for the pdb files that does not incur a risk of collision; for instance by keeping the original extension in the final name, e.g. "jvm.dll" -> "jvm.dll.pdb" instead of "jvm.pdb" (and "jvm.dll.stripped.pdb" for stripped symbols if "--with-external-symbols-in-bundles=public" is used, "jvm.dll.diz" for "--with-native-debug-info=zipped").

The debugging experience, both with Visual Studio and the built-in tooling already present in the JDK, should not be affected by this change of name.