MySQL Bugs: #64909: MySQL server does not start after upgrade

Bug #64909	MySQL server does not start after upgrade
Submitted:	8 Apr 2012 9:35	Modified:	27 Feb 2013 9:47
Reporter:	Peter Laursen (Basic Quality Contributor)	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S1 (Critical)
Version:	5.5.22, 5.5.23, 5.6.5	OS:	Windows (7/64)
Assigned to:		CPU Architecture:	Any
Tags:	qc

Description:
I experience that after upgrade 5.5.20 > 5.5.22 the server does not start.

How to repeat:
I do as I have been doing 100 times before: simply doubleclick the .msi installer, let the installation complete and next skip the config wizard (in order to use existing configuration from 5.5.20) by unnchecking 'configure the server now'.

I first thought that the reason could be that some option in the existing my.ini was not supported anymore. But that is not the case. There is no problem with the .ini. It is the datadir from 5.5.20 that does not work with 5.5.22. The server starts with with the empty datadir created by the installer in the installation folder.

(Before upgrading 5.5 I uninstalled 5.6.4 because of a known bug that 5.5 cannot be upgraded using the .msi installer if a 5.6 version is installed (http://bugs.mysql.com/bug.php?id=56889).

I had to uninstall 5.5 completely and delete all files (including datadir) to get 5.2.22 up and running

Actually I experienced the same when (after what is described above) I was installing 5.6.5 (maybe there is no official 5.6.5 release experience but it is available from mirrors since yesterday) afterwards. The server installed but would not start. Only after uninstalling again and deleting all files belonging to 5.6 (including datadir) I was able to succesfull install and start 5.6 again. I did not spend time with that because I have nothing important stored with 5.6)

Suggested fix:
I have a backup of the /datadir that used to run perfectly with 5.5.20. I intended to download 5.5.20 in order to verify but it has been removed from mirrors (see ftp://ftp.easynet.be/mysql/Downloads/MySQL-5.5/ - 5.5.21 is the oldest there).

Can I download the 5.5.20 ZIP-package for Windows (64 bit) from somewhere so that I can verify that this old datadir runs with 5.5.20? I also have lost a few important tables I would like to recover as it would save me lots of time. They are InnoDB tables and thus a simple file copy is not possible (and yes .. I should have backed them up in a more accessible form - like a SQL dump or a CSV for instance!)

First of all, you can download older versions from archives (check Archive at dev.mysql.com). URL to all kinds of 5.5.20 binaries for your case is:

http://downloads.mysql.com/archives.php?p=mysql-5.5&v=5.5.20

Then, had you checked that my.ini file used by MySQL service (mysql55 or whatever) after upgrade points to proper datadir?

Last question: I did not overwrite the my.ini and it pointed to \Program Data.  Please see my description.  I simply did not change/modify/overwrite the .ini or the /datadir at all. I skipped the config wizard. It has worked for me like this 100 times before.

I will try to connect to the old datadir with 5.5.20.  If successful I will dump and drop the few tables with private data and attach the datadir.  It is < 20 MB zipped so this should be OK for the ftp upload.

(but annoying that http://bugs.mysql.com/bug.php?id=56889 is not fixed! Vladislav Vaintrub tells me (on MariaDB mailing list) that he prepared a fix and committed for review before leaving Oracle 1+ year ago.  Why can't it be committed?)

Datadir does not work with 5.5.20 either.

1) installed 5.5.20 as service 'mysqlold'

C:\mysql5520\bin>mysqld install mysqlold
Service successfully installed.

2) renamed my_medium.ini to my.ini

3) With my old /datadir that worked with 5.5.20 before upgrade server does not start

C:\mysql5520\bin>net start mysqlold
Tjenesten mysqlold starter...
Tjenesten mysqlold kunne ikke startes.

Der opstod en systemfejl.
Systemfejlen 1067 opstod.
Processen sluttede uventet.

4) With the empty datadir shipped with the server it is working fine:

C:\mysql5520\bin>net start mysqlold
Tjenesten mysqlold starter.
Tjenesten mysqlold er startet.

5) net stop mysqlold

6) trying from command-line (not as service) with the old datadir:

C:\mysql5520\bin>mysqld --skip-grant-tables --no-defaults

C:\mysql5520\bin>

.. if the server process starts at all it exits shortly (less than 1 second) after. Default port 3306 is not in use so that is not the issue.

