DEV Community

Cover image for MySQL Shutdown Unexpectedly XAMPP: Safe Fix
Faizan
Faizan

Posted on Originally published at headsntail.com

MySQL Shutdown Unexpectedly XAMPP: Safe Fix

#php #beginners #tutorial

The worst mistake after seeing "MySQL shutdown unexpectedly" in XAMPP is deleting database files before reading the error log. Many tutorials recommend removing ibdata1, replacing the entire data directory or copying random files from mysql\backup. Those actions can turn a recoverable startup problem into permanent database loss.

When XAMPP displays "Error: MySQL shutdown unexpectedly", it only means the database server started and then exited. The Control Panel doesn't identify the underlying cause. The actual explanation is usually in MariaDB's error log.

Quick answer: Open C:\xampp\mysql\data\mysql_error.log and read the latest error messages. If port 3306 is occupied, stop the conflicting service or change XAMPP's port. If Aria recovery fails, back up the entire data directory before repairing logs. If InnoDB reports corruption, preserve all database files and use controlled recovery rather than deleting ibdata1.

This guide assumes XAMPP is installed in C:\xampp. Replace that path if your installation is elsewhere.

What "MySQL shutdown unexpectedly" actually means

The XAMPP Control Panel commonly displays:

Error: MySQL shutdown unexpectedly.
This may be due to a blocked port, missing dependencies,
improper privileges, a crash, or a shutdown by another method.
Press the Logs button to view error logs and check
the Windows Event Viewer for more clues.
Enter fullscreen mode Exit fullscreen mode

This message isn't a database diagnosis.

It means the Control Panel attempted to start the database server, but the process did not remain running.

One detail causes confusion: the XAMPP Control Panel labels the database service MySQL, but many Windows XAMPP packages actually include MariaDB.

For example, Apache Friends' Windows XAMPP releases with PHP 8.0.30, 8.1.25 and 8.2.12 bundle MariaDB 10.4.32.

Other XAMPP packages may contain different MariaDB versions.

That matters because MariaDB changed parts of its InnoDB redo-log handling between versions.

Don't follow recovery instructions written for another version without checking your installation.

Official XAMPP download information:

https://www.apachefriends.org/download.html

Find the real MariaDB error

Open:

C:\xampp\mysql\data\mysql_error.log
Enter fullscreen mode Exit fullscreen mode

Alternatively, click Logs beside MySQL in the XAMPP Control Panel and select the database error log.

The default configuration file is:

C:\xampp\mysql\bin\my.ini
Enter fullscreen mode Exit fullscreen mode

Some installations use a different error-log filename or data directory. If the expected log is missing, inspect the log_error and datadir settings in my.ini.

Read the messages from the latest startup attempt.

Don't focus only on the final line saying:

[ERROR] Aborting
Enter fullscreen mode Exit fullscreen mode

That line tells you the server stopped.

The useful explanation usually appears immediately before it.

Here are common messages and what they indicate.

Error-log message Likely cause
Do you already have another server running on port: 3306? Another process is using port 3306
Aria recovery failed Aria crash-recovery logs or tables may be damaged
Can't lock aria control file Another MariaDB instance may already be using the same data directory
Can't open and lock privilege tables System-table corruption, permissions or another storage-engine problem
Operating system error number 32 Windows file-sharing violation or another process holding the file
Operating system error number 13 Access or permission problem
Plugin 'InnoDB' registration as a STORAGE ENGINE failed InnoDB initialization failed; inspect the preceding errors

If mysql_error.log isn't being updated, check:

Event Viewer → Windows Logs → Application

Look for MariaDB or MySQL events around the time of the failure.

Back up your data before attempting repairs

This step should happen before any modification involving database files.

First, stop MySQL from the XAMPP Control Panel.

Then confirm the relevant mysqld.exe or mariadbd.exe process is no longer running.

Open PowerShell:

Get-Process mysqld,mariadbd -ErrorAction SilentlyContinue |
    Select-Object Id, ProcessName, Path
Enter fullscreen mode Exit fullscreen mode

No result means Windows currently reports no matching running process.

If a process appears, identify which database instance it belongs to before stopping anything.

A running database process may be handling another application.

Don't terminate it blindly.

Once the affected MariaDB instance is stopped, make a physical backup.

