Weird issue with C# console app on a specific machine

Question

I have the simplest C# console app that only does a WriteLine and a ReadLine. For some reason, it doesn't run in standalone mode on the machine it was built. I tried the built executable on another box and it works fine.

Trying to run it on this machine makes it just hang there. It works fine inside VS, just not from the command line.

Trying to attach VS to the hanging process says something along the lines of "ConsoleApplication1 has triggered a breakpoint" but can't see what the problem is (it indicates the breakpoint is _LdrpDoDebuggerBreak@0() in ntdll.dll).

Any ideas on how to diagnose what's going on?

EDIT (answering comments below): Same behavior happens for both Release and Debug. Platform is set to Auto. Both machines tested on are 64-bit. The one it's working on is Windows 7, the one I'm building on (and where it hangs) is Windows 10.

EDIT2: Something else I noticed is that trying to run the app doesn't bring up a console window (so it hangs before that). Also, detaching after attaching to the hanging process also hangs VS.

EDIT3: Here's the full zipped project: (removed). It contains the debug .exe file as well for the curious. It's just a vanilla console application project with the following code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApplication1
{
  class Program
  {
    static void Main(string[] args)
    {
        Console.WriteLine("ASD");
        Console.ReadLine();
    }
  }
}

Answer 1

Are you sure that there's nothing in your code except a WriteLine() and a ReadLine()? I haven't tested it, but this sounds like exactly the behavior I would expect from calling Debugger.Break() .

The MSDN page has a note:

Starting with .NET Framework 4, the runtime no longer exercises tight control of launching the debugger for the Break method, but instead reports an error to the Windows Error Reporting (WER) subsystem. WER provides many settings to customize the problem reporting experience, so a lot of factors will influence the way WER responds to an error such as operating system version, process, session, user, machine and domain. If you're having unexpected results when calling the Break method, check the WER settings on your machine. For more information on how to customize WER, see WER Settings. If you want to ensure the debugger is launched regardless of the WER settings, be sure to call the Launch method instead.

On the machine where it is working, it's either ignoring this line because you don't have development tools installed, or your settings are such that it just skips it. On the machine you're developing on, the settings would be different. Possibly fees are based on the Windows 7 and 10 defaults, but I don't know.

Answer 2

Finally figured it out. It's my lovely antivirus. Hoping this helps someone in the future, Avast doesn't bring up the usual prompt indicating it's scanning the app or quarantining it or anything. Disabling the shields (Avast Shields Control -> Disable for 10 mins) makes the app work properly. Argh!

Thank you all for the support!

Interestingly the other machine where it works is still running Avast, but I think it's one major version behind. This is for version 10.4.2233.