The two applications, as well as the library, were all being compiled as Debug builds.

The issue was due to setting 'Project Properties -> Configuration Properties -> Use Debug Libraries' of the two executable projects being set to 'No', which I found entirely strange that this setting became an issue when it was not before.

I researched further and discovered:

The runtime issue when compiling a Debug version of TradeTools with Use Debug Libraries set to "No" could be caused by a mismatch between the build configuration and the libraries being linked or used. Here’s why this matters and how it could affect the applications:

Mismatch Between CRT Libraries

Debug builds typically link against debug versions of the C runtime (CRT), like MSVCRTD.lib, while Release builds link against MSVCRT.lib. If Use Debug Libraries is set to "No", the compiler links against the Release CRT, but the code and dependencies (like TradeTools) may still be expecting debug symbols and debug-specific memory management behavior.

Memory Allocation Differences

Debug and Release CRTs manage memory differently (e.g., debug CRT adds padding and performs extra checks). If the TradeTools library is compiled with Debug settings but linked against Release CRT, any cross-boundary allocation/deallocation (e.g., new in DLL, delete in EXE) could lead to heap corruption or invalid pointer exceptions.

Symbol Mismatch

Debug builds often include extra symbols for debugging (like assert, extra std::vector checks, etc.). If you're running a debug build but linking to the Release CRT, you may encounter "Entry Point Not Found" or unresolved symbol issues because the debug symbols aren’t present in the linked Release CRT.

Thank you to those that commented / helped.