Can one use MKL with C++/WinRT?

[Eckhardt__Stephen]

I'm trying to call MKL routines from a program written for WinUI 3 using C++/WinRT.  Unfortunately, when I call a cblas routine, the program crashes.  STL exception handling catches nothing.  Is MKL compatible with C++/WinRT?

I created a repro and saved it in https://github.com/dr-eck/MiniEditor  as the TestMKL project.  Here's what I did:

First, create a standard "Blank App, Packaged (WinUI 3 in Desktop)" app and remove all traces of myProperty. Here's the new MainWindow.cpp:

#include "pch.h"
#include "MainWindow.xaml.h"
#if __has_include("MainWindow.g.cpp")
#include "MainWindow.g.cpp"
#endif
#include "mkl.h"
#include <exception>

using namespace winrt;
using namespace Microsoft::UI::Xaml;

namespace winrt::TestMKL::implementation
{
    MainWindow::MainWindow()
    {
        InitializeComponent();
    }
    void MainWindow::myButton_Click(IInspectable const&, RoutedEventArgs const&)
    {
        myButton().Content(box_value(L"Clicked"));
        // Test MKL
        // Example: Compute the dot product of two vectors
        double x[3] = { 1.0, 2.0, 3.0 };
        double y[3] = { 4.0, 5.0, 6.0 };
        double rv;
        try {
            rv = cblas_ddot(3, x, 1, y, 1);
        }
        catch (const std::exception& e) {
            OutputDebugString((L"MKL exception: " + to_hstring(e.what()) + L"\n").c_str());
        }
        OutputDebugString((L"Dot product: " + std::to_wstring(rv) + L"\n").c_str());
        result().Text(winrt::hstring{ std::to_wstring(rv) });
    }
}

Then, as a review for OneAPI users:

1. Install the OneAPI base toolkit
2. Make sure ONEAPI_ROOT points to C:\Program Files (x86)\Intel\oneAPI\
3. Add $(ONEAPI_ROOT)\mkl\latest\include to the C/C++ | General | Additional Include Directories
4. Add $(ONEAPI_ROOT)\mkl\latest\lib to the Linker | General | Additional Library Directories
5. Add mkl_intel_lp64_dll.lib;mkl_tbb_thread_dll.lib;mkl_core_dll.lib; to the Linker | Input | Additional Dependencies
6. copy mkl_blacs_lp64.2.dll, mkl_core.2.dll and mkl_tbb_thread.2.dll to the x64\Debug\TestMKL\AppX directory

You must copy the DLLs even if you work from the Github repo.

The program should compile and run. When the button is clicked, the program disappears. Commenting out the MKL code verifies that the program does not disappear if cblas_ddot is not called.

How do I make this work?

[Shiquan_Su]

Hi, Stephen:

Would you be more specific about which button you click? Can you run the debug mode to output the debug result? Can you see the actual compile/link commands to be run? Which step does your code crash? The compile step? The link step? Or the run time?

[Eckhardt__Stephen]

Thanks for the quick response.  In my instruction "First, create a standard "Blank App, Packaged (WinUI 3 in Desktop)" app", I should have mentioned that you need to use Visual Studio 2022.  If you follow this instruction, you will end up with a WinUI 3 app that displays one button.  When you click that button, the code in 

myButton_Click()

 runs.  The line of code where the program crashes is: 

rv = cblas_ddot(3, x, 1, y, 1);

Here's the debug output:

The thread 'DWM Compositor Thread' (25732) has exited with code 2 (0x2).
The thread 'DWM Master Input Thread' (37808) has exited with code 2 (0x2).
The thread 35044 has exited with code 2 (0x2).
The thread 28696 has exited with code 2 (0x2).
The thread 22284 has exited with code 2 (0x2).
The thread 38236 has exited with code 2 (0x2).
The thread 19496 has exited with code 2 (0x2).
The thread 'DManip Delegate Thread' (38376) has exited with code 2 (0x2).
The thread 23180 has exited with code 2 (0x2).
The thread 35644 has exited with code 2 (0x2).
The thread 35052 has exited with code 2 (0x2).
The thread 29832 has exited with code 2 (0x2).
The thread 19784 has exited with code 2 (0x2).
The thread 'Lifted DMIT' (25556) has exited with code 2 (0x2).
The thread 14616 has exited with code 2 (0x2).
The thread 'DWM Manipulation Thread' (37100) has exited with code 2 (0x2).
The thread 16132 has exited with code 2 (0x2).
The thread 'Composition Token Thread' (28208) has exited with code 2 (0x2).
The thread 34600 has exited with code 2 (0x2).
The program '[17628] TestMKL.exe' has exited with code 2 (0x2).

The code crashes in run time.

Please let me know if you need any other information.
 

[Viraj_M_Intel]

Hi @Eckhardt__Stephen 

Can you add `mkl_uwp_compat_dll.lib` and `mkl_uwp_compat.dll` in steps 5 and 6 of VS project setup respectively and check if the app works?

If you still have failures, please share the build commands from the command-line or build output in Visual studio.

[Eckhardt__Stephen]

I'll be happy to try that.  Where do I get copies of the files?  They aren't in my OneAPI distro, and I can't find them on the Intel.com site.

[Viraj_M_Intel · Accepted solution]

Hi @Eckhardt__Stephen ,

Looks like oneMKL stopped shipping these 2 files some time ago. I will check with the team and see if we can re-enable them. Sorry for the inconvenience.

As a workaround until then, you may use the Custom DLL builder to build a custom DLL with only the APIs that you need, and also enable UWP support for that DLL: https://www.intel.com/content/www/us/en/docs/onemkl/developer-guide-windows/2025-0/using-the-custom-dll-builder-in-command-line-mode.html. Check the "uwd_compat" and "crt" options. Note that custom DLL builder only works in the command-line. Once you have your custom DLL, you can use that in steps 5 and 6 instead of the default oneMKL libraries.

Please share if this works for you.

[Eckhardt__Stephen]

Hi @Viraj_M_Intel ,

Thanks for checking with the team.  One important note:  WinUI 3 is part of the Windows App SDK, which is significantly different from UWP.  Because UWP is deprecated and Win App SDK is recommended for all future development, the ideal case would be to have `mkl_was_compat_dll.*` files rather than the UWP versions.  Feel free to fork my https://github.com/dr-eck/MiniEditor , specifically  the TestMKL project, to test the new files.

Thanks also for the workaround.  I'll try it, but "uwd_compat" forces "threading = sequential", which does not give me the performance enhancement I want.  I'll let you know later today if it works.

[Eckhardt__Stephen]

Hi @Viraj_M_Intel ,

I'm still working on creating a custom DLL.  The page you reference tells me to use nmake to make the DLL.  It took me a while to find the makefile, and it doesn't quite work.  I didn't have time to fix it today.  I also tried the Visual Studio project in the same part of the distro, but haven't got that to work yet either.  I'll try again tomorrow.

[Viraj_M_Intel]

NMake can be installed from the Visual studio installer, but needs to be used from the command-line for the custom DLL builder.

[Eckhardt__Stephen]

@Viraj_M_Intel Thanks.  I'm familiar with nmake, but a bit rusty.  I had to add the locations of lib.exe and mt.exe to my PATH and the location of libcmt.lib to my LIB.  Once I did this, nmake worked flawlessly.  I added the output files to the appropriate folders in my TestMKL app, and it works!

Now the bad news.  My real app uses a few LAPACKE functions, such as LAPACKE_dposv.  I added these to the "export" input file for nmake and rebuilt the DLLs.  They grew, so things were looking good.  Unfortunately, although the linker finds the cblas_* functions, it does not find the LAPACKE_* functions in the same .lib file.  I used Notepad++ to look at the .exp and .lib files, and the LAPACKE_*  files are in there. 

Here's one error message:

unresolved external symbol LAPACKE_dposv referenced in function "public: class std::vector<double,class std::allocator<double> > __cdecl DLS::Solve(class std::vector<double,class std::allocator<double> >,class std::vector<double,class std::allocator<double> >)" (?Solve@DLS@@QEAA?AV?$vector@NV?$allocator@N@std@@@std@@V23@V23@@Z)

Any clues as to why the linker is able to find the cblas_* functions but not the LAPACKE_* ones?

[Eckhardt__Stephen]

Oops!  Things work much better when you copy the new files to the correct folder.  (Blush).  Problem solved, at least for as long as I can tolerate single threaded performance.  Please let me know when I can either make a new custom DLL with a WindowsAppSDK_compat flag or beta test the new "mkl_was_compat_dll.*" files.

[Viraj_M_Intel]

@Eckhardt__Stephen Can you please share why you are limited to single threaded performance if placing oneMKL DLLs in the App directory? Can you use mkl_intel_thread or mkl_tbb_thread instead of mkl_sequential? You will also need Openmp or TBB depending on which threading option you choose.

I am looking into this issue now, and my general understanding from WinAppSDK is that it creates a sandboxed environment and installs packages in that environment via Nuget as the primary package manager. Since Nuget is not the only option, users may choose a different way to source their dependencies and packages, one of them being manual DLL integration via the app manifest and copying them into the app folder, which you tried earlier.

That being said, we do provide oneMKL nuget packages for static linking: https://www.nuget.org/packages/intelmkl.static.win-x64 and dynamic linking: https://www.nuget.org/packages/intelmkl.redist.win-x64. (Note the dependencies in the dependencies tab). Can you give either of these two packages a try and let us know if they work directly with your workflow without manual modifications?

Reference: https://www.intel.com/content/www/us/en/developer/tools/oneapi/onemkl-download.html?operatingsystem=windows&windows-install=nuget 

[Eckhardt__Stephen]

I'm having trouble with the Visual Studio Nuget Package Manager.  I can easily find intelmkl.redist.win-x64 when I browse nuget.org from within the Nuget Package Manager, but when I attempt to install it, I get this message:

Package 'intelmkl.redist.win-x64 2025.3.0.453' is not found in the following primary source(s): 'https://api.nuget.org/v3/index.json'. Please verify all your online package sources are available (OR) package id, version are specified correctly.

I just updated three packages, so the manager seems to be working, at least for Microsoft code.

I also tried using the Package Manager Console, but I got an error.  Here's the session:

PM> NuGet\Install-Package intelmkl.redist.win-x64 -Version 2025.3.0.453


Attempting to gather dependency information for package 'intelmkl.redist.win-x64.2025.3.0.453' with respect to project 'My Project', targeting 'native,Version=v0.0'
NuGet\Install-Package : Package 'intelmkl.redist.win-x64 2025.3.0.453' is not found in the following primary source(s): 'https://api.nuget.org/v3/index.json,C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'. Please verify all your online package sources are 
available (OR) package id, version are specified correctly.
At line:1 char:1
+ NuGet\Install-Package intelmkl.redist.win-x64 -Version 2025.3.0.453
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand
 
Time Elapsed: 00:00:00.2433915

I'm guessing this is a Visual Studio problem (or user error), but do you have any suggestions?

[Eckhardt__Stephen]

@Viraj_M_Intel I figured it out just after posting.  I needed to add an "intel*" mapping to my preexisting "Microsoft.*" mapping.  intelmkl.redist.win-x64 and its dependencies are now installed.  Now I can test them.

[Eckhardt__Stephen]

I linked against the libraries under Intel/OneAPI/mkl (and Intel/OneAPI/2025.3/lib for libiomp5md.lib) and my program now links and runs.  The NuGet packages seem to have done the trick.  Thank you very much!!!

[Viraj_M_Intel]

@Eckhardt__Stephen Thank you for verifying!

Just a heads-up - I found that the threading options are not populated by default after installing the intelmkl nuget package, so I had to choose those options in the properties manager:

[Eckhardt__Stephen]

Thanks for letting me know.  I changed the setting from Sequential to Parallel and the program still works.  I'm very happy.