locked
Wix installer project freezes RRS feed

  • Question

  • I've got a wix installer project that works fine when I build it in visual studio, but when I check it in the build server just freezes when it runs the linker (light) (see image).

    Any thoughts as to what it could be and how to fix it?Frozen MSBuild

    Tuesday, August 2, 2016 8:38 AM

Answers

  • This looks a bit strange. Although the source code of the Light task has a comment saying that it runs as a separate process by default, it doesn't seem to set the RunAsSeparateProcess property inherited from the WixToolTask class; and the Link target specifies RunAsSeparateProcess="$(RunWixToolsOutOfProc)" when it calls the Light task, just like the Compile target does with the Candle task.

    It also sets RunWixToolsOutOfProc=true if the MSBuild process isn't x86. Are you using 32-bit or 64-bit MSBuild? I think 64-bit might work better; or if you use 32-bit, then try setting the RunWixToolsOutOfProc property yourself.

    …On the other hand, you wrote it builds OK in Visual Studio, which AFAIK uses 32-bit MSBuild. So, switching to 64-bit MSBuild might not solve your problem, but at least it should cause light.exe to run as a separate process so that you can see it in Task Manager and create a dump file.
    • Edited by ranta Wednesday, August 3, 2016 3:52 PM Visual Studio uses 32-bit MSBuild though
    • Marked as answer by DragonLord66 Wednesday, August 3, 2016 4:36 PM
    Wednesday, August 3, 2016 3:44 PM
  • FYI the underlying issue in the WiX Toolset was finally tracked down (we got a repro at FireGiant and coudl finally hunt down the root problem) and fixed in WiX v3.14.0.1703.

    You should no longer need to use `RunWixToolsOutOfProc` (unless you want to).


    • Marked as answer by DragonLord66 Friday, May 4, 2018 8:09 AM
    Friday, May 4, 2018 6:05 AM

