Slicer-4.13 hangs at startup on Windows11

[lassoan]

Slicer does not start up (hangs, then the operating system terminates it) on Windows11

See discussion here:
https://discourse.slicer.org/t/slicer-on-windows-11/20085/11

Environment

• Slicer version: Slicer 4.13.0-2021-10-08
• Operating system: Windows 11 Pro, Version: 21H2, OS build: 22000.194

[lassoan]

I did some more debugging and I can confirm what @jamesobutler found above that the application's main thread hangs in the Windows kernel when running the _fsstat64() function. This function is called by openblas (libopenblas.WCDJNK7YVMPZQ2ME2ZZHJJRJ3JIKNDB7.gfortran-win_amd64.dll) that numpy loads when the application is starting up.

The hanging function call can be reproduced in Python:

import _ctypes
_ctypes.LoadLibrary(r"C:\D\S4RD\python-install\Lib\site-packages\numpy\.libs\libopenblas.WCDJNK7YVMPZQ2ME2ZZHJJRJ3JIKNDB7.gfortran-win_amd64.dll", 0)

and in C++

LoadLibraryExA("C:\\D\\S4RD\\python-install\\Lib\\site-packages\\numpy\\.libs\\libopenblas.WCDJNK7YVMPZQ2ME2ZZHJJRJ3JIKNDB7.gfortran-win_amd64.dll", NULL, 0);

Most likely this library attempts to read from stdin and it gets blocked (on Windows, reading from a pipe is a blocking operation).

As I suspected, this is related to standard input/output/error redirection. If we don't redirect the stdout and stderr to the logs then the problem does not occur. For example, if we comment out this->ErrorLogModel->registerMsgHandler(new ctkErrorLogFDMessageHandler); in qSlicerApplicationPrivate::init() then the application starts normally. But of course this is not a good solution because we want to capture outputs.

It is interesting to note that the hang seems to depend on timing. For example, by just adding a breakpoint in the logging setup code in a RelWithDebInfo build makes the problem go away (even if the breakpoint is not hit). However, simply adding a this->processEvents() or Sleep(1000) function call in the main thread right after calling q->setupFileLogging(); does not fix the issue.

Since this issue only occurs with this particular DLL, and only if it is loaded after output redirections are set up (anytime after q->setupFileLogging(); call in qSlicerApplicationPrivate::init()), an easy temporary workaround is to import numpy before file logging is set up. For example in S4\Base\Python\slicer\__init__.py. This solves the problem because import numpy loads the openblas DLL into the process, so next time the DLL loading is requested then the operating system just uses the DLL already in the memory.

[jamesobutler]

I'm glad that the libopenblas information was a helpful hint. Thanks for tracking down a workaround! I'll keep an eye on Windows 11 compatibility issues and if this workaround becomes no longer needed.