I had some difficulty identifying why my Windows 10 Enterprise machine suddenly could not run Event Viewer (the MMC plugin).
It would launch, but produce the following message: MMC could not create the snap-in. The snap-in might not have been installed correctly. Name: Event Viewer CLSID: FX:{b05566ad-fe9c-4363-be05-7a4cbb7cb510}
I tried all the usual channels and suggestions that came up from a Google search to no avail. Someone at work suggested that a recent change to my machine.config could be causing the problem. It turns out he was right. By removing the following line from my machine.config, MMC is now able to run giddy as a goat:
I removed the <machineSettings maxTimeout="00:00:00"/> node from the system.transactions node and now Event Viewer runs great.
Someone else on stack overflow had similar issues and "solved" it by blasting the entire Microsoft.NET folder and replacing it with a "working machine" (Windows Server 2008 R2: Cannot access event viewer, server manager, IIS7 CLSID:FX:{18ea3f92-d6aa-41d9-a205-2023400c8fbb}) but that could cause problems if the machines have different .NET frameworks installed.
This post is first, an effort to help others who come across this issue and second, a ping out there to see if anyone could explain why a .NET machine.config alters the behavior of MMC plug-ins.
Please correct me if I'm wrong, but I thought the Event Viewer (still version 1.0) was built in C++, so it wouldn't require the machine.config from the CLR library. Why, then, would a change to the machine.config or installing any version of the .NET framework cause an issue (E.G. "MMC plugins (e.g. EventViewer) not working after installing .NET Framework V4.5.2")?
In case it matters, I am running the .NET framework v4.0.30319. The machine.config file that was modified is under the C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config path.
One possible fix to the "MMC could not create the snap-in." error is to check your .NET machine.config XML. In my case, removing the <machineSettings maxTimeout="00:00:00"/> tag resolved the issue. This was a tag that was added by our architect to get around a SQL transaction timeout so an in-house installer would run to completion.
It would still be good to know why a change to the machine.config would matter to the Event Viewer plugin or the Microsoft Management Console.