Fixing “Cannot start Microsoft Outlook. Cannot open the Outlook window” error when starting Outlook 2013

Yesterday I wasted spent a few enjoyable hours fixing my test environment. I have a VM which hosts almost entire Microsoft technology stack within it (AD DS, SQL, Exchange) and of course K2 (it is all works well together, you know 🙂 ). So I spent some time arranging tiny test case and was about to start checking the results when I run into issue with starting Outlook 2013 with the following error message:

The problem with this error message that it is a bit generic and especially if you take only two three first sentences out of it you will be set on wrong track both by your knee-jerk reflex and/or Google realizing that this was wrong direction well in the middle or even after completing all client side troubleshooting tricks (something from this list which is quite cool for curing client side Outlook quirks).

Somewhere in the midst of going through that list with no positive results, I finally realized that I probably need to re-read error message a bit more carefully. At this point I realized that Outlook says that it has server side problems in fact, and 3 firs sentences just sort of incongruous introduction. LESSON: Read error message till the end carefully, it really helps 🙂

So once I refocused my troubleshooting efforts on the second part of error message I was able to solve the issue (not in 10 minutes, but anyway). Connectivity issues were not something to worry about on “all in one” VM (AD DS, Exchange and Outlook are on the same box), so I started checking on Exchange side. I visited EAC and quickly noticed that single mailbox database available in my environment is offline:

So  I quickly attempted to mount it back by issuing the following command in EMS (for history geeks reading this EMS was first introduced in Exchange 2007):

Mount-Database "Your Database Name"

For aforementioned command you need to specify database name only which you can see in EAC (see screenshot above) or in the output of the following cmdlet:

Get-MailboxDatabase

Unfortunately I was not able to mount my mailbox database with the following error “MapiExceptionDatabaseError: Unable to mount database (StoreEc: 0x454)”:

In order to check the state of mailbox database you will need to use Exchange Server Database Utility – eseutil issuing something similar to this in EMS:

eseutil /mh "%Path to your mailbox database%\%Mailbox Database Name%.edb"

The problem with that is that you need to know and explicitly specify a path to your database file in this case. You can get this path by issuing the following command in EMS (source):

Get-MailboxDatabase -Status | select edbfilepath

Once I was done with that I was able to see that my mailbox DB had a state “Dirty Shutdown” which normally indicates only that the database files were not detached from the log stream correctly (see details here):

So knowing this we want to bring back our DB to “Clean Shutdown” state. This can be done by means of hard repair using eseutil /p:

eseutil /p "%Path to your mailbox database%\%Mailbox Database Name%.edb"

This operation will check the database for any damaged pages; if it finds any, it will delete them. Make sure that you can live without any data inside the database before doing a hard repair, because you may lose data. Once this operation completed you can verify your DB state issuing esutil /mh once again, it should be “Clean Shutdown” now:

But before trying to mount mailbox database once again it is also necessary to move or delete all  database logs (all the log files + 1 check file E00.chk). Moving logs is a part of hard repair procedure which was actually my scenario. Before doing this you may verify log files healt with the following command:

eseutil /ml "%Log File Location%\%Log file prefix%"

In my case it was test VM and I was ready to accept any data loss focusing only on getting my environment back in up and running state ASAP – so I just located and deleted all the logs even without checking their health first.

For production or real world cases you should be very clear on exact process and have clear understanding on differences between soft recovery and hard repair. Probably this article may be helpful for you: Exchange Database Recovery – Using eseutil commands.

Anyhow it was interesting to fix it without reverting to snapshot or employing any other methods from cargo cult system administration toolbox (apart from restore from snapshot it may also include such things as triple-reset and extra coffee-breaks 🙂 ). Though I should admit my troubleshooting approach in this particular case had a tiny touch of cargo-cult sysadmin culture.