It definitely worked before I upgraded from 5.5.20 with the old datadir. I was connected to it around 10:30 am this morning. The datadir seems to have been damaged for some reason. It could be for several reason - also unrelated to MySQL. But why did the 5.6 datadir also corrupt? I am mystified. As told what I did I have been doing 100 times before. Only complication when upgrading 5.5 is this ridiculous bug: http://bugs.mysql.com/bug.php?id=56889.

Unfortunately I am not able to share this corrupt/non-functional datadir with Oracle. I also have no idea how to do progress. I can recover/aggregate data from various tables on other servers, so it is not a showstopper issue. A few hours trivial work only.

Error log record on "mysqld ----no-defaults --skip-grant-tables"

120408 14:18:13 [Note] Plugin 'FEDERATED' is disabled.
120408 14:18:13 InnoDB: The InnoDB memory heap is disabled
120408 14:18:13 InnoDB: Mutexes and rw_locks use Windows interlocked functions
120408 14:18:13 InnoDB: Compressed tables use zlib 1.2.3
120408 14:18:13 InnoDB: Initializing buffer pool, size = 128.0M
120408 14:18:13 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file .\ib_logfile0 is of different size 0 55574528 bytes
InnoDB: than specified in the .cnf file 0 5242880 bytes!
120408 14:18:13 [ERROR] Plugin 'InnoDB' init function returned error.
120408 14:18:13 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
120408 14:18:13 [ERROR] Unknown/unsupported storage engine: InnoDB
120408 14:18:13 [ERROR] Aborting

120408 14:18:13 [Note] mysqld: Shutdown complete

I think I saw this "ib_logfile* is of different size" somewhere before - probably here or in some release notes.

I meant "mysqld --no-defaults --skip-grant-tables" .. only and obviously!

"different size .. than specified in the .cnf file". I am using "--no-defaults" option.  How does setting in .cnf file apply then? With this option the server is not supposed to read the .cnf/.ini file at all as far as I can understand http://dev.mysql.com/doc/refman/5.5/en/option-files.html#option_general_no-defaults.  

There is a my.ini inf the /basedir. It is (as told) my-medium.ini renamed to my.ini (and port setting changed to "3320" for both server and client in order not to conflict wiht 5.1 instance installed). But even this has no ib_logfile setting as far as I can see.

(But this may be an issue with the error message only when starting the server with "--no-defaults").

If it matters this /datadir origines back from May 2010 when this machine was a new machine and I installed the latest MySQL 5.5x version available at the time using .msi installer and config wizard. I have upgraded several times (only rarely skipping a 'minor' version) exactly like I did today without problems (possibly except for one early upgrade where I had to remove some discontinued option from my.ini - but that situation could also have been with 5.1x - I do not remember this now)

IMHO everything is clear based on this message:

InnoDB: Error: log file .\ib_logfile0 is of different size 0 55574528 bytes
InnoDB: than specified in the .cnf file 0 5242880 bytes!

in the existing datadir that left from some previous version you have ib_logfile* files with non-default size (for whatever reason, probably because you had created them this way using some custom my.ini in the past). That's why you can NOT start up service with this datadir but without my.ini (that is, with default values for all variables). There are 2 solutions: either you remove ib_logfile* (or entire datadir) and use all defaults, or you create my.ini that has setting for innodb_log_file_size that corresponds to real ib_logfile* that exist in the datadir...

So, where is the bug here? I see user mistake (one time I use non-default configuration or configuration from some other version, but next time I want to use all default settings, just because I am lazy or for whatever reason...)

I don't see a user error. I see a bug with either the 5.5 or 5.6 installer. It could be a 'side effect' of http://bugs.mysql.com/bug.php?id=56889.

<b>I had both MySQL 5.5.20 and 5.6.4 *running perfectly* this morning. I have NOT change any configuration since then</b>. I upgraded to 5.5.22, but uninstalled 5.6.4 first 8as I had to due to bug56889). After uninstall of 5.5.22 I installed 5.6.5. It would not start either. I uninstall 5.6.5 and delete all 5.6 files in both 'Program Data' and 'Program Files'. I now install 5.6.5 again. 5.6.5 works fine. 5.5.22 does not. Only after deleting all 5.5x files and doing a fresh install it does.

I can obivously understand the error log message. But there is more than that ..