The following PowerShell script copies the entire XAMPP data directory to a timestamped folder. Change the destination drive to one with sufficient free space.

$source = 'C:\xampp\mysql\data'
$backupRoot = 'D:\xampp-mysql-backups'

if (-not (Test-Path -LiteralPath $source -PathType Container)) {
    throw "Source data directory not found: $source"
}

$running = Get-Process mysqld,mariadbd -ErrorAction SilentlyContinue

if ($running) {
    throw 'A MariaDB/MySQL process is running. Identify and stop the affected instance before copying database files.'
}

New-Item -ItemType Directory -Path $backupRoot -Force | Out-Null

$destination = Join-Path $backupRoot (
    'data-' + (Get-Date -Format 'yyyyMMdd-HHmmss')
)

New-Item -ItemType Directory -Path $destination -ErrorAction Stop | Out-Null

Copy-Item -Path (Join-Path $source '*') `
    -Destination $destination `
    -Recurse `
    -Force `
    -ErrorAction Stop

Write-Host "Backup copy completed: $destination"

Get-ChildItem -LiteralPath $destination -Force |
    Select-Object Name, Length
Enter fullscreen mode Exit fullscreen mode

The script creates a separate copy without modifying the original data folder.

Before proceeding, compare the copied folder with the source, confirm that important database files are present, and retain the backup untouched.

A copied data directory is useful for recovery, but it isn't a substitute for tested SQL backups.

A physical copy taken after a crash may contain the same corruption as the original.

Keep it anyway. It preserves the state needed for further recovery attempts.

Never replace ibdata1, .ibd files or redo logs before preserving the original files.

Fix port 3306 conflicts without touching database files

Port conflicts are among the simplest causes of a XAMPP startup failure.

They can happen when another database installation already runs on Windows.

Examples include:

  • MySQL installed separately through MySQL Installer.
  • Another MariaDB Windows service.
  • WampServer or Laragon.
  • A local Docker container exposing port 3306.
  • XAMPP's own database server already running as a Windows service.

In this situation, the database files may be completely healthy.

Deleting anything from mysql\data would solve nothing.

Step 1: Identify the process using port 3306

Open Command Prompt:

netstat -ano | findstr :3306
Enter fullscreen mode Exit fullscreen mode

Look for a LISTENING entry.

For example:

TCP    0.0.0.0:3306    0.0.0.0:0    LISTENING    4528
Enter fullscreen mode Exit fullscreen mode

The last number is the Process ID.

Check which program owns it:

tasklist /SVC /FI "PID eq 4528"
Enter fullscreen mode Exit fullscreen mode

Replace 4528 with the PID shown on your computer.

The command identifies the executable and, where applicable, the associated Windows service.

If several lines appear in netstat, identify the actual listening process rather than selecting a random established connection.

Step 2: Stop the conflicting database service

Press:

Win + R

Enter:

services.msc
Enter fullscreen mode Exit fullscreen mode

Look for the service identified in the previous step.

It might be named:

MySQL80
MariaDB
mysql
Enter fullscreen mode Exit fullscreen mode

The actual service name depends on the installation.

If the service belongs to another application, confirm that the application doesn't need it before stopping it.

If it's unused, stop the service and consider changing its startup type to Manual.

Don't uninstall a database service simply because XAMPP cannot start.

The other installation may contain important databases.

Step 3: Change XAMPP to port 3307 if both servers are needed

If you need both database servers running, assign them different TCP ports.

First, back up:

C:\xampp\mysql\bin\my.ini
Enter fullscreen mode Exit fullscreen mode

Open the original configuration file.

Find the server configuration:

[mysqld]
port=3306
Enter fullscreen mode Exit fullscreen mode

Change it to:

[mysqld]
port=3307
Enter fullscreen mode Exit fullscreen mode

If your configuration contains a client section, update its port too:

[client]
port=3307
Enter fullscreen mode Exit fullscreen mode

Check for other active port settings and confirm which option groups your server uses.

Save the file.

Next, in the XAMPP Control Panel open:

Config → Service and Port Settings → MySQL

Change Main Port to:

3307
Enter fullscreen mode Exit fullscreen mode

This Control Panel setting must agree with the actual server configuration.

