I'm unable to comment but would like to share an opinion:

Task.Factory.StartNew is queueing the callback on to the ThreadPool. This can be seen if one looks at the source code:

• StartNew

  • https://source.dot.net/#System.Private.CoreLib/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/TaskFactory.cs,d107c03204fc34e1

• internal StartNew

  • https://source.dot.net/#System.Private.CoreLib/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs,ca049b8b7d014a0d

• ScheduleAndStart

  • https://source.dot.net/#System.Private.CoreLib/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs,107ac97251bea153

Which means that the Console.ReadKey is running in the background thread. This is interesting because the Task will not be started immediately, which gives time for other stuff to happen in the mean time (unlike the direct approach).

The main difference between these two is that the former one will continue executing while the latter will block until a key is read (in both examples the Task is not awaited).

Calling the ReadConsoleInput directly is what is causing the issue, here's why I think that: somewhere before ReadConsoleInput is called you are calling some other un-awaited async Console method which does some kind of reading (Console.In.[...], Console.Out.[...] etc.) or something else Console related.

Both Console.ReadKey and the other method are in a deadlock because both are locking on themselves:

• https://source.dot.net/#System.Console/System/IO/SyncTextReader.Unix.cs,ebee0a78f846715f

• https://source.dot.net/#System.Console/System/IO/SyncTextReader.cs,21ee17a8c2ef18cb,references

Reason why starting the process with TaskFactory is working is because the other method completed its work or got disposed.

I will delete this answer if any of the above is wrong (assumptions or otherwise) or unhelpful.