Exchange Server: unhandled exception in MMC Snap-in

Question

Exchange Server: unhandled exception in MMC Snap-in

Michael Carter 0

Hello.

The C:\ drive on our hybrid Exchange Server filled up, and after extending the disk and rebooting, now find that Exchange Server will not start. When I launch Exchange Toolbox, I get the error that MMC Snap-in won't load. The details are:

Snap-in Unavailable.
This snap-in performed a non-valid operation and has been unloaded. To continue wirking with this snap-in, restart MMC or try loading the snap-in again.

I have no idea which snap-in this is referring to, but am assuming it's just Exchange-related.

Details of the error yield this:

FX:{[Moderator note: Personally Identifiable Information removed]} Type is not resolved for member 'Microsoft.Exchange.Configuration.MonadDataProvider.MonadDataAdapterInvocationException,Microsoft.Exchange.Configuration.ObjectModel, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. at Microsoft.ManagementConsole.Internal.IMessageClient.ProcessRequest(Request request)
at Microsoft.ManagementConsole.Executive.RequestStatus.BeginRequest(IMessageClient messageClient, RequestInfo requestInfo)
at Microsoft.ManagementConsole.Executive.SnapInRequestOperation.ProcessRequest()
at Microsoft.ManagementConsole.Executive.Operation.OnThreadTransfer(SimpleOperationCallback callback)

I've run DISM and SFC to check for any system integrity errors, and none were found.

I've also cleared the local MMC configuration for my user for anything Exchange-related, but that didn't do anything.

0 comments

2 answers

Your answer

Answer 1

Michael Carter 0

All services except for "Microsoft Exchange Transport" service started successfully.

Error while starting the Microsoft Exchange Transport service:

"Error 1068: The dependency service or group failed to start"

Kai-L 18,970 Reputation points Microsoft External Staff Moderator

2026-09-02T22:26:56.9466667+00:00
Dear Michael,

Thank you for your update. From my research, transport depends on the Microsoft Filtering Management Service, which in turn depends on the Microsoft Exchange Diagnostics Service. It is worth checking those two first, as a failure further down the chain will stop Transport regardless of everything else looking healthy.

A few things to work through:

Open services.msc, find Microsoft Exchange Transport, and check the Dependencies tab to see the full chain for your build. Then try starting each dependency individually from the bottom up, noting which one fails.

Check the Microsoft Filtering Management Service specifically. If it will not start, that is almost certainly your blocker.

Review the Application and System event logs at the moment you attempt the start. The dependency that fails will usually log a more specific error than 1068 does.

Given the disk filled beforehand, there is a reasonable chance the transport queue database or its logs were left in an inconsistent state, which can prevent the related services from starting. The queue database lives under the TransportRoles\data\Queue folder in your Exchange installation path. If the event log points that way, renaming that folder so Exchange rebuilds a fresh queue database is a known recovery step, though I would only do that after confirming from the logs, and after taking a copy of the folder first since any messages still queued would be lost. I hope this helps. Looking forward to your reply.
Kai-L 18,970 Reputation points Microsoft External Staff Moderator

2026-09-03T20:54:26.1166667+00:00

Dear Michael,

It has been a while and I am writing to see how things are going with this issue. If there’s anything else I can assist you with or if you need further clarification, please don’t hesitate to let me know, I’m here to help. Looking forward to hearing from you. Wishing you a great day ahead!

Answer 2

Dear Michael,

Unfortunately, as a forum moderator, I am not able to access your server or its logs to diagnose this directly. My role here is limited to general guidance you can apply from your side. The MMC error is almost certainly secondary. Exchange Toolbox runs over Exchange PowerShell, and when that session fails the exception cannot be serialized back to the snap-in, producing the message you are seeing. That is why DISM, SFC and clearing the MMC config made no difference. Given the drive filled just before this started, I would recommend checking the following:

Run Test-ServiceHealth, or check services.msc for any Microsoft Exchange service set to Automatic that is not running.
Confirm the Default Web Site and Exchange Back End are started in IIS, and that the PowerShell virtual directory exists under both. Run iisreset if they look correct.
Open the Exchange Management Shell directly. If it also fails, the error will be far more useful than the snap-in's.
Check the Application event log around the reboot, filtered on MSExchange sources.
Run Get-MailboxDatabase -Status to confirm the databases are mounted.

Worth noting separately that extending the disk treats the symptom. Transport queue growth or logs not being truncated are the usual causes, so the drive may fill again.

If you need to escalate, you can go through Microsoft Professional Support (pay-per-incident), with initial response times from 2 hours for critical business impact. For more technical or in-depth topics, the Home | Microsoft Community Hub offers a vibrant space to collaborate with Exchange Server specialists and IT professionals. This can be a helpful step before considering a paid support option.

I hope this information is helpful and provides you with a clear path forward. Should you have any further questions or need additional assistance, please don't hesitate to reach out. I'm always happy to help.

If the answer is helpful, please click "Yes" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in the forum documentation to enable e-mail notifications if you want to receive the related email notification for this thread.