saga 9.7.1-1 fails to start (MSVCP140.dll error)

[andreaerdna]

On my Windows 10 Home 64-bit system, SAGA-GIS 9.7.1 (saga 9.7.1-1) fails to start.

The Windows Event Viewer reports the following error:

Nome dell'applicazione che ha generato l'errore: saga_gui.exe, versione: 0.0.0.0, timestamp: 0x6789b035
Nome del modulo che ha generato l'errore: MSVCP140.dll, versione: 14.32.31332.0, timestamp: 0x8b64702c
Codice eccezione: 0xc0000005
Offset errore 0x00000000000132f8
ID processo che ha generato l'errore: 0x47f0
Ora di avvio dell'applicazione che ha generato l'errore: 0x01db99baa11ae5ef
Percorso dell'applicazione che ha generato l'errore: C:\OS5C2A~1\apps\saga\saga_gui.exe
Percorso del modulo che ha generato l'errore: C:\WINDOWS\SYSTEM32\MSVCP140.dll
ID segnalazione: 720bce00-0843-4bf5-bffc-55e36b365526
Nome completo pacchetto che ha generato l'errore: 
ID applicazione relativo al pacchetto che ha generato l'errore:

Bucket errato 1782025303810636025, tipo 4
Nome evento: APPCRASH
Risposta: Non disponibile
ID CAB: 0

Firma problema: 
P1: saga_gui.exe
P2: 0.0.0.0
P3: 6789b035
P4: MSVCP140.dll
P5: 14.32.31332.0
P6: 8b64702c
P7: c0000005
P8: 00000000000132f8
P9: 
P10: 

File allegati:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERB9AC.tmp.dmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERD8CE.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERD9A9.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERD9B7.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERDAA2.tmp.txt

I file potrebbero essere disponibili qui:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_saga_gui.exe_eada9cd6608119c1be4556efad32dafdf87296_bf7819f6_22b8794a-81b1-44b1-8ea6-c6085fde9eb9

Simbolo analisi: 
Nuova ricerca di soluzioni: 0
ID rapporto: 720bce00-0843-4bf5-bffc-55e36b365526
Stato rapporto: 268435456
Bucket con hash: 7e1c97cc1ae010bb28bb06927e63f8f9
GUID CAB: 0

It looks like this issue is similar to the one already previously reported about GRASS #872.

[jef]

Where does that old version in system32 come from?

According to the properties dialog of explorer the version I have in system32 on my local machine is 14.40.33816.0 and OSGeo4W's 14.38.33135.0. And I don't have that issue - but I'm on Windows 11.

However I have no idea when msvcp140.dll was last updated in system32 (according to its timestamp it's from 1.2.2002).

​https://github.com/Zero3/windows-installer-file-search/blob/master/windows-installer-file-search.py reports a ton of packages that (could have) install(ed) msvcp140.dll to system32.

I guess installing the latest vc_redist would fix the issue for you. Was there maybe some recent update that downgraded msvcp140.dll (maybe some common driver for windows 10 or something) and introduced the problem?

[andreaerdna]

Why GRASS-GIS and SAGA-GIS (and other ones) executable don't use the msvcp140.dll shipped by OSGeo4W with the msvcrt2019 package (shouldn't it be named msvcrt2022)? Is there a way to enforce the use of the one shipped by OSGeo4W instead of the one installed in the system (apart from copying the msvcp*.dll in the same folder of the executable)?

It looks like on some Windows 10 versions also pdal_wrench.exe ​https://github.com/qgis/QGIS/issues/61222 and untwine.exe ​https://github.com/qgis/QGIS/issues/61222#issuecomment-2760570138 have the same issue also disrupting the Point Cloud functionalities in QGIS.

The msvcp140.dll 14.32.31332.0 in my system32 folder has the creation and last modified date June 10th, 2022, and it was almost certainly installed by the latest Microsoft Visual C++ 2015-2022 Redistributable (x64) - 14.32.31332 installed in my system.

No other non-OSGeo4W application crashes on my system due to msvcp140.dll in system32.

If there is no way to enforce the use of the one shipped by OSGeo4W instead of the one installed in the system, then maybe the Setup program should check the msvc version installed in the system and either trigger a newer version installation or warn the user, or maybe a note should be put in the Windows download page about the minimum msvc version needed for Windows 10/11.

[Andreas Müller]

I can't tell what is wrong with your installation, but I check the path, because Osgeo4w\bin should come before system pathes. That is set usually by the provided batch files. Try running the Osgeo4w-Shell and from there call the batch flle of your applications.

[andreaerdna]