1) I delete innodb log files
2) Server does not start. it complains taht user tables are not there.
3) I start like "C:\mysql5520\bin>mysqld --skip-grant-tables"
4) Server s5.5.20 tarts now. but wiht this in error log:

120408 19:07:28 [Note] Plugin 'FEDERATED' is disabled.
mysqld: Table 'mysql.plugin' doesn't exist
120408 19:07:28 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
120408 19:07:28 InnoDB: The InnoDB memory heap is disabled
120408 19:07:28 InnoDB: Mutexes and rw_locks use Windows interlocked functions
120408 19:07:28 InnoDB: Compressed tables use zlib 1.2.3
120408 19:07:28 InnoDB: Initializing buffer pool, size = 128.0M
120408 19:07:28 InnoDB: Completed initialization of buffer pool
120408 19:07:28 InnoDB: Log file .\ib_logfile0 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
120408 19:07:28 InnoDB: Log file .\ib_logfile1 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
120408 19:07:28 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
120408 19:07:28 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
120408 19:07:29 InnoDB: Waiting for the background threads to start
120408 19:07:30 InnoDB: 1.1.8 started; log sequence number 23515148
120408 19:07:30 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
120408 19:09:00 [Note] Plugin 'FEDERATED' is disabled.
mysqld: Table 'mysql.plugin' doesn't exist
120408 19:09:00 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
120408 19:09:00 InnoDB: The InnoDB memory heap is disabled
120408 19:09:00 InnoDB: Mutexes and rw_locks use Windows interlocked functions
120408 19:09:00 InnoDB: Compressed tables use zlib 1.2.3
120408 19:09:00 InnoDB: Initializing buffer pool, size = 128.0M
120408 19:09:00 InnoDB: Completed initialization of buffer pool
120408 19:09:00 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
120408 19:09:00 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
120408 19:09:00 InnoDB: Waiting for the background threads to start
120408 19:09:01 InnoDB: 1.1.8 started; log sequence number 23515148
120408 19:09:01 [Note] Recovering after a crash using mysql-bin
120408 19:09:01 [Note] Starting crash recovery...
120408 19:09:01 [Note] Crash recovery finished.
120408 19:09:01 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
120408 19:10:53 [Note] Plugin 'FEDERATED' is disabled.
120408 19:10:53 InnoDB: The InnoDB memory heap is disabled
120408 19:10:53 InnoDB: Mutexes and rw_locks use Windows interlocked functions
120408 19:10:53 InnoDB: Compressed tables use zlib 1.2.3
120408 19:10:53 InnoDB: Initializing buffer pool, size = 128.0M
120408 19:10:53 InnoDB: Completed initialization of buffer pool
120408 19:10:53 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
120408 19:10:53 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
120408 19:10:54 InnoDB: Waiting for the background threads to start
120408 19:10:55 InnoDB: 1.1.8 started; log sequence number 23515148
120408 19:10:55 [Note] Recovering after a crash using mysql-bin
120408 19:10:55 [Note] Starting crash recovery...
120408 19:10:55 [Note] Crash recovery finished.
120408 19:10:55 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them
120408 19:10:55 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist
120408 19:10:55 [ERROR] Native table 'performance_schema'.'events_waits_current' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'events_waits_history' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'events_waits_history_long' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'setup_consumers' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'setup_instruments' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'setup_timers' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'performance_timers' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'threads' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'events_waits_summary_by_thread_by_event_name' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'events_waits_summary_by_instance' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'events_waits_summary_global_by_event_name' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'file_summary_by_event_name' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'file_summary_by_instance' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'mutex_instances' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'rwlock_instances' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'cond_instances' has the wrong structure
120408 19:10:55 [ERROR] Native table 'performance_schema'.'file_instances' has the wrong structure
120408 19:10:55 [Note] mysqld: ready for connections.
Version: '5.5.20-log' socket: '' port: 3320 MySQL Community Server (GPL)

5) After all I can now connect and dump my tables. So far so good.

6) But

SHOW TABLES FROM mysql;
/* --returns
Tables_in_mysql
-----------------
nonsense
test
*/

SHOW TABLES FROM performance_schema;
-- empty set

7) I cannot spend more time with this now (I was able to mgrate my tables and thanks), but I think you should take it seriously. At least fix bug56889 to ensure that 5.6 igores 5.5 installation and vice versa!

