Problem solved!  Thanks to @acer for setting me on the right track.

For others, here's the bottom line:

I installed Intel's MKL library on my machine, but Maple 2019 has its own MKL DLLs in the Maple bin folder, which were shadowing 'my' MKL DLLs at runtime.  I confirmed this by moving Maple's MKL DLLs out of the Maple bin folder, which did in fact fix the problem.  (This is not a real fix, obviously, but it does confirm that shadowing of the DLLs was causing the problem.)

So, there are 2 solutions:

1) Don't use a separate MKL installation in code you want to call from Maple.  (There are other choices for BLAS AND LAPACK: OpenBLAS, ATLAS, etc.)

2) Use static linking when compiling the C++ DLL.  In Visual Studio, I did this by changing Properties >> C/C++ >> Code Generation >> Runtime Library from "Multi-threaded DLL (/MD)" to "Multi-threaded (/MT)".  My DLL goes from 38KB to 11MB when I do this -- that's not ideal, of course, but I can live with it for now.

@acer Static linking seems like the most promising option.  I'll look into it.

Otherwise, I may need to use something other than MKL for BLAS and LAPACK.  (There are a number of other options: OpenBLAS, ATLAS, etc.)  Using MKL when Maple has its own internal MKL may well make this knot too hard to untangle.

Thanks again for your help.

What I'm trying to achieve: from Maple code, I want to be able to call C++ code that uses Intel MKL code (specifically, my own installation of MKL, not the one baked into Maple itself).

The MKL DLLs in my installation are in two folders: C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\redist\intel64_win\mkl and C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\redist\intel64_win\compiler.

Of course, you're exactly right: I had to add those 2 folders to the system path in order to get execution of the C++ function to succeed in Visual Studio and at the command line, meaning that operators.dll is dynamically linking to the MKL DLLs at runtime.

You're suggesting that I try adding the MKL DLLs to the Maple runtime path.  Is Maple not using the system path for this purpose?  If not, can you tell me how to tell Maple where to look for the MKL DLLs?

Given that, as you said, Maple's bin folder has its own versions of at least some of the DLLs that we're talking about (e.g., mkl_core.dll), I worry that adding my own different MKL DLLs into Maple's runtime path may create more problems than it solves.  Still, if you can give me more specific pointers on how to do that, I'll give it a try!

Thanks for your help.

@ Thank you for the feedback!  I'll keep my fingers crossed that someone will be able to help me, but I'll start thinking about alternate solutions as well.