viewhero, can you send the installation log, please?
you can create it with msiexec.exe /i path-to-package.msi /l*v path-to-logfile.txt

Did you upgrade on top of 10.4.12? Did installation of the latest VS2019 runtime help?

mariadb-log.txt

Hi, Vladislav.
I got log file and screen shot.
Anyway, 10.4.13 windows msi cannot be installed.

I tested 3 environments.

1. upgrade from 10.4.12. PC has Visual Studio 2017&2019 .
It was OK to upgrade.

2. upgrade from 10.4.12. None of Visual Studio.
It was failed. Error screen was displayed.(same to finish.jpg)

3. new install 10.4.13. Clearn PC.
It was failed. Error screen was displayed.
Attached log was got from this PC.
Instration was failed. also, MariaDB windows service was not installed.

Please, check it.
Thank you.

well, the reboot prompt in finish.jpg, or in the MSI log, it is MSIs own magic, that we can't prevent. It is not a bug by itself, you can choose to continue and restart. You stopped the installation before it became "interesting"

Failure for the mariadb service to start, that's bug. I can already guess where it is, we used some outdated merge modules that did not include
vcruntime140_1.dll . That needs to be fixed, but in the meantime for you, installing the newest vc_redist would help

https://github.com/MariaDB/server/commit/3bfe305c5cd678a8563f7a76d6ed59095129007e will probably solve that

viewhero , I put a new build of mariadb MSI to my OneDrive share , here https://1drv.ms/u/s!AKT4tBcElQz_j5Ej

I'd appreciate if you can test it on clean PC, as I do not have anything like that clean PC right at the moment.
Note, it is 10.4.14, but the difference between 10.4.13 release is only this small change in packaging I mentioned aboved.

Thank you for uploading fixed version.

I test 2 environment.
1. upgrade from 10.4.12.
2. new install.

Both of tests are OK.
MariaDB service was started completely.

This problem is resolved.
Thank you.

changed title to be better googleable

The installer refuses to run on Windows Server 2008, saying "The application is only supported on Windows 10 and Windows 2016".

Downloading and unpacking the ZIP shows the error 0xc0000022 (STATUS_ACCESS_DENIED).

D:\>cd mariadb-10.5.4-winx64

D:\mariadb-10.5.4-winx64>bin\mysqld --help

D:\mariadb-10.5.4-winx64>echo %errorlevel%

-1073741790

mariadb-admin.exe and other tools work.

As I used Cygwin's unzip, it assigned mis-ordered Windows ACL permissions to the files. But fixing the permissions, including the recursive inheritance, giving myself full control, did not resolve the issue.

Attaching the process monitor with a filter "process name includes mariadbd".

mariadbd-access-denied.CSV

The full log shows some BUFFER_OVERFLOW result in Symantec antivirus trying to read a registry value around the same time.

HKLM\SOFTWARE\Wow6432Node\Symantec\Symantec Endpoint Protection\{E23CB818-6B41-4447-B087-E6EFCA77415F}\Common Client\PathExpansionMap\installdir32

mariadbd-access-denied-with-others.CSV

Perhaps, it's about Symantec's failing to validate Microsoft's SHA-2 signatures.

https://www.zdnet.com/article/symantec-cannot-handle-sha-2-and-breaks-windows-7-and-server-2008-r2/

My naive stripping the files in bin and lib of their signatures using https://github.com/ng-pe/RemoveSignCode possibly got me further where I got another error

0xC0000139

STATUS_ENTRYPOINT_NOT_FOUND

The event log had this in the System folder,

mariadbd.exe - Entry Point Not Found

The procedure entry point GetSystemTimePreciseAsFileTime could not be located in the dynamic link library KERNEL32.dll.

See, there is an actual reason why 10.5 msi did not want to install on EOLed Windows. I also think you took unrelated bug report for commenting eelgheez

Sorry to hijack the solved issue. (But the not-in-my-backyard vision of the older Windows versions made me step away from trying MariaDB, sorry. I doubt that getting a system time could not be interpolated for the older Windows).

It is not about getting system time. It is about getting precise system time. We would not use that function GetSystemTimePreciseAsFileTime just for the sake of forcing you off the obsolete Windows version (abandoned by its vendor), because that function is also more expensive than the non-precise variation GetSystemTimeAsFileTime we used previously.