Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-23038

Service registered with deprecated "mysqld.exe --install" crashes on startup

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.5.4
    • 10.5.5
    • Platform Windows, Server
    • None
    • Windows 10 18363

    Description

      Today i tried upgrading from 10.4.13 to 10.5.4 without success. On my windows machine i've installed Mariadb as a service.

      When i upgrade mariadb server files and than want to start the server again, it crashes instantly. In windows errors logs i have the following error message.

      I've seen that with 10.5.x the ucrtbase.dll is not shipped anymore with the "bin" folder of mariadb. Now this missing module is taken from my Windows/System32 folder which results in a crash, maybe because it's incompatible with mariadb.

      I cannot get it to work. I have reverted back to 10.4.13 which works like a charm.

      Name der fehlerhaften Anwendung: mysqld.exe, Version: 10.5.4.0, Zeitstempel: 0x5ef224e3
      Name des fehlerhaften Moduls: ucrtbase.dll, Version: 10.0.18362.815, Zeitstempel: 0x32a6df9a
      Ausnahmecode: 0xc0000005
      Fehleroffset: 0x0000000000023838
      ID des fehlerhaften Prozesses: 0x314c
      Startzeit der fehlerhaften Anwendung: 0x01d64dd9d949e3c3
      Pfad der fehlerhaften Anwendung: c:\srv\mariadb\bin\mysqld.exe
      Pfad des fehlerhaften Moduls: C:\Windows\System32\ucrtbase.dll
      Berichtskennung: fac4cfb2-9443-4387-bd34-598660c851dc
      Vollständiger Name des fehlerhaften Pakets: 
      Anwendungs-ID, die relativ zum fehlerhaften Paket ist: 
      

      Attachments

        Issue Links

          Activity

            BrainFooLong Roland created issue -
            wlad Vladislav Vaintroub added a comment - - edited

            It crashes it one of the ucrtbase.dll functions, but not because we do not ship ucrtbase.dll. This dll is part of your Windows 10. If it is part of OS (and it is since Windows 8.1) , It will always load from system32, whether it is put into executable directory, or not. And anything prior to Windows 8.1 had already reached end of life, thus there is no whatever reason to put it into executable's directory.

            And it crashes because there is some bug in mariadb.

            Would it be possible to provide at least the error log, and ideally also the crash dump? And all supplemental files, like e.g my.ini

            wlad Vladislav Vaintroub added a comment - - edited It crashes it one of the ucrtbase.dll functions, but not because we do not ship ucrtbase.dll. This dll is part of your Windows 10. If it is part of OS (and it is since Windows 8.1) , It will always load from system32, whether it is put into executable directory, or not. And anything prior to Windows 8.1 had already reached end of life, thus there is no whatever reason to put it into executable's directory. And it crashes because there is some bug in mariadb. Would it be possible to provide at least the error log, and ideally also the crash dump? And all supplemental files, like e.g my.ini
            wlad Vladislav Vaintroub made changes -
            Field Original Value New Value
            Labels need_feedback
            BrainFooLong Roland made changes -
            Attachment mariadb.zip [ 52426 ]
            BrainFooLong Roland added a comment - - edited

            Thanks for your answer. I'll provide all information as wanted. To the my.ini. I've provided 2 files, one stripped down to our minimums, even with that it doesn't work. The ucrtbase.dll is the one from my windows/system32 folder. Also there is no error log in the error log destination file. Errors just only show up in syslog from windows event viewer. mariadb.zip

            BrainFooLong Roland added a comment - - edited Thanks for your answer. I'll provide all information as wanted. To the my.ini. I've provided 2 files, one stripped down to our minimums, even with that it doesn't work. The ucrtbase.dll is the one from my windows/system32 folder. Also there is no error log in the error log destination file. Errors just only show up in syslog from windows event viewer. mariadb.zip

            Thank you. the last and the the most interesting one, would be
            C:\ProgramData\Microsoft\Windows\WER\Temp\WER21A1.tmp.dmp (taking the name of the crash dump from the windows event log,or under whatever name the crash dump is saved)

            wlad Vladislav Vaintroub added a comment - Thank you. the last and the the most interesting one, would be C:\ProgramData\Microsoft\Windows\WER\Temp\WER21A1.tmp.dmp (taking the name of the crash dump from the windows event log,or under whatever name the crash dump is saved)

            And if not there, then "möglicherweise" there C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_mysqld.exe_e4f99a763f7ceb1563f76a1a352eb93224d66522_31d2382f_a4f3c35d-16a6-4fd4-b973-c57f8bcf3371

            wlad Vladislav Vaintroub added a comment - And if not there, then "möglicherweise" there C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_mysqld.exe_e4f99a763f7ceb1563f76a1a352eb93224d66522_31d2382f_a4f3c35d-16a6-4fd4-b973-c57f8bcf3371
            BrainFooLong Roland made changes -
            Attachment Report.zip [ 52427 ]
            BrainFooLong Roland added a comment -

            Unfortunately there is just the "AppCrash" file that exist, all other files logged in the error log doesn't exist after the crash. I've uploaded those. Report.zip

            BrainFooLong Roland added a comment - Unfortunately there is just the "AppCrash" file that exist, all other files logged in the error log doesn't exist after the crash. I've uploaded those. Report.zip

            BrainFooLong^ , could you provide the WER crash dump, please? Thank you!

            wlad Vladislav Vaintroub added a comment - BrainFooLong ^ , could you provide the WER crash dump, please? Thank you!
            BrainFooLong Roland added a comment -

            I would, if the files would exist. There are no WER crash dumps, even if they are listed in the log.

            BrainFooLong Roland added a comment - I would, if the files would exist. There are no WER crash dumps, even if they are listed in the log.

            its a pity. For such things, crash dump is really important.

            maybe you can run

            procdump -mp -x . mysqld.exe <args>

            from the command line (let's try elevated command line just in case) rather than from service
            where <args> are mostly likely --defaults-file=<path\to\my.ini>

            Then the .dmp will be written in the current working directory

            https://docs.microsoft.com/en-us/sysinternals/downloads/procdump contains the information about the procdump utility and the link to download.

            wlad Vladislav Vaintroub added a comment - its a pity. For such things, crash dump is really important. maybe you can run procdump -mp -x . mysqld.exe <args> from the command line (let's try elevated command line just in case) rather than from service where <args> are mostly likely --defaults-file=<path\to\my.ini> Then the .dmp will be written in the current working directory https://docs.microsoft.com/en-us/sysinternals/downloads/procdump contains the information about the procdump utility and the link to download.
            BrainFooLong Roland added a comment -

            Ok, thanks for that hint. But, to make things worse, i've now tried various things and it turns out that i CAN start mysqld by hand with command line, with or without providing the path to the ini.

            If i just start from command line (with and without elevated user), the mysqld starts fine and database is working correct.

            But if i want to start it from windows services, it doesn't work, no matter what i try. By default, the service run as system user. I tried several users, admin, normal and system user. No user can start mysqld from the service window, but every user can start directly from command line.

            I've also tried deleting and re-installing the service with "mysqld --install MariaDB". Doesn't help.

            For that reason, i cannot give you a dump when it crashes, because i cannot intercept the service call that crashes with procdump.

            I don't know what to do now. All logs that i have when it crashes are already uploaded here.

            BrainFooLong Roland added a comment - Ok, thanks for that hint. But, to make things worse, i've now tried various things and it turns out that i CAN start mysqld by hand with command line, with or without providing the path to the ini. If i just start from command line (with and without elevated user), the mysqld starts fine and database is working correct. But if i want to start it from windows services, it doesn't work, no matter what i try. By default, the service run as system user. I tried several users, admin, normal and system user. No user can start mysqld from the service window, but every user can start directly from command line. I've also tried deleting and re-installing the service with "mysqld --install MariaDB". Doesn't help. For that reason, i cannot give you a dump when it crashes, because i cannot intercept the service call that crashes with procdump. I don't know what to do now. All logs that i have when it crashes are already uploaded here.
            wlad Vladislav Vaintroub made changes -
            Assignee Vladislav Vaintroub [ wlad ]
            wlad Vladislav Vaintroub made changes -
            Summary Cannot run/crash 10.5.4 on windows because of ucrtbase.dll Service registered with deprecated "mysqld.exe --install" do not start
            wlad Vladislav Vaintroub added a comment - - edited

            I fixed the title to reflect what actually happened. The mysqld --install is the culprit, if you just told it from the start on.

            For temporary workaround, you can hack in a registry
            Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MariaDB
            Change "ImagePath" value to be

            c:\srv\mariadb\bin\mysqld.exe "--defaults-file=C:\srv\mariadb\data\my.ini" mariadb

            And yes, you'd need a valid --defaults-file, a different path is OK

            wlad Vladislav Vaintroub added a comment - - edited I fixed the title to reflect what actually happened. The mysqld --install is the culprit, if you just told it from the start on. For temporary workaround, you can hack in a registry Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MariaDB Change "ImagePath" value to be c:\srv\mariadb\bin\mysqld.exe "--defaults-file=C:\srv\mariadb\data\my.ini" mariadb And yes, you'd need a valid --defaults-file, a different path is OK
            wlad Vladislav Vaintroub made changes -
            Summary Service registered with deprecated "mysqld.exe --install" do not start Service registered with deprecated "mysqld.exe --install" crashes on startup
            wlad Vladislav Vaintroub made changes -
            Labels need_feedback
            wlad Vladislav Vaintroub made changes -
            Component/s Platform Windows [ 10138 ]
            Component/s Server [ 13907 ]
            Fix Version/s 10.5.5 [ 24423 ]
            Resolution Fixed [ 1 ]
            Status Open [ 1 ] Closed [ 6 ]
            BrainFooLong Roland added a comment -

            Thanks. I can confirm that the regedit hack does work. I see that with 10.5.5 this already should be fixed. Need we need to re-install services with 10.5.5 in order to fix this issue?

            BrainFooLong Roland added a comment - Thanks. I can confirm that the regedit hack does work. I see that with 10.5.5 this already should be fixed. Need we need to re-install services with 10.5.5 in order to fix this issue?

            I think it would be a fine to just live with registry "hack" for the time being. Unless you specifically want to test 10.5.5 fix, when it comes out. The registry structure like this is completely legit, this is how better supported mysql_install_db.exe would create it, 2 parameters for mysqld, rather than 1 (defaults-file and service name)

            wlad Vladislav Vaintroub added a comment - I think it would be a fine to just live with registry "hack" for the time being. Unless you specifically want to test 10.5.5 fix, when it comes out. The registry structure like this is completely legit, this is how better supported mysql_install_db.exe would create it, 2 parameters for mysqld, rather than 1 (defaults-file and service name)
            BrainFooLong Roland added a comment -

            Ok. We have a lot of long running MariaDb servers that will need the fix. I'll stick with a fixed .reg file that i just need to run once on each server.
            This should probably be mentioned in upgrade notes here -> https://mariadb.com/kb/en/upgrading-from-mariadb-104-to-mariadb-105/ as it is a breaking change for this specific case.

            BrainFooLong Roland added a comment - Ok. We have a lot of long running MariaDb servers that will need the fix. I'll stick with a fixed .reg file that i just need to run once on each server. This should probably be mentioned in upgrade notes here -> https://mariadb.com/kb/en/upgrading-from-mariadb-104-to-mariadb-105/ as it is a breaking change for this specific case.
            wlad Vladislav Vaintroub made changes -
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 110592 ] MariaDB v4 [ 158034 ]

            People

              wlad Vladislav Vaintroub
              BrainFooLong Roland
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.