MacType causes "File locked with only readers" errors in MSBuild.exe

[mufunyo]

I was troubleshooting why I couldn't get either DiligentEngine or OBS-Studio to compile in VS2019, and noticed I was getting "Access denied" and "Error creating or communicating with child process" messages in the build log.

When I investigated deeper with ProcMon, I saw that MSBuild.exe was trying to get a file handle on link.exe or cl.exe and was getting "File locked with only readers" as a result. Of course, it shouldn't even be trying to get write access to simply execute a binary.

Then I looked at the stack and noticed MacType.dll was loaded. So I disabled MacType and the build errors disappeared.

A suitable workaround seems to be to blacklist MSBuild.exe in MacType's excluded processes, but if you want to fix the underlying issue, you can reproduce by downloading DiligentEngine or OBS-Studio and attempting to compile it with Visual Studio 2019.

[wmjordan]

Please simply blacklist them, they don't have any interface.

I guess it is better to have a mechanism to include blacklists from external ini files, if snowie2000 has time to implement that, therefore users may make and share some blacklist files for various environments, like ad blocker lists.

I blacklisted the following Visual Studio related files:

[UnloadDll]
mspdbsrv.exe
MSBuild.exe
VBCSCompiler.exe
ServiceHub.SettingsHost.exe
ServiceHub.IdentityHost.exe
ServiceHub.VSDetouredHost.exe
ServiceHub.Host.CLR.x86.exe
ServiceHub.Host.Node.x86.exe
ServiceHub.RoslynCodeAnalysisService32.exe
ServiceHub.ThreadedWaitDialog.exe

[mufunyo]

Of course the workaround is perfectly viable since the processes in question don't have a GUI, but I wanted to share the specifics of the bug just in case it is possible that it gets triggered in other applications that do include a GUI.

[snowie2000]

You are the first one who reported this bug. Others have reported like MacType made compiling slower or something, but not crash.

[mufunyo]

@snowie2000 The common factor between the projects that trigger the bug seem to be rather large solution files with a lot of sub-projects, generated by CMake.

With my own smaller projects generated by Premake I didn't have any issues.

Just spitballing here, but if MacType somehow causes the access permissions for OpenFile calls to be modified, it could be that it only becomes a problem when two processes do it at the exact same time for the same file. This would be consistent with the bug only triggering on large projects, as it's more likely for race conditions to occur with multi-threaded compilation.

[mufunyo]

A suitable workaround seems to be to blacklist MSBuild.exe in MacType's excluded processes

I've just done some reproduction tests and this is actually not the case. Excluding MSBuild.exe from MacType still causes the errors to appear. The only workaround that seems to work so far is stopping the MacType service entirely (this is what I initially did, and I incorrectly assumed that excluding the process would have the same effect).

Just spitballing here, but if MacType somehow causes the access permissions for OpenFile calls to be modified, it could be that it only becomes a problem when two processes do it at the exact same time for the same file. This would be consistent with the bug only triggering on large projects, as it's more likely for race conditions to occur with multi-threaded compilation.

I cannot confirm this hypothesis either, as the error still occurs with multi-threaded compile limited to 1 parallel project build.

I tried the following:

[UnloadDll]
mspdbsrv.exe
MSBuild.exe
VBCSCompiler.exe
ServiceHub.SettingsHost.exe
ServiceHub.IdentityHost.exe
ServiceHub.VSDetouredHost.exe
ServiceHub.Host.CLR.x86.exe
ServiceHub.Host.Node.x86.exe
ServiceHub.RoslynCodeAnalysisService32.exe
ServiceHub.ThreadedWaitDialog.exe
cl.exe
link.exe
devenv.exe

And still got the same errors. Only stopping the MacType service entirely works to prevent the errors from occurring.