Changing the displayed port in the Control Panel alone doesn't necessarily change the MariaDB listener.

Step 4: Update phpMyAdmin

Open:

C:\xampp\phpMyAdmin\config.inc.php
Enter fullscreen mode Exit fullscreen mode

Find the relevant server configuration.

For a TCP connection to the changed port, use:

$cfg['Servers'][$i]['host'] = '127.0.0.1';
$cfg['Servers'][$i]['port'] = '3307';
Enter fullscreen mode Exit fullscreen mode

Place these settings in the existing server configuration section.

Don't create duplicate server definitions.

The host setting matters because phpMyAdmin documents special handling for localhost. Using 127.0.0.1 explicitly selects TCP and avoids ambiguity about a nondefault port.

See the official phpMyAdmin configuration documentation:

https://docs.phpmyadmin.net/en/latest/config.html

Step 5: Update Laravel's database configuration

If your Laravel project uses the local XAMPP database, open its .env file.

Set:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3307
Enter fullscreen mode Exit fullscreen mode

Keep the existing database name, username and password.

Then, from the Laravel project directory, run:

php artisan config:clear
Enter fullscreen mode Exit fullscreen mode

This removes Laravel's cached configuration so the updated connection settings can take effect.

Before running any migration or database-changing command, confirm .env points to the intended local database rather than a production server.

Verify the port change

Open Command Prompt:

netstat -ano | findstr :3307
Enter fullscreen mode Exit fullscreen mode

Look for a listening process.

Then test the server directly:

C:\xampp\mysql\bin\mysql.exe -h 127.0.0.1 -P 3307 -u root -p -e "SELECT VERSION();"
Enter fullscreen mode Exit fullscreen mode

Enter the configured database password when prompted.

If your local root account has an empty password, submit an empty password at the prompt.

A successful response means the client connected to the database server and executed the query.

Also verify phpMyAdmin and your Laravel application.

If MySQL starts successfully after changing the port, the original problem was a listener conflict. No database recovery was necessary.

Recover damaged Aria logs and system tables safely

If the error log contains:

Aria recovery failed.
Please run aria_chk -r on all Aria tables
Enter fullscreen mode Exit fullscreen mode

the problem is different from a port conflict.

MariaDB uses the Aria storage engine for various system tables and internal operations.

After an interrupted write or improper shutdown, Aria's crash-recovery logs may become damaged.

This can prevent MariaDB from starting even if your application databases are otherwise intact.

The relevant files normally include:

C:\xampp\mysql\data\aria_log.00000001
C:\xampp\mysql\data\aria_log_control
Enter fullscreen mode Exit fullscreen mode

Other numbered aria_log files may exist.

These files have different purposes.

aria_log.######## files record changes used for Aria recovery.

aria_log_control stores control information, including the current logging state and checkpoint information.

Don't treat the control file as disposable.

Fix A: Aria recovery log is damaged

This procedure is appropriate only when the error specifically identifies Aria crash-log recovery as the problem.

First:

  1. Stop the affected MariaDB instance.
  2. Confirm no process is using its data directory.
  3. Complete and verify a physical backup.
  4. Preserve the original log files.

Create a folder outside the active data directory:

C:\xampp\mysql\aria-recovery-old
Enter fullscreen mode Exit fullscreen mode

With MariaDB stopped, move only the numbered files matching this pattern:

aria_log.00000001
aria_log.00000002
Enter fullscreen mode Exit fullscreen mode

The actual numbered files will depend on your installation.

Do not move ordinary database files.

Do not move ibdata1.

Do not move ib_logfile0 or ib_logfile1.

Normally, leave aria_log_control in place.

Restart MySQL from the XAMPP Control Panel.

If the problem was limited to damaged Aria recovery logs, MariaDB may recreate the necessary log files and start.

That doesn't prove all tables are undamaged.

Recent Aria changes not fully recovered from the logs may have been lost. Some tables may require additional repair.

MariaDB documents this recovery approach in its Aria FAQ and storage-engine documentation:

https://mariadb.com/docs/server/server-usage/storage-engines/aria/aria-faq

What if aria_log_control is corrupted?

A damaged control file is a separate case.

For example, the log might report:

Missing valid id at start of file.
File is not a valid aria control file
Enter fullscreen mode Exit fullscreen mode

