Suppress Windows DLL hard-error dialog on incompatible plugin load by nicoddemus · Pull Request #185 · ESSS/hookman

nicoddemus · 2026-06-23T18:16:41Z

When a plugin DLL has unresolved imports (e.g. a conflicting bundled dependency), Windows would raise a modal hard-error dialog during LoadLibrary before any code could react to the failure.

This change suppresses that dialog and now surface a new typed exception (SharedLibraryLoadError) on the Python side, and as a human-readable RuntimeError (via FormatMessageA) on the C++ side, rather than blocking dialogs.

Plugin discovery is also made resilient: a single failing plugin no longer aborts enumeration of all others. The new get_plugins_available_and_failures() method returns successful plugins alongside a list of PluginLoadFailure records that callers can use to report the specific reason to the user.

Documents how to set up the virtualenv, run type checking, run tests, build C++ artifacts, and regenerate file regression snapshots. Also ignore the .claude/ session directory.

The build task only knew VS 2017 and VS 2019 Enterprise paths; add the VS 2019 BuildTools path so 'inv build' works on machines that have BuildTools installed instead of the full IDE. pybind11 was not found by CMake because no CMAKE_PREFIX_PATH was set; pass it from the pybind11 Python package so the binding target builds correctly with the active virtualenv. Move the build/artifacts sys.path injection from tox's PYTHONPATH setenv into an autouse pytest fixture, so the .pyd is found when running pytest directly outside of tox.

When a plugin DLL has unresolved imports (e.g. a conflicting bundled dependency), Windows would raise a modal hard-error dialog during LoadLibrary before any code could react to the failure. This change suppresses that dialog by setting SEM_FAILCRITICALERRORS via SetThreadErrorMode around every DLL load — both in the Python ctypes path (discovery) and in the generated C++ HookCaller path (hook caller construction). Load failures now surface as a new typed exception (SharedLibraryLoadError) on the Python side, and as a human-readable RuntimeError (via FormatMessageA) on the C++ side, rather than blocking dialogs. Plugin discovery is also made resilient: a single failing plugin no longer aborts enumeration of all others. The new get_plugins_available_and_failures() method returns successful plugins alongside a list of PluginLoadFailure records that callers can use to report the specific reason to the user. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>