The error – HR0x80004005 EC1142 – Unable to mount database arises when the Exchange Server cannot mount a database because the transaction log files could be missing, corrupted, or in the wrong sequence. It is related to log file integrity failure and not a database corruption error. Along with this error, you may also encounter other related error codes, such as:
- EC1108: It is related to the Active Manager DAG connection failure.
- EC543: It is a Jet engine access/permissions error.
- EC1142: It is related to a transaction log file issue (missing/corrupt/sequence error).
There are other HR0 error headers, like HR0x80040115, related to a connectivity issue of MAPI/RPC service.
What does the HR0x80004005 EC1142 Error Mean?
When the Exchange Server tries to mount the database and the database engine finds out that the required transaction log files are not accessible, corrupt, or not found in the storage, it generates the HR0x80004005 EC1142 error. Unlike EC1108 (related to Active Manager connectivity issue) and EC543 (related to Jet engine permissions), EC1142 is exclusively a transaction log integrity issue.
In the table below, we have mentioned the error codes, their possible root causes and the first troubleshooting step you should take in order to identify the error and the problem.
| Error Code | Root Cause | First Check |
| HR0x80004005 EC1142 | Log files missing, corrupt, or wrong sequence | Run eseutil /ml to check log file integrity |
| HR0x80004005 EC1108 | Active Manager lost connection to database copy (DAG) | Run Get-MailboxDatabaseCopyStatus to check DAG health |
| HR0x80004005 EC543 | Jet engine access denied – possible file permissions issue | Check file system permissions on the EDB and log files |
| HR0x80040115 | MAPI/RPC connectivity failure to Exchange store | Check that all the required Exchange Server services are running |
Note: You may encounter this error in ant Exchange Server version – be it 2010, 2013, 2016, 2019, or the new Exchange Server Subscription Edition (SE).
Common Causes of the EC1142 Error
With the focus on the EC1142 error, here is a list of the common causes, along with the explanation of each instance. The below are sorted in order of criticality.
| Order | Cause | Explanation |
| 1 | Missing transaction log files | Transaction log files are deleted, moved, or lost due to backup failure or incompatibility, applications which are not compatible with Exchange Server, or disk failure. An Exchange Server cannot mount the database without all the logs from the last checkpoint to the current state. So, check the log folder for gaps in the E00.log sequence and the Event Viewer for any indications. |
| 2 | Corrupt transaction log files | Though the transaction log file exists, its contents are unreadable, inconsistent, or corrupt. This might be the result of hardware failure, sudden power loss, or disk I/O errors during log write operations. |
| 3 | Logs in wrong location | The transaction log file path configured for the database does not match where the logs actually exist. This might happen to you after a database or log file move operation. If the move was not successful or the transaction logs did not move. |
| 4 | Circular logging deleting needed logs | If circular logging is enabled, the Exchange Server will overwrite transaction log files. If the database is in Dirty Shutdown state and the required logs to replay them are deleted, you will not be able to recover the database. You should not enable circular logging for production servers. |
| 5 | Insufficient disk space | This is a very common issue if the server is not monitored. When a disk is full, it will prevent the Exchange Server from creating, writing to new log files, or even shut down the database properly, which causes the log sequence to break and possibly cause corruption. |
What should you do before you start?
Before you move to fixing the problem, you need to run the below checks to diagnose the system. The output will indicate where the issue is and what is causing it, thus reducing the recovery time.
Check 1 – Checking the Database State
For this, you need to use the EseUtil command with the mh parameter (see the below example).
eseutil /mh "<full file path to the edb file>"
You should check the State field. The command will give you the state of the database as:
- Clean Shutdown – The database is healthy and the file path of the transaction logs is correct.
- Dirty Shutdown – This indicates an issue with the database itself or the transaction logs.
Check 2 – Verify Log File Integrity
The ESEUtil command with the ml parameter can be used to check the integrity of the transaction logs (see the example below).
eseutil /ml "<file path of the database>\<transaction log number>"
This will determine if there is any issue with the transaction log. If an error is displayed, then the issue is definitely with a transaction log.
Below is a matrix of the state that can point you to the right method to troubleshoot and recover the data from the database.
| eseutil /mh State | eseutil /ml Result | Go to |
| Clean Shutdown | All logs are fine | Method 3 — Check log file path configuration |
| Clean Shutdown | Errors in log files | Method 2 — Repair or restore log files |
| Dirty Shutdown | All logs are fine | Method 1 — Soft recovery (eseutil /r) |
| Dirty Shutdown | Missing or corrupt logs | Method 4 — Eseutil Hard recovery (last resort) or Method 5 — Stellar Repair for Exchange |
Methods to Fix the EC1142 Error
Below are the possible fixes that you can try to resolve the HR0x80004005 EC1142 after the initial checks have been done based on the results.
Method 1 – Soft Recovery using ESEUtil /r
The ESEUtil soft recovery is your first choice to start with. The ‘r’ parameter will replay all the transaction logs on the database to remove any integrity issues. If all the transaction logs are present, this might resolve the EC1142 error. Here’s the command:
eseutil /r <log prefix> /l "<transaction log path>" /d "<full database path>"
The log prefix can be taken from the /mh command.
Note: The soft recovery should only be used if the status is showing Dirty Shutdown and the transaction log check is saying that all is ok. If it is showing Dirty Shutdown and there are missing log files, do not use this command and go to Method 2 or Method 4.
Method 2 — Restore Missing or Corrupt Log Files from Backup
If the result from the ESEUtil shows that there are missing or corrupt transaction logs, the soft recovery will not be effective. The other solution for you is to recover the database from backup. After the restore of the database is complete, you should always run the soft recovery as in most of the cases, it will still show dirty shutdown, but soft recovery will fix it.
Note: Using this method will result in data loss from when the last healthy backup was taken to when the server failed. If there is no backup or the backup is too old, you should skip to either Method 4 or Method 5.
Method 3 — Verify and Correct Log File Path
If the database is showing the state of clean shutdown but the error EC1142 still persists, you must check the path configured in the Exchange Server and confirm that it matches with the actual location of the logs. This could be caused by lost storage or loss of connectivity with the storage, disk issues, or human error during a change of location.
Verify the location of the logs using the Get-MailboxDatabase command below:
Get-MailboxDatabase -Identity <database name> | fl EdbFilePath,LogFolderPath
If this is not correct, you should use the Move-DatabasePath to change the Log Folder Path to the correct one.
Move-DatabasePath -Identity "<database name>" -LogFolderPath "<location of logs>" -ConfigurationOnly:$false
If this is not the case, you can go to Method 4 or Method 5, but if data loss is not acceptable, you should go directly to Method 5 (Stellar Repair for Exchange).
Method 4 — Hard Recovery (eseutil /p) — Last Resort
Before proceeding, it’s important to note that this is a destructive method and it will cause data loss. The hard recovery will just purge any data which is deemed corrupted, along with false positives, and it’s not a guarantee that after running this command, the database will mount. You must also note that this procedure will require ample free storage and will take a lot of time to complete. It must only be used as a last resort. If data loss is not acceptable you should use Method 5 (Stellar Repair for Exchange).
To perform hard recovery, use the below command:
eseutil /p "<full database path>"
Method 5 — Stellar Repair for Exchange (When eseutil Fails)
When all fails and data loss is not acceptable, you will need to rely on specialized tools, such as Stellar Repair for Exchange. It can open databases of any size, in any state, and mounted or standalone. This tool supports all the Exchange Servers – 2007, 2010, 2013, 2016, 2019 and Subscription Edition (SE).
After repair, you can granularly save user mailboxes, archives, shared mailboxes, public folders, disabled mailboxes, and even deleted/purged items to PST and other file formats. You can also export directly to a live Exchange Server database or Microsoft 365 tenant. It features automatic mailbox matching, parallel export, and priority exports, thus reducing the recovery time and recovery of services while ensuring a seamless restore.
How to Verify if the Error is Fixed?
After applying any method, you should run the ESEUtil /mh command to see that the state has changed to Clean Shutdown. It’s important to confirm the state before attempting to mount the database.
Eseutil /mh "<full database path>"
Alternatively, you can run the below command in the Exchange Management Shell (EMS) to ensure the state of the database.
Get-MailboxDatabase -Identity "DatabaseName" -Status | fl Name,Mounted
This command should return a True state. If the database is not showing as mounted, use the Mount-Database command below to mount the database.
Mount-Database -Identity "DatabaseName"
FAQs