MariaDB's documentation describes recreating the control file together with the Aria logs when the control file itself is corrupted.

That is not a routine cleanup action.

Removing a valid control file can cause MariaDB to treat existing Aria tables as if they were moved from another server and trigger checks or recovery work.

Only consider isolating it when the error specifically identifies control-file corruption and a verified backup exists.

Fix B: Repair an individual damaged Aria table

If MariaDB starts but reports an Aria table as crashed, use SQL-level checks first.

For example:

CHECK TABLE mysql.global_priv;
Enter fullscreen mode Exit fullscreen mode

This checks the specified table and returns diagnostic information.

Don't automatically repair every database table because one system table reported a problem.

If a specific Aria table requires offline repair, MariaDB provides aria_chk.

The server must be completely stopped before using aria_chk on its files.

For example, to check one known Aria table from Command Prompt:

C:\xampp\mysql\bin\aria_chk.exe --datadir=C:\xampp\mysql\data --check C:\xampp\mysql\data\mysql\global_priv.MAI
Enter fullscreen mode Exit fullscreen mode

Only use that path if the file exists in your installation.

The command checks the specified Aria table's index file.

For a table confirmed as damaged, the offline recovery command is:

C:\xampp\mysql\bin\aria_chk.exe --datadir=C:\xampp\mysql\data --recover C:\xampp\mysql\data\mysql\global_priv.MAI
Enter fullscreen mode Exit fullscreen mode

--recover attempts a repair and can modify table files.

Use it only after backing up the data directory and confirming MariaDB is stopped.

It doesn't repair InnoDB tables.

Official reference:

https://mariadb.com/docs/server/clients-and-utilities/aria-clients-and-utilities/aria_chk

Fix C: The mysql system database is damaged

Sometimes the logs indicate damaged privilege tables, plugin tables or other structures inside:

C:\xampp\mysql\data\mysql
Enter fullscreen mode Exit fullscreen mode

A commonly shared fix recommends:

  1. Replacing the data folder with C:\xampp\mysql\backup.
  2. Copying personal database folders into it.
  3. Copying the original ibdata1.
  4. Mixing in redo-log files from the old directory.

This procedure is risky.

It combines files from potentially different server states.

It can leave Aria tables, privilege records, InnoDB metadata and transactional recovery information inconsistent.

A successful startup after this procedure doesn't guarantee that all data survived or that the tables are healthy.

Don't use the backup-folder swap as the first repair attempt.

Instead, follow this recovery order:

  • Preserve the entire original data directory.
  • Diagnose and repair the specific damaged Aria or system table where possible.
  • If MariaDB starts, export all important databases immediately.
  • If it cannot start normally, investigate controlled recovery using the original files.
  • Rebuild a clean MariaDB installation only after obtaining verified SQL dumps or identifying another reliable restore source.

A clean XAMPP mysql\backup directory contains initial database files. It is not a backup of your application's current databases, users or transactions.

If you use it to initialize a new server, custom database accounts and permissions must be recreated.

MariaDB 10.4 also stores account information in mysql.global_priv, with mysql.user provided as a compatibility view.

Replacing system tables can therefore change authentication and privileges.

For a related failure after an unsafe data-folder rebuild, see phpMyAdmin Error #1932: Table Doesn't Exist in Engine.

Why ibdata1 must not be replaced casually

The InnoDB system tablespace commonly uses:

ibdata1
Enter fullscreen mode Exit fullscreen mode

Depending on the MariaDB version and configuration, this file contains important InnoDB metadata, including the internal data dictionary.

Individual table files may be stored as:

employees.ibd
attendance.ibd
payroll.ibd
Enter fullscreen mode Exit fullscreen mode

Those .ibd files aren't independent database backups.

The original system tablespace and the table files may contain related metadata that must remain consistent.

If you replace ibdata1 with a fresh file while retaining old .ibd files, MariaDB may no longer recognize those tables.

A typical symptom is:

#1932 - Table doesn't exist in engine
Enter fullscreen mode Exit fullscreen mode

Don't delete ibdata1 because a tutorial claims MariaDB will recreate it.

It may create a new system tablespace, but that doesn't restore the metadata required to access the original tables.

Also don't delete .frm, .ibd, .MAD or .MAI files as a general startup fix.

