Slicer on Windows 11

Now that Windows 11 has been publicly released, I have started to test out Slicer’s compatibility on the new version of the OS.

The latest Slicer stable 4.11.20210226 currently starts without issue on Windows 11, however the latest Slicer Preview is not starting and getting stuck at instantiating modules during the splash screen. I was using today’s preview build Slicer 4.13.0-2021-10-08.

I have currently only been able to start Slicer preview by doing the following to disable scripted modules.
Slicer.exe --disable-builtin-scripted-loadable-modules

Thanks for testing :+1:

Do you think the failures are due to the preview binary not being signed or something else?

Ok I’ve narrowed it down some more.

After launching Slicer 4.13.0-2021-10-08 successfully with Slicer.exe --disable-builtin-scripted-loadable-modules, Slicer will crash on import numpy. Some scripted modules were importing numpy which was why it was failing on start.

Wow, I would not have expected this, and most likely Microsoft will fix this soon, but it is worth investigating this just in case.

Are there any useful information in the Windows Event log?

Does installing Visual Studio runtime libraries help?

Can you check if standard Python 3.6.7 is similarly crashing, too?

Importing numpy from PythonSlicer.exe works, but not with Slicer preview started and using the python console.


PS C:\Users\james\AppData\Local\NA-MIC\Slicer 4.13.0-2021-10-08\bin> ./PythonSlicer

Python 3.6.7 (default, Oct  8 2021, 23:20:41) [MSC v.1924 64 bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.

>>> import numpy

>>> numpy.__version__

'1.19.5'

Importing numpy from within Slicer 4.11.20210226 works perfectly.

When importing numpy within Slicer preview console, the application locks up and becomes unresponsive which then the OS wants to close.

I’m currently using latest runtime (14.29.30135). The fact that numpy successfully imports from PythonSlicer, but not within Slicer preview makes me think it is a Slicer problem.

Nothing in the Windows Event Viewer since the app just becomes unresponsive. Just ultimately logged The program SlicerApp-real.exe version 0.0.0.0 stopped interacting with Windows and was closed.

The only thing I can think of is stdout/stderr redirection issue. Does it help if you launch Slicer.exe from the terminal?

What method Slicer gets stuck in? You don’t need to install a debugger, just right-click on SlicerApp-real.exe in ProcessExplorer, go to Threads tab, choose the main thread, and click on Stack button.

Launching the applauncher from powershell has the same results as if I was to launch with a desktop shortcut.

I don’t believe I have used ProcessExplorer before. Is this the type of output you’re looking for?
image

Yes, this is the call stack. Usually the main thread is the topmost, but its call stack does not look like usual (it should start with some memory addresses in SlicerApp-real.exe and qSlicerBaseQTCore.dll!qSlicerCoreApplication::exec). Maybe the application was already shutting down.

You might need a debug-mode build to make it easier to see where the application is hanging.

With my debug build of Slicer, here is the stack at startup using ./Slicer.exe --disable-builtin-scripted-loadable-modules.
stack-call-debug-startup

Then the stack after doing import numpy.
stack-call-debug-numpy

When attached to process, after import numpy I only see that it loaded a few more things before locking up. Note that my “S5R” is actually a debug build.

'SlicerApp-real.exe' (Win32): Loaded 'C:\S5R\python-install\Lib\lib-dynload\_ctypes.pyd'. Module was built without symbols.
'SlicerApp-real.exe' (Win32): Loaded 'C:\S5R\python-install\Lib\site-packages\numpy\.libs\libopenblas.WCDJNK7YVMPZQ2ME2ZZHJJRJ3JIKNDB7.gfortran-win_amd64.dll'.

The call stack after numpy import looks like the application is already shutting down, so does not tell anything about the underlying error.

I’ve started a Windows11 build on an Azure VM. While setting up things, I already experienced a number of regressions in the operating system (some applications, such as Anydesk installer don’t start, download and run from Edge browser breaks after a few downloads, drag-and-drop to the taskbar does not bring the application to the top). Overall, it does not feel like a finished product, which I have not experienced since Windows Vista.

So far I haven’t noticed any issues with how I use Windows. Overall, my first impression is it isn’t much different from my last transition from Windows 7 to Windows 10. Requires some learning of the updated UI, but nothing I don’t already have to do when I update my iPhone to the latest iOS each year. I’m sure the next Windows update this upcoming Tuesday (patch Tuesday) will resolve some issues and other issues will be tuned over the coming months.

A release build generated on Windows 11 with the latest Windows SDK (10.0.22000) and Visual Studio 2022 v143 toolset, packaged successfully and runs successfully on a Windows 10 machine. import numpy is successful. When running on Windows 11 the same import numpy lock up issue is present.

I’ve built Slicer on Windows11 yesterday with v142 toolset in debug mode and it works well on that Windows11 computer. I’ll test a release-mode build soon.

Unfortunately, release-mode build hangs at startup, debug-mode build starts normally. This is the worst combination, because it makes debugging harder. I’ve now started a RelWithDebInfo build.

I’m surprised that debug-mode build starts normally for you as it did not start for me for both release and debug on Windows 11.

I think it might be worth deferring developmental time into this issue for a few weeks while Microsoft sorts out some of their regressions. Microsoft has noted a number of issues including non-ASCII characters in registry keys. After seeing this message, I installed Windows 11 and replicated the issues of @jamesobutler. I was concerned, as my own MRIcroGL uses embedded Python. Recently, I have changed the way my software links to the Python dll files. I found that old versions of my software worked, while the most recent release did not. Since my software is much simpler than Slicer3D, I thought this might allow me to track down the issue. However, after Windows updated itself all my software seemed to work. I removed initialization files and reinstalled the latest version of my software and it seems to work out of the box now. My best explanation is that some Windows update resolved my own issue. Based on this anecdotal experience, it might be worth waiting a while until Microsoft gets their shop in order. I actually like the user interface changes, but agree with @lassoan that Windows 11 feels unfinished and rushed to market.

1 Like

Thanks for the useful additional information @Chris_Rorden.

I did some more debugging and it turned out that (as expected) that the hang is related to output redirection. An easy workaround is to import numpy once early (before output redirection is set up). See more details in this issue:

Pull request with the proposed fix is submitted.

Updating Windows 11 from OS Build 22000.194 to 22000.258 with yesterday’s Patch Tuesday release did not fix the Slicer startup issues. It did resolve other unrelated issues with using the OS such as poor performance on VPN.

I can confirm that @lassoan 's workaround fix did resolve the issue for me. I confirmed by using the latest Slicer Preview (4.13.0-20211012) built by the factory build machine (It also worked for my local build). Here is a Slicer scripted module that I’m now able to load with Slicer running on Windows 11.

I will continue to provide updates if I find any compatibility issues on Windows 11 with Slicer.

1 Like