BTW_ can we agree taht the error messsage "\ib_logfile0 is of different size .. than specified in my.cnf" since my.ini/my.cnf is not being read at all when using "--no-defaults"?

Since I was able to connect I was also able to drop the two tables with private data.  So I can now upload the datadir including innodb log files if somebody wants to look into it.

Please, explain me the exact sequence of actions performed. Had you installed 5.5.20, then upgraded to 5.6.5, then uninstalled it and installed 5.5.22, all with the same datadir and using the same Windows service name/same .ini file?

Obviously 5.5 and 5.6 use each their own datadir as they were installed with the .msi installer - ie. C:\Program Data\MySQL\MySQL Server 5.{secondary version no} for each. This should be clear from what I already wrote, I think. besides I think you know me well enough to know that I know that two servers of different versions cannot use the same /datadir.

I cannot reconstruct the exact steps more detailed than what I already told. In is like that as far as I remember

1) I had 5.5.20 and 5.6.4 installed and both working fine.
2) I have not manually touched any configuration from here.
3) I uninstall 5.6.4 from Control Panel (as necessary because of the other bug). I do not remove any remaining files belonging to 5.6 manually.
4) I install 5.5.22 using the .msi and skip the configuration wizard (unchecking the checkbox 'configure .. now').
5) I install 5.6.5 from ftp://ftp.easynet.be/mysql/Downloads/MySQL-5.6/mysql-5.6.5-m8-winx64.msi. Also here I skip the configuration wizard.
6) I notice that 5.6.5 won't start. This instance is not important for me so I uninstall again and manually delete all files and folders related to 5.6 in both "Program Files" and "Program Data".
7) I do a fresh install of 5.6.5. This time I run the config wizard.
8) Now I notice the problems reported in the beginning of this report ... including that an innodb log file size is expected different from the size of actual/existing files.
9) So I ended up doing a fresh install of 5.5.22 as well as described. The old datadir could be used after deletion of innodb log files and whne starting server with --skip-defaults. The last error log snippet I posted reveals several problems.

Maybe it does not matter but I remember that when I upgraded to a previous 5.5 version (5.5.20 or before that) I have used the 'unified installer' once.

I have reconstructed the /datadir (with a few tables dropped) as per the start of 8) above. This (and no more) I can provide for analysis.

Please correct:

9) So I ended up doing a fresh install of 5.5.22 as well as described. The old datadir could be used after deletion of innodb log files and when starting server with --skip-grant-tables.

I can see that 5.5.23 is available.  I will upgrade when I get time (sometime next week probably) and see if problem is repeatable and be more careful to record each step exacty.

Please, share any results with 5.5.23.

There are reproducible issues with both 5.5.23 and 5.6.5 .msi installer packages if I uncheck the option to 'configure the MySQL server now" (ie. skip config wizard because I want to continue to use my existing configurations). But the problems with 5.5 and 5.6 are different.

1)
Upgrading 5.5.22 > 5.5.23 (remember: skipping config wizard):

120504 20:48:50 [Note] Plugin 'FEDERATED' is disabled.
C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Table 'mysql.plugin' doesn't exist
120504 20:48:50 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
120504 20:48:50 InnoDB: The InnoDB memory heap is disabled
120504 20:48:50 InnoDB: Mutexes and rw_locks use Windows interlocked functions
120504 20:48:50 InnoDB: Compressed tables use zlib 1.2.3
120504 20:48:50 InnoDB: Initializing buffer pool, size = 106.0M
120504 20:48:51 InnoDB: Completed initialization of buffer pool
120504 20:48:51 InnoDB: highest supported file format is Barracuda.
120504 20:48:53 InnoDB: Waiting for the background threads to start
120504 20:48:54 InnoDB: 1.1.8 started; log sequence number 146193518
120504 20:48:54 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
120504 20:49:38 [Note] Plugin 'FEDERATED' is disabled.
C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Table 'mysql.plugin' doesn't exist
120504 20:49:38 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
120504 20:49:38 InnoDB: The InnoDB memory heap is disabled
120504 20:49:38 InnoDB: Mutexes and rw_locks use Windows interlocked functions
120504 20:49:38 InnoDB: Compressed tables use zlib 1.2.3
120504 20:49:38 InnoDB: Initializing buffer pool, size = 106.0M
120504 20:49:38 InnoDB: Completed initialization of buffer pool
120504 20:49:38 InnoDB: highest supported file format is Barracuda.
120504 20:49:38 InnoDB: Waiting for the background threads to start
120504 20:49:39 InnoDB: 1.1.8 started; log sequence number 146193518
120504 20:49:39 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
(the only option to get access to data is to start the server with "mysqld --skip-grant-tables"

Now if I start the installer again and choose 'repair' option the server will start. But my user privilege details are gone.

2) Upgrading 5.6.4>5.6.5 (remember: skipping config wizard)