They may contain the only remaining copies of your table definitions or data.

Fix file locks, permissions and InnoDB startup errors

If the problem isn't a port conflict or Aria recovery failure, inspect Windows file access and InnoDB initialization.

Cause 3: Windows permissions or file locks

MariaDB may report errors such as:

Operating system error number 32
Enter fullscreen mode Exit fullscreen mode

or:

Operating system error number 13
Enter fullscreen mode Exit fullscreen mode

On Windows, error 32 commonly indicates a sharing violation: another process has a file open in a way that prevents MariaDB from accessing it.

Error 13 commonly indicates access was denied.

Possible causes include:

  • Another MariaDB process using the same data directory.
  • Antivirus or endpoint security software locking database files.
  • Backup or synchronization software accessing active data files.
  • Incorrect NTFS permissions.
  • A database service running under a different Windows account.
  • XAMPP installed in a protected directory.

Start by checking whether another database process is active.

Then inspect the file path named in the error log.

Don't make broad permission changes without identifying the account running MariaDB.

For example, granting Everyone Full Control over the database directory is not an appropriate general fix.

The database service account needs suitable access to its files, but unrelated users shouldn't automatically receive it.

Antivirus and backup software

Real-time security software can occasionally interfere with database file access.

However, permanently disabling antivirus protection is a poor troubleshooting method.

Review the security software's logs and confirm whether it actually blocked or locked the file.

If an exclusion is justified, keep it narrowly scoped and follow your organization's security policy.

Database files also shouldn't be synchronized live through ordinary OneDrive or Dropbox folder synchronization as a substitute for a database-aware backup.

A cloud-sync copy made while MariaDB is writing may not be transactionally consistent.

Use a logical SQL dump or a supported database backup mechanism.

Running XAMPP as administrator

Running the XAMPP Control Panel as administrator can help determine whether a problem involves service-control permissions.

Right-click:

C:\xampp\xampp-control.exe
Enter fullscreen mode Exit fullscreen mode

Select:

Run as administrator

Then retry starting the service.

If the same file-access error remains, inspect the actual NTFS permissions and MariaDB service account.

Running the panel with administrator privileges doesn't repair corrupted database files.

Also, avoid installing XAMPP inside protected folders such as C:\Program Files when following the traditional XAMPP Windows setup.

Apache Friends documents Windows UAC-related write restrictions in those locations.

Cause 4: InnoDB fails to initialize

A common startup sequence looks like:

[ERROR] Plugin 'InnoDB' init function returned error.
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB
[ERROR] Aborting
Enter fullscreen mode Exit fullscreen mode

These are often consequences of another failure.

Look for earlier messages containing:

InnoDB:
Enter fullscreen mode Exit fullscreen mode

The preceding messages may identify the actual cause:

  • A missing tablespace.
  • A corrupted database page.
  • Redo-log recovery failure.
  • An invalid InnoDB configuration.
  • Incorrect file permissions.
  • A file locked by another process.
  • A version mismatch after replacing MariaDB binaries.

Don't delete InnoDB redo logs after a crash

Older MariaDB installations commonly use redo-log files such as:

ib_logfile0
ib_logfile1
Enter fullscreen mode Exit fullscreen mode

MariaDB 10.4 normally uses two redo-log files by default.

Starting with MariaDB 10.5, the default redo-log layout changed to a single file named ib_logfile0.

The actual files also depend on configuration.

Redo logs help InnoDB recover transactions after an unexpected shutdown.

Deleting them after a crash may remove information needed to bring the database back to a consistent state.

Some old tutorials recommend deleting redo logs whenever InnoDB won't start.

Don't follow that advice blindly.

There are controlled procedures for changing redo-log configuration after a clean shutdown, but those are not interchangeable with crash recovery.

If the problem appeared immediately after changing innodb_log_file_size or another InnoDB setting, restore your previous my.ini configuration first.

Keep the original redo logs intact while investigating.

Official MariaDB redo-log documentation:

https://mariadb.com/docs/server/server-usage/storage-engines/innodb/innodb-redo-log

Use innodb_force_recovery only for emergency extraction

If the error log indicates InnoDB corruption and MariaDB cannot start normally, innodb_force_recovery may allow the server to start sufficiently to extract data.