According to ​https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order and ​https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security, if "the application is not using an alternate search order", the system folder comes before the directories that are listed in the PATH environment variable, while the folder where the application resides comes before the system folder.

In fact it seems to me that bin\qgis(*).exe uses the msvcp140.dll available in the bin folder, while apps\saga\saga_gui.exe and other apps not in the bin folder (e.g. apps\qgis(*)\untwine.exe, apps\qgis(*)\pdal_wrech.exe) use msvcp140.dll available in the system folder.

Anyway, SAGA-GIS crashes (MSVCP140.dll) and fails to start even executing the saga_gui command in the OSGeo4W Shell (the path is PATH=C:\OS5C2A~1\apps\qt5\bin;C:\OS5C2A~1\apps\Python312\Scripts;C:\OS5C2A~1\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBem).

[jef]

Replying to andreaerdna:

Why GRASS-GIS and SAGA-GIS (and other ones) executable don't use the msvcp140.dll shipped by OSGeo4W with the msvcrt2019 package (shouldn't it be named msvcrt2022)? Is there a way to enforce the use of the one shipped by OSGeo4W instead of the one installed in the system (apart from copying the msvcp*.dll in the same folder of the executable)?

No. That's the problem. QGIS (and python) use AddDllDirectory internally to make sure system32 doesn't take priority over PATH - but that's not the default. By default the directory of a DLL or EXE has the highest priority - that's why copying the runtime everywhere helps, then system32, then whatever is in PATH.

See ​https://github.com/qgis/QGIS/blob/master/src/app/mainwin.cpp#L135 and ​https://github.com/jef-n/OSGeo4W/blob/master/src/python3/osgeo4w/package.sh#L159.

My question is why this is a problem all of a sudden on some machines. I'm not aware of any updates in OSGeo4W that would cause this. Installing the latest runtime would require admin rights, but I don't think that the latest one is even required - any not too ancient one should do - so I wonder why/if/how you got yours.

[andreaerdna]

On my system, saga 9.5.1-1 (GDAL/OGR 3.9) and previous ones work, while saga 9.7.1-1 (GDAL/OGR 3.10) not; grass 8.4.0-2 (GDAL/OGR 3.9) and previous ones work, while 8.4.0-5 or 8.4.1-1 (GDAL/OGR 3.10) not; untwine.exe and pdal_wrench.exe in QGIS <= 3.40.2 (GDAL/OGR 3.9) work, while in QGIS >= 3.40.3 (GDAL/OGR 3.10) not.

It looks like there is an issue for some applications built with a newer version of msvcp140 when they are run on system with some previous versions of msvcp140, see ​https://developercommunity.visualstudio.com/t/Builds-against-MSVC-Redistributable-144/10690723?sort=newest, and the issue is due to a change in mutex contructor in VS 2022 17.10 ​https://developercommunity.visualstudio.com/t/Access-violation-in-_Thrd_yield-after-up/10664660#T-N10668856.

In fact, renaming all the msvcp* dlls in bin folder in order to force also QGIS and other libraries to use the msvcp* dlls available in the system, even executing gdalinfo --version in the OSGeo4W shell crashes (MSVCP140.DLL) after reporting the GDAL version, and QGIS crashes when it is closed:

Stack Trace

mtx_do_lock mutex.cpp:103
CPLODBCDriverInstaller::RemoveDriver :
CPLODBCDriverInstaller::RemoveDriver :
CPLODBCDriverInstaller::RemoveDriver :
CPLODBCDriverInstaller::RemoveDriver :
QgsApplication::exitQgis :
QgisApp::~QgisApp :
QList::operator+= :
main :
BaseThreadInitThunk :
RtlUserThreadStart :

So... maybe the issue has been is actually triggered by GDAL/OGR 3.10 build.

See also ​https://github.com/OSGeo/gdal/pull/10224, ​https://github.com/actions/runner-images/issues/10004#issuecomment-2153445161, ​https://github.com/OSGeo/gdal/commit/5a9ef441292b5a92ab58fe54a9fcdab5b1e58bdd

[jef]

Thanks for the insight. Please check whether gdal 3.10.2-3 fixes this.

[andreaerdna]

Great! It seem to me all the reported issues with SAGA-GIS, untwine and pdal_wrench are now fixed with gdal 3.10.2-2. Also GRASS-GIS modules no longer crash even removing all the msvc*.dll and vc*.dll from apps\grass\grass84\bin.

[andreaerdna]

It works with gdal 3.10.2-3, too.

[andreaerdna]

For the record, the issue also affected qgis_process ​https://github.com/qgis/QGIS/issues/61320