I just dealt with this on a client computer. The problem was that the machine.config
files for .NET Framework 4.x had both been corrupted (they had somehow become zero-length files).
Deleting the files is insufficient.
It worked to simply replace the zero length files with the code below, but I used the "known good" versions in order to ensure that there weren't any long-term side-effects.
This is the minimum required content for the machine.config
files:
<?xml version="1.0" encoding="UTF-8"?>
<configuration />
Replacing these two files with "known good" copies of machine.config
from the same version resolved this for me and didn't leave me worrying that some unknown issue would crop up later.
After fixing or replacing the machine.config
files a reboot is required.
The Windows machine.config
file is located one of the following folders:
%Windows%\Microsoft.NET\Framework\v{version}\CONFIG
%Windows%\Microsoft.NET\Framework64\v{version}\CONFIG
There may also be corrupted machine.config
files for individual applications under their *\mono\{version}
folders, though I would be much more hesitant to replace them without using a copy from the same application and application version on the same platform and CPU architecture.
In any case, on Windows, you can find the specific defective files by searching for zero-length files under the Windows folder named machine.config
. This command will do that for you.
forfiles /P %windows% /S /M machine.config /C "cmd /c if @isdir==FALSE if @fsize EQU 0 echo @path"
MMC cannot initialize the snap-in.
I wonder if this could be in any way related to the powershell error.