This is an emergency recovery mechanism.

It is not a repair command.

Before using it, preserve the entire data directory and the original my.ini.

In:

C:\xampp\mysql\bin\my.ini
Enter fullscreen mode Exit fullscreen mode

Under the existing [mysqld] section, add:

innodb_force_recovery=1
Enter fullscreen mode Exit fullscreen mode

Restart MariaDB.

If the server starts, prioritize exporting your important databases.

Don't run application migrations, normal payroll processing or other write-heavy tasks while emergency recovery is enabled.

If level 1 doesn't work, MariaDB documentation describes increasing the value one level at a time.

Higher values skip additional recovery operations.

That increases the risk of inconsistent results.

At levels 4 and above, recovery behavior becomes particularly hazardous and depends on the MariaDB version.

Don't jump directly to level 6 because someone online described it as the strongest fix.

If recovery succeeds, export the data, remove the recovery setting, and plan restoration into a clean, compatible database installation.

Never consider a database repaired merely because it starts with innodb_force_recovery enabled.

Official reference:

https://mariadb.com/docs/server/server-usage/storage-engines/innodb/innodb-troubleshooting/innodb-recovery-modes

Verify databases and Laravel connections after recovery

A green MySQL label in the XAMPP Control Panel only proves the server process stayed running.

It doesn't prove your databases are intact.

Run these checks before returning to development.

Step 1: Confirm the database server responds

Open Command Prompt:

C:\xampp\mysql\bin\mysql.exe -h 127.0.0.1 -P 3306 -u root -p -e "SELECT VERSION();"
Enter fullscreen mode Exit fullscreen mode

Change 3306 if your installation uses another port.

Enter the configured password when prompted.

A working server returns its version information.

For example, an installation using the documented XAMPP 8.2.12 package may report a MariaDB 10.4.32 version string.

The exact result depends on your installation.

Step 2: List the databases

Run:

C:\xampp\mysql\bin\mysql.exe -h 127.0.0.1 -P 3306 -u root -p -e "SHOW DATABASES;"
Enter fullscreen mode Exit fullscreen mode

You should see your application databases.

For example:

information_schema
mysql
performance_schema
my_laravel_app
Enter fullscreen mode Exit fullscreen mode

Database names vary between installations.

If an expected database is missing, don't recreate it until you've inspected your physical backup and SQL dumps.

Recreating an empty database with the original name doesn't recover its records.

Step 3: Check table health

MariaDB includes a command-line table-checking utility.

In XAMPP installations where mysqlcheck.exe is present, run:

C:\xampp\mysql\bin\mysqlcheck.exe -h 127.0.0.1 -P 3306 -u root -p --check --all-databases
Enter fullscreen mode Exit fullscreen mode

This checks tables and reports warnings or errors.

It requires the database server to be running.

It may take time on large databases.

Review the output rather than assuming every line must literally say OK.

Some table types, views and storage engines can produce different status messages.

If a particular Aria or MyISAM table is damaged, a targeted repair may be appropriate after creating a backup.

For example:

CHECK TABLE my_laravel_app.example_table;
Enter fullscreen mode Exit fullscreen mode

Replace the example table with the actual table name.

Don't use broad automatic repair commands as a universal solution.

MariaDB's table-repair tools don't repair corrupted InnoDB pages in the same way they repair Aria or MyISAM tables.

Step 4: Verify important records

A database appearing in SHOW DATABASES doesn't prove that every table contains its original records.

Open phpMyAdmin:

http://localhost/phpmyadmin
Enter fullscreen mode Exit fullscreen mode

Inspect several important tables.

For a payroll or attendance application, verify:

  • Employee records.
  • Attendance records.
  • Leave records.
  • Salary and payroll records.
  • Recent transactions or imported data.

Compare record counts and recent records with a known-good backup or application report where possible.

Don't rely only on table counts to prove data integrity.

A table can contain the expected number of rows while still having missing or incorrect values.

Step 5: Test Laravel without changing its database

From your Laravel project directory:

php artisan config:clear
Enter fullscreen mode Exit fullscreen mode

Then:

php artisan migrate:status
Enter fullscreen mode Exit fullscreen mode

This displays migration status without executing pending migrations.

Confirm that the application connects to the intended local database before running it.