The service simply gets removed! 'repair' does not help. Running the config wizard or installing service with "mysqld install .." command works - service get installed and can start.

From the time where the config wizard was introduced years back until a few months ago it worked fine to skip the config wizard if you simply wanted to continue using your esiting configuration when upgrading (and since there is a a checkbox for user to choose it also should work in both cases of course!)

Due to loss of privilege data with the 5.5 upgrade process I am raising this to "S1" severity.

(and the problem here is not related to the other - verified - report that 5.5 will not upgrade if 5.6 is installed. I was also not able to reproduce that InnoDB logfiles size got changed. This time I did not have a 5.5 installed with the 'unified installer' previously and this could be the reason.)

THERE IS NO CRAP IN THE WORLD COMPARABLE TO MySQL INSTALLERS FOR WINDOWS!!

In summary:

1)
upgrading 5.5.22 > 5.5.23 skipping the config wizard destroys privilege data in the existing `mysql` database. This is SERIOUS.

2)
upgrading 5.6.4 > 5.6.5 skipping the config wizard removes the service from the system. Maybe NOT VERY SERIOUS but will still be a show-stopper for many Windows users who do not know how to install the service with "mysqld install servicename".

And 5.5.24 is now available and I have to perform this circus again-again-again.  SIGH!

I just upgraded my 5.1 instance from 5.1.62 to 5.1.63.  There was absolutely no issue even though I have both 5.5 and 5.6 installed on the system.  But upgrading 5.5 with 5.6 installed too causes all this mess.

CIRCUS ORACLIMUS coming to town again. Mostly clowns are there it seems - and no artists.

This clown says that the log file size problem is a duplicate of Bug#13494.

I solved it by adding a .exe next to the mysqld in the registry file path.
I kept getting an Error 193: 0xc1 "Could not launch the MySQL56 service on Local Computer"

This is what I did...

1) Type regedit into run and launch it.
2) Go through HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services and then search for the MySQL56 (or whatever) service. 
3)Click on the ImagePath and simply add .exe next to mysqld so that it says "mysqld.exe" (without quotation marks ofcourse)
4) Click OK and exit regedit.
5) Type service.msc into run and launch it.
6) Search for the MySQL service again, double-click it and click on Start. (Also make sure the "Startup Type" is Automatic)

If that doesn't work, click on MySQL service again and follow these steps...

1) Click on the Log On tab
2) Where it says "Log On as:" click on the "Local System Account" Radiobutton and click Apply.
3) Go back to General Tab, make sure Startup Type is on Automatic and click Start.

Hope this helps!!

Oh, and if neither works, just go back to the registry and remove that .exe from the ImagePath again so be safe. It won't do much though, as it only changes a file path.

I have not had any issues with neither the 5.5.30 'standalone' nor the 5.6.10 'integrated' installers.

I think the discussion here is going off-track! Besides I see this

[4 Oct 2012 7:33] Marko Mäkelä
This clown says that the log file size problem is a duplicate of
Bug#13494

Errhh? Who is the clown here?

Peter,

Sorry if you were offended by my reuse of your word 'clown'.

I think that the root cause of the problem is mentioned in your comment:

[8 Apr 2012 12:20] Peter Laursen 
[...]
InnoDB: Error: log file .\ib_logfile0 is of different size 0 55574528 bytes
InnoDB: than specified in the .cnf file 0 5242880 bytes!

This is the very issue that I fixed in WL#6494 (included in MySQL 5.6.8), making the innodb redo log file resizeable. On size difference, we would make a log checkpoint, discard the old log files and create new ones.

There were numerous bugs reported on this issue over the years. I must have closed more than 10 bugs that I was able to find.

This one was not the only bug that was filed against a Windows installer or administration tool. If you think that the Windows tools could show the server log on failure, or should more prominently tell to check the error log, maybe that deserves another bug.

Again, sorry for trying to crack a joke when closing the bugs.