Activate downloaded upgrade sometimes fail


I agree. It does more bad than good.


Not sure why that task is being disposed, there is no need to dispose the task, so you can remove the using around it, but I am not sure it fixes anything.

Any idea why the new pair is not responding to the parent WindowsService process?


None at all lol, will try to debug some time later today


It is possible that the closed process somehow closes the stdin/stdout of the WindowsService process, which makes it unable to ping-pong the new pair and that cause it to think it has stopped working.


I just tested the changes made in that commit (the ones that were reverted) without disallowing WindowsService to use the autoupdater, in other words, I did not do what is said here:

That means that the behavior is for the entire stack to exit, leaving recovery to the Services Manager.

This time, using the debugger, this is what happens:

  1. We have a normal stack of:
    1.1. Base WindowsService.exe
    1.2. Newest WindowsService.exe (also base)
    1.3. Newest Server.exe (base)
  2. I download and activate the latest update
  3. Server exits with the magic code
  4. Newest WindowsService detects the MAGIC_CODE, according to the committed changes
  5. Base WindowsService also detects MAGIC_CODE and therefore does not exit, it proceeds looping at this section of the code:
  1. When it tries to launch the newest WindowsService, the child process exits instantly. I’m pretty sure of this because I’ve added a Debugger.Launch() and Debugger.Break() as the first two lines on WindowsService.Main() and I don’t get prompted to launch the debugger.

By using the debugger, I’ve dumped the proc variable right after it is defined, this is what I get: - proc {System.Diagnostics.Process} System.Diagnostics.Process Associated tr -


I’ve done the same process with the proposed change (calling RealMain directly from WindowsService and let Server sort its newest version) and everything seems normal from the lines executed. No idea why I/O breaks.