Do not run:

php artisan migrate:fresh
Enter fullscreen mode Exit fullscreen mode

That command drops all tables before rerunning migrations.

It is not a database recovery operation and can destroy the data you're trying to save.

Also don't run migrate:refresh or db:wipe as a troubleshooting shortcut.

If Laravel reports:

SQLSTATE[HY000] [1045] Access denied
Enter fullscreen mode Exit fullscreen mode

the database account or password may have changed.

Check the .env credentials and MariaDB users.

If you rebuilt the MariaDB system database, custom users and grants may need to be recreated from your documented configuration.

If Laravel reports:

SQLSTATE[HY000] [2002] Connection refused
Enter fullscreen mode Exit fullscreen mode

verify the database port, listener and host.

A changed port in my.ini won't automatically update Laravel's .env.

Step 6: Test normal restart behavior

After verifying the data:

  1. Stop MariaDB cleanly from the XAMPP Control Panel.
  2. Confirm that the server process exits.
  3. Start it again.
  4. Check the latest error-log entries.
  5. Reopen phpMyAdmin and the Laravel application.

A database that starts only once, then fails again after a clean restart, isn't reliably recovered.

If InnoDB emergency recovery was used, remove the recovery setting before the final normal-start test.

Prevent another crash and know when to reinstall

Most XAMPP startup problems become much easier to solve when a recent SQL dump exists.

A physical database folder and a logical SQL export serve different purposes.

The physical copy preserves engine-specific files and may support low-level recovery.

The SQL dump gives you a way to recreate databases through supported SQL operations.

For development environments, keep both where practical.

Create regular SQL backups

MariaDB provides mysqldump, also known in newer packages as mariadb-dump.

On Windows, the --result-file option is preferable to shell output redirection for generating SQL files.

Create a batch file:

C:\xampp\backup-db.bat
Enter fullscreen mode Exit fullscreen mode

Use:

@echo off
setlocal

set "MYSQLDUMP=C:\xampp\mysql\bin\mysqldump.exe"
set "BACKUPDIR=C:\db-backups"
set "BACKUPFILE=%BACKUPDIR%\dev-databases.sql"

if not exist "%MYSQLDUMP%" (
    echo ERROR: mysqldump.exe not found.
    exit /b 1
)

if not exist "%BACKUPDIR%" mkdir "%BACKUPDIR%"

if not exist "%BACKUPDIR%" (
    echo ERROR: Backup directory could not be created.
    exit /b 1
)

"%MYSQLDUMP%" -h 127.0.0.1 -P 3306 -u root -p --single-transaction --routines --events --triggers --databases my_laravel_app another_db --result-file="%BACKUPFILE%"

if errorlevel 1 (
    echo ERROR: Database export failed. Do not trust the output file.
    exit /b 1
)

if not exist "%BACKUPFILE%" (
    echo ERROR: Backup file was not created.
    exit /b 1
)

echo Database export completed:
echo %BACKUPFILE%

endlocal
Enter fullscreen mode Exit fullscreen mode

Replace my_laravel_app and another_db with your database names.

Change the port if necessary.

Run the batch file while MariaDB is running normally.

You will be prompted for the database password.

The command uses:

  • --single-transaction to obtain a consistent transactional snapshot for InnoDB tables.
  • --routines to include stored procedures and functions.
  • --events to include scheduled database events.
  • --triggers to include table triggers.
  • --databases to include the named database creation and selection statements.
  • --result-file to write the SQL output directly to a file.

Two limitations matter.

First, --single-transaction doesn't provide the same consistent snapshot guarantees for nontransactional tables such as Aria and MyISAM.

Second, a successful process exit doesn't automatically prove the backup can be restored.

You should periodically test an export by importing it into an isolated database instance.

Also, this example deliberately uses one fixed filename and overwrites it on each run.

For actual backup retention, use timestamped filenames and keep multiple generations, ideally on another drive or storage system.

Don't leave the only backup on the same disk as the original database.

Official MariaDB dump documentation:

https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump

Don't run SQL dumps against an already failed server

mysqldump requires a running database server.

If MariaDB cannot start, the command cannot extract your data.

That's why preserving the full data directory before attempted repair is so important.

If the server starts only under emergency recovery, try exporting the highest-priority application databases first.