All replies

  • Hi DragonLord66,

    >>Any thoughts as to what it could be and how to fix it?

    According to your description, it works fine when build it in visual studio. It seems that something on server could cause the issue, I would suggest that you could reboot your server system and rebuild the application and check if it works.

    Best regards,
    Li Wang


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, August 3, 2016 9:51 AM
  • This is going wrong with both a local build server and a hosted build server (I installed the local server to see if that would fix it).  As such we can't restart the Hosted server.

    Also, I've tried uploading the wix binaries to the TFS and redirecting the project to that, but that doesn't help.

    Wednesday, August 3, 2016 10:14 AM
  • A stack trace from each thread of the frozen process would help. Either install Debugging Tools for Windows on the server in which it freezes and attach the debugger to the process there, or create a dump file using Task Manager and load that in the debugger. Then run the .symfix and ~*k commands.

    My hunch is that it's frozen in some unmanaged code, perhaps in msi.dll; that would explain why it freezes only in light.exe and not in candle.exe. In this case, an unmanaged-code stack trace should already show useful information and you won't need the managed-code stack trace commands from the SOS debugging extension, which is more difficult to set up.

    Wednesday, August 3, 2016 12:09 PM
  • I'm struggling to get the symbol files for msbuild, as I can't see light.exe in the process explorer.

    Any thoughts as to if I'm a) looking at the right process, or b) a step by step guide as to how to get that information?

    Wednesday, August 3, 2016 2:28 PM
  • This looks a bit strange. Although the source code of the Light task has a comment saying that it runs as a separate process by default, it doesn't seem to set the RunAsSeparateProcess property inherited from the WixToolTask class; and the Link target specifies RunAsSeparateProcess="$(RunWixToolsOutOfProc)" when it calls the Light task, just like the Compile target does with the Candle task.

    It also sets RunWixToolsOutOfProc=true if the MSBuild process isn't x86. Are you using 32-bit or 64-bit MSBuild? I think 64-bit might work better; or if you use 32-bit, then try setting the RunWixToolsOutOfProc property yourself.

    …On the other hand, you wrote it builds OK in Visual Studio, which AFAIK uses 32-bit MSBuild. So, switching to 64-bit MSBuild might not solve your problem, but at least it should cause light.exe to run as a separate process so that you can see it in Task Manager and create a dump file.
    • Edited by ranta Wednesday, August 3, 2016 3:52 PM Visual Studio uses 32-bit MSBuild though
    • Marked as answer by DragonLord66 Wednesday, August 3, 2016 4:36 PM
    Wednesday, August 3, 2016 3:44 PM
  • Well that helped, as it highlighted a load of errors instead of just freezing.

    Thanks for finding that setting :)

    Wednesday, August 3, 2016 4:36 PM
  • WiX actually looks up the DllGetClassFactory export from mergemod.dll, instead of relying on CoCreateInstance. That's why it doesn't need the manifest to which the obsolete comment in the Light task constructor refers.

    This kind of hack seems likely to create the instance in the wrong type of COM apartment, though. I see [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{F94985D5-29F9-4743-9805-99BC3F35B678}\InprocServer32] has ThreadingModel="Apartment", i.e. IClassFactory.CreateInstance must be called in a single-thread apartment (STA); but Binder.ProcessMergeModules doesn't try to ensure this, and the entry point of light.exe even has MTAThreadAttribute. Still, I don't think that is what caused it to freeze under MSBuild, because this threading-model mismatch also occurs when light.exe is run as a separate process.

    Thursday, August 4, 2016 12:20 PM
  • WixToolTask.ExecuteTool temporarily redirects Console.Out and Console.Error to a WixToolTaskLogger instance that enqueues the output strings, and the HandleToolMessages method in another thread then dequeues them and sends them to MSBuild loggers. If TFS makes MSBuild use a logger that in turn writes the message to Console.Out, I think WixToolTaskLogger will enqueue the same message again. The queue would then never become empty, HandleToolMessages would keep looping and not release the lock, and WixToolTaskLogger would hang waiting for the lock if the task tries to write another message. This would explain why it froze on your build servers.

    It looks like this has not been fixed in wix4 either, and none of the issues tagged "msbuild" in the GitHub wixtoolset project describes this problem. If you have an account there, you could perhaps file a bug.

    The ConsoleLogger class of MSBuild reads Console.Out during the constructor and then just keeps using that, so it is unaffected by the redirection and will not hit this bug, unless the FORCECONSOLECOLOR parameter is set or a custom WriteHandler reads Console.Out.

    Here's how to reproduce the problem with a custom logger.

    1. Build a C# class library project that contains the following:
      using System;
      using Microsoft.Build.Framework;
      using Microsoft.Build.Logging;
      
      namespace BuildLogToConsoleOut
      {
          public class ConsoleOutLogger : ConsoleLogger
          {
              public ConsoleOutLogger()
                  : base(LoggerVerbosity.Normal, Console.WriteLine, color => { }, () => { })
              {
              }
          }
      }
      Note that this uses Console.WriteLine rather than Console.Out.WriteLine, which would capture the current value of Console.Out.
    2. Create a WiX setup project using the project template.
    3. Build the WiX setup project like this:
      C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild /logger:..\BuildLogToConsoleOut\bin\Debug\BuildLogToConsoleOut.dll SetupProject1.wixproj
      It outputs some stuff and then hangs without consuming CPU time.
    4. Attach to the MSBuild process with Visual Studio, and break into it. The call stacks of two threads reveal a deadlock.

      In "RequestBuilder thread", WiXtoolTask.HandleToolMessages has locked this.messageQueue and indirectly called Console.Out.WriteLine, which is a synchronized method and is trying to lock Console.Out:

       	[In a sleep, wait, or join]	
      >	System.IO.TextWriter.SyncTextWriter.WriteLine(string)	
       	System.Console.WriteLine(string)	
       	Microsoft.Build.BackEnd.Logging.BaseConsoleLogger.WriteLinePretty(int, string)	
       	Microsoft.Build.BackEnd.Logging.BaseConsoleLogger.WriteLinePretty(string)	
       	Microsoft.Build.BackEnd.Logging.SerialConsoleLogger.MessageHandler(object, Microsoft.Build.Framework.BuildMessageEventArgs)	
       	Microsoft.Build.Evaluation.ProjectCollection.ReusableLogger.MessageRaisedHandler(object, Microsoft.Build.Framework.BuildMessageEventArgs)	
       	Microsoft.Build.BackEnd.Logging.EventSourceSink.RaiseMessageEvent(object, Microsoft.Build.Framework.BuildMessageEventArgs)	
       	Microsoft.Build.BackEnd.Logging.EventSourceSink.Consume(Microsoft.Build.Framework.BuildEventArgs)	
       	Microsoft.Build.BackEnd.Logging.EventSourceSink.Consume(Microsoft.Build.Framework.BuildEventArgs, int)	
       	Microsoft.Build.BackEnd.Logging.EventRedirectorToSink.Microsoft.Build.Framework.IEventRedirector.ForwardEvent(Microsoft.Build.Framework.BuildEventArgs)	
       	Microsoft.Build.BackEnd.Logging.CentralForwardingLogger.EventSource_AnyEventRaised(object, Microsoft.Build.Framework.BuildEventArgs)	
       	Microsoft.Build.BackEnd.Logging.EventSourceSink.RaiseAnyEvent(object, Microsoft.Build.Framework.BuildEventArgs)	
       	Microsoft.Build.BackEnd.Logging.EventSourceSink.RaiseMessageEvent(object, Microsoft.Build.Framework.BuildMessageEventArgs)	
       	Microsoft.Build.BackEnd.Logging.EventSourceSink.Consume(Microsoft.Build.Framework.BuildEventArgs)	
       	Microsoft.Build.BackEnd.Logging.LoggingService.RouteBuildEvent(Microsoft.Build.Framework.BuildEventArgs)	
       	Microsoft.Build.BackEnd.Logging.LoggingService.RouteBuildEvent(object)	
       	Microsoft.Build.BackEnd.Logging.LoggingService.ProcessLoggingEvent(object, bool)	
       	Microsoft.Build.BackEnd.Logging.LoggingService.LogBuildEvent(Microsoft.Build.Framework.BuildEventArgs)	
       	Microsoft.Build.BackEnd.TaskHost.LogMessageEvent(Microsoft.Build.Framework.BuildMessageEventArgs)	
       	Microsoft.Build.Utilities.TaskLoggingHelper.LogMessage(Microsoft.Build.Framework.MessageImportance, string, object[])	
       	Microsoft.Build.Utilities.TaskLoggingHelper.LogMessageFromText(string, Microsoft.Build.Framework.MessageImportance)	
       	Microsoft.Build.Utilities.ToolTask.LogEventsFromTextOutput(string, Microsoft.Build.Framework.MessageImportance)	
       	Microsoft.Tools.WindowsInstallerXml.Build.Tasks.WixToolTask.HandleToolMessages()	
       	Microsoft.Tools.WindowsInstallerXml.Build.Tasks.WixToolTask.ExecuteTool(string, string, string)	
       	Microsoft.Build.Utilities.ToolTask.Execute()	
       	Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()	
       	Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask.MoveNext()	
       	System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask>(ref Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask)	
       	System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.__Canon>.Start<Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask>(ref Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask)	
       	Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(Microsoft.Build.BackEnd.ITaskExecutionHost, Microsoft.Build.BackEnd.Logging.TaskLoggingContext, Microsoft.Build.BackEnd.TaskHost, Microsoft.Build.BackEnd.ItemBucket, Microsoft.Build.BackEnd.TaskExecutionMode)	
       	Microsoft.Build.BackEnd.TaskBuilder.InitializeAndExecuteTask.MoveNext()	
       	System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<Microsoft.Build.BackEnd.TaskBuilder.InitializeAndExecuteTask>(ref Microsoft.Build.BackEnd.TaskBuilder.InitializeAndExecuteTask)	
       	System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.__Canon>.Start<Microsoft.Build.BackEnd.TaskBuilder.InitializeAndExecuteTask>(ref Microsoft.Build.BackEnd.TaskBuilder.InitializeAndExecuteTask)	
       	Microsoft.Build.BackEnd.TaskBuilder.InitializeAndExecuteTask(Microsoft.Build.BackEnd.Logging.TaskLoggingContext, Microsoft.Build.BackEnd.ItemBucket, System.Collections.Generic.IDictionary<string,string>, Microsoft.Build.BackEnd.TaskHost, Microsoft.Build.BackEnd.TaskExecutionMode)	
       	Microsoft.Build.BackEnd.TaskBuilder.ExecuteBucket.MoveNext()	
       	System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<Microsoft.Build.BackEnd.TaskBuilder.ExecuteBucket>(ref Microsoft.Build.BackEnd.TaskBuilder.ExecuteBucket)	
       	System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.__Canon>.Start<Microsoft.Build.BackEnd.TaskBuilder.ExecuteBucket>(ref Microsoft.Build.BackEnd.TaskBuilder.ExecuteBucket)	
       	Microsoft.Build.BackEnd.TaskBuilder.ExecuteBucket(Microsoft.Build.BackEnd.TaskHost, Microsoft.Build.BackEnd.ItemBucket, Microsoft.Build.BackEnd.TaskExecutionMode, System.Collections.Generic.Dictionary<string,string>)	
       	Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask.MoveNext()	
       	System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask>(ref Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask)	
       	System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.__Canon>.Start<Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask>(ref Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask)	
       	Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask(Microsoft.Build.BackEnd.TaskExecutionMode, Microsoft.Build.BackEnd.Lookup)	
       	Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask.MoveNext()	
       	System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask>(ref Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask)	
       	System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.__Canon>.Start<Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask>(ref Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask)	
       	Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask(Microsoft.Build.BackEnd.Logging.TargetLoggingContext, Microsoft.Build.BackEnd.BuildRequestEntry, Microsoft.Build.BackEnd.ITargetBuilderCallback, Microsoft.Build.Execution.ProjectTargetInstanceChild, Microsoft.Build.BackEnd.TaskExecutionMode, Microsoft.Build.BackEnd.Lookup, Microsoft.Build.BackEnd.Lookup, System.Threading.CancellationToken)	
       	Microsoft.Build.BackEnd.TargetEntry.ProcessBucket.MoveNext()	
       	System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<Microsoft.Build.BackEnd.TargetEntry.ProcessBucket>(ref Microsoft.Build.BackEnd.TargetEntry.ProcessBucket)	
       	System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.__Canon>.Start<Microsoft.Build.BackEnd.TargetEntry.ProcessBucket>(ref Microsoft.Build.BackEnd.TargetEntry.ProcessBucket)	
       	Microsoft.Build.BackEnd.TargetEntry.ProcessBucket(Microsoft.Build.BackEnd.ITaskBuilder, Microsoft.Build.BackEnd.Logging.TargetLoggingContext, Microsoft.Build.BackEnd.TaskExecutionMode, Microsoft.Build.BackEnd.Lookup, Microsoft.Build.BackEnd.Lookup)	
       	Microsoft.Build.BackEnd.TargetEntry.ExecuteTarget.MoveNext()	
       	System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<Microsoft.Build.BackEnd.TargetEntry.ExecuteTarget>(ref Microsoft.Build.BackEnd.TargetEntry.ExecuteTarget)	
       	System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.Threading.Tasks.VoidTaskResult>.Start<Microsoft.Build.BackEnd.TargetEntry.ExecuteTarget>(ref Microsoft.Build.BackEnd.TargetEntry.ExecuteTarget)	
       	System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start<Microsoft.Build.BackEnd.TargetEntry.ExecuteTarget>(ref Microsoft.Build.BackEnd.TargetEntry.ExecuteTarget)	
       	Microsoft.Build.BackEnd.TargetEntry.ExecuteTarget(Microsoft.Build.BackEnd.ITaskBuilder, Microsoft.Build.BackEnd.BuildRequestEntry, Microsoft.Build.BackEnd.Logging.ProjectLoggingContext, System.Threading.CancellationToken)	
       	Microsoft.Build.BackEnd.TargetBuilder.ProcessTargetStack.MoveNext()	
       	System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<Microsoft.Build.BackEnd.TargetBuilder.ProcessTargetStack>(ref Microsoft.Build.BackEnd.TargetBuilder.ProcessTargetStack)	
       	System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.Threading.Tasks.VoidTaskResult>.Start<Microsoft.Build.BackEnd.TargetBuilder.ProcessTargetStack>(ref Microsoft.Build.BackEnd.TargetBuilder.ProcessTargetStack)	
       	System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start<Microsoft.Build.BackEnd.TargetBuilder.ProcessTargetStack>(ref Microsoft.Build.BackEnd.TargetBuilder.ProcessTargetStack)	
       	Microsoft.Build.BackEnd.TargetBuilder.ProcessTargetStack(Microsoft.Build.BackEnd.ITaskBuilder)	
       	Microsoft.Build.BackEnd.TargetBuilder.BuildTargets.MoveNext()	
       	System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<Microsoft.Build.BackEnd.TargetBuilder.BuildTargets>(ref Microsoft.Build.BackEnd.TargetBuilder.BuildTargets)	
       	System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.__Canon>.Start<Microsoft.Build.BackEnd.TargetBuilder.BuildTargets>(ref Microsoft.Build.BackEnd.TargetBuilder.BuildTargets)	
       	Microsoft.Build.BackEnd.TargetBuilder.BuildTargets(Microsoft.Build.BackEnd.Logging.ProjectLoggingContext, Microsoft.Build.BackEnd.BuildRequestEntry, Microsoft.Build.BackEnd.IRequestBuilderCallback, string[], Microsoft.Build.BackEnd.Lookup, System.Threading.CancellationToken)	
       	Microsoft.Build.BackEnd.RequestBuilder.BuildProject()	
       	Microsoft.Build.BackEnd.RequestBuilder.BuildAndReport.MoveNext()	
       	System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<Microsoft.Build.BackEnd.RequestBuilder.BuildAndReport>(ref Microsoft.Build.BackEnd.RequestBuilder.BuildAndReport)	
       	System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.Threading.Tasks.VoidTaskResult>.Start<Microsoft.Build.BackEnd.RequestBuilder.BuildAndReport>(ref Microsoft.Build.BackEnd.RequestBuilder.BuildAndReport)	
       	System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start<Microsoft.Build.BackEnd.RequestBuilder.BuildAndReport>(ref Microsoft.Build.BackEnd.RequestBuilder.BuildAndReport)	
       	Microsoft.Build.BackEnd.RequestBuilder.BuildAndReport()	
       	Microsoft.Build.BackEnd.RequestBuilder.RequestThreadProc.MoveNext()	
       	System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<Microsoft.Build.BackEnd.RequestBuilder.RequestThreadProc>(ref Microsoft.Build.BackEnd.RequestBuilder.RequestThreadProc)	
       	System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.Threading.Tasks.VoidTaskResult>.Start<Microsoft.Build.BackEnd.RequestBuilder.RequestThreadProc>(ref Microsoft.Build.BackEnd.RequestBuilder.RequestThreadProc)	
       	System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start<Microsoft.Build.BackEnd.RequestBuilder.RequestThreadProc>(ref Microsoft.Build.BackEnd.RequestBuilder.RequestThreadProc)	
       	Microsoft.Build.BackEnd.RequestBuilder.RequestThreadProc(bool)	
       	Microsoft.Build.BackEnd.RequestBuilder.StartBuilderThread.AnonymousMethod__9()	
       	System.Threading.Tasks.Task<System.Threading.Tasks.Task>.InnerInvoke()	
       	System.Threading.Tasks.Task.Execute()	
       	System.Threading.Tasks.Task.ExecutionContextCallback(object)	
       	System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, object, bool)	
       	System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, object, bool)	
       	System.Threading.Tasks.Task.ExecuteWithThreadLocal(ref System.Threading.Tasks.Task)	
       	System.Threading.Tasks.Task.ExecuteEntry(bool)	
       	System.Threading.Tasks.ThreadPoolTaskScheduler.LongRunningThreadWork(object)	
       	System.Threading.ThreadHelper.ThreadStart_Context(object)	
       	System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, object, bool)	
       	System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, object, bool)	
       	System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, object)	
       	System.Threading.ThreadHelper.ThreadStart(object)	
       	[Native to Managed Transition]	
      

      In an anonymous worker thread, Candle.Run has called Console.Out.WriteLine, which has locked Console.Out and indirectly called WixToolTask.WixToolTaskLogger.Write, which is trying to lock this.messageQueue:

       	[In a sleep, wait, or join]	
      >	Microsoft.Tools.WindowsInstallerXml.Build.Tasks.WixToolTask.WixToolTaskLogger.Write(char)	
       	System.IO.TextWriter.Write(char[], int, int)	
       	System.IO.TextWriter.WriteLine(string)	
       	System.IO.TextWriter.SyncTextWriter.WriteLine(string)	
       	Microsoft.Tools.WindowsInstallerXml.Tools.Candle.Run(string[])	
       	Microsoft.Tools.WindowsInstallerXml.Tools.Candle.Main(string[])	
       	[Native to Managed Transition]	
       	Microsoft.Tools.WindowsInstallerXml.Build.Tasks.WixToolTask.ExecuteToolThread(object)	
       	System.Threading.ThreadHelper.ThreadStart_Context(object)	
       	System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, object, bool)	
       	System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, object, bool)	
       	System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, object)	
       	System.Threading.ThreadHelper.ThreadStart(object)	
       	[Native to Managed Transition]	
      

      Although I wrote earlier that the WiX code would go to a busy loop reading text from the queue, this is actually a deadlock. I didn't realize that Console.SetOut constructs a SyncTextWriter around the specified TextWriter.

    This experiment proves that WiX will hang if an MSBuild logger reads the Console.Out property and writes to that TextWriter. However, this does not prove that TFS uses such a logger.


    • Edited by ranta Monday, August 8, 2016 5:42 PM correct whitespace in MSBuild invocation
    Friday, August 5, 2016 1:47 PM
  • Thanks for going into more depth, I don't have an account there. But hopefully this question will have enough detail in it that the next person to have this problem will find it instead of scratching their heads for a few days.
    Monday, August 8, 2016 9:21 AM
  • FYI the underlying issue in the WiX Toolset was finally tracked down (we got a repro at FireGiant and coudl finally hunt down the root problem) and fixed in WiX v3.14.0.1703.

    You should no longer need to use `RunWixToolsOutOfProc` (unless you want to).


    • Marked as answer by DragonLord66 Friday, May 4, 2018 8:09 AM
    Friday, May 4, 2018 6:05 AM
  • Latest Wix I see is 3.11.1?! http://wixtoolset.org/releases/
    Sunday, May 27, 2018 3:21 PM