Add launcher binary that allows for debugging missing DLL dependencies at load time #657
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background: on Unix platforms, running a binary with a missing dependent shared library produces a human-readable error message on stderr containing the name of the missing library. On Windows, the loader may show a graphical dialog box with missing the DLL names when a process is run from a UI context, but in most cases the process will simply exit with
STATUS_DLL_NOT_FOUND
and no other information. This can make debugging missing dependent shared libraries very difficult.The program in this PR uses Loader Snaps and documented SPI to replicate the Unix experience on Windows, printing nice human readable messages like
This application has failed to start because \(missingDLL) was not found.
to stderr. It's implemented as a launcher (think ccache), where its arguments are the command line that would be originally executed.Mostly putting this up to illustrate the technique, not immediately planning to land this. Not sure if this is the right place for it either, or if Swift is even a good choice of implementation language (due to the fact that the launcher itself will have DLL dependences of its own on the Swift runtime).
It also has to be a launcher binary and not a set of helper APIs, since some of the APIs called in here really only make sense in the context of a main executable and not in library code.
Thanks to https://github.com/TimMisiak/LoaderLog/blob/main/LoaderLog.cpp for some learnings behind this.