Some corrupted tables may still be unreadable.

Record which exports completed successfully and which failed.

Never mistake a partial SQL file for a complete backup.

Keep XAMPP and database versions documented

Before upgrading PHP, XAMPP or MariaDB, record:

  • XAMPP version.
  • MariaDB version.
  • Active database port.
  • Data directory location.
  • Database users used by each application.
  • Existing backup location.
  • Relevant custom my.ini settings.

If the application uses Laravel, also preserve its .env configuration securely.

Don't publish .env files or include database passwords in support screenshots.

When should you reinstall XAMPP?

Reinstallation may be appropriate when:

  • XAMPP binaries or installation files are damaged.
  • A version upgrade left incompatible components.
  • The database server cannot be restored safely in place.
  • You have verified SQL backups and want a clean installation.
  • Repeated startup failures indicate a broader installation problem.

But reinstalling XAMPP doesn't repair corrupted InnoDB tables.

If the only copy of your data is in the broken data directory, reinstalling without preserving it can make recovery harder.

The safest reconstruction path is:

  1. Preserve the complete original XAMPP directory or at least the original database directory and relevant configuration.
  2. Verify that your SQL backups are readable and contain the required databases.
  3. Install a compatible XAMPP or MariaDB version into a separate clean directory or environment.
  4. Start the new database server with its own initialized data directory.
  5. Import your verified SQL backups.
  6. Recreate required application users and grants.
  7. Update Laravel connection settings if necessary.
  8. Verify the applications and data before retiring the old installation.

For example, after a successful clean installation with a running database and an appropriate SQL dump, an import from Command Prompt may look like:

C:\xampp\mysql\bin\mysql.exe -h 127.0.0.1 -P 3306 -u root -p < C:\db-backups\dev-databases.sql
Enter fullscreen mode Exit fullscreen mode

Use the correct executable path, port and credentials for the new installation.

The example assumes the dump includes the necessary database creation statements.

Don't import into an existing production database without understanding which tables the dump will create, replace or modify.

If you have no SQL dump and the original MariaDB data is corrupted, don't copy database folders into a fresh installation and expect InnoDB to work.

Raw database recovery is version-sensitive and may require the original system tablespace, redo logs, configuration and specialized recovery work.

Preserve those files and investigate recovery before overwriting anything.

For broader development-server protection, the HeadsNTail website security checklist covers backup and access-control practices. Although that article focuses on cPanel, the underlying principles also apply to local development environments.

FAQ

Why does XAMPP say "MySQL shutdown unexpectedly" immediately after I click Start?

The XAMPP Control Panel shows this message when the database process starts and then exits. Common causes include a port conflict, damaged Aria recovery logs, locked database files, incorrect permissions or an InnoDB initialization failure. Read the most recent error messages in mysql_error.log before changing files or settings.

Can I delete ibdata1 or aria_log files to fix XAMPP?

Don't delete ibdata1. It contains important InnoDB system information and may be necessary to recover existing tables. Numbered aria_log files can sometimes be isolated when MariaDB explicitly reports Aria crash-log corruption, but only after stopping the server and preserving a complete backup. Normally preserve aria_log_control unless its own corruption is confirmed.

How do I fix port 3306 already in use in XAMPP?

Run netstat -ano | findstr :3306 to identify the listening PID, then inspect it using tasklist /SVC /FI "PID eq 4528", replacing 4528 with your actual PID. Stop the conflicting service if it isn't needed, or configure XAMPP to use another port such as 3307. Update phpMyAdmin and Laravel connection settings afterward.

Will copying mysql\backup into the data folder restore my databases?

No. XAMPP's mysql\backup directory contains initial database files, not the current contents of your applications. Replacing the active data directory with it can remove access to your existing databases. Mixing its system files with old InnoDB table files may also create metadata inconsistencies. Preserve the original data directory and prioritize restoring verified SQL dumps.

Next step: If XAMPP currently shows "MySQL shutdown unexpectedly," open the error log and identify the first meaningful failure from the latest startup attempt. Fix that specific cause, verify the database contents, and create a tested SQL backup before returning to normal development.

Technical references

Originally published at headsntail.com. Free tools for PHP, Laravel and cPanel work: headsntail.com/tools.

Top comments (0)