The computer may freeze under various circumstances. These are the ones I can think of now:
x86 CLI and HLT . CLI disables interrupts, so no asynchronous event (for example, a timer interrupt or a key press) can move the CS:EIP instruction pointer to another command and the HLT literally stops the processor.
The instruction is rarely used and only allowed by the kernel if some initialization procedure in the boot code fails, for example. Although restarting is the best option here.
Note that HLT stops the kernel from starting , not all .
The window is not responding (usually on Windows). This is different from application to application. More details here .
An attempt was made to obtain a resource, but it is protected by a lock and has already been received. The process waits (actually busy-loops or gives another process) until it finally can get the resource. This is only a temporary condition , but unlike ...
Dead end. Many circumstances in which this can happen, but common, are two processes trying to get the resources that they provide each other at the same time. No one can process a receive request because both are waiting for other processes, so both processes end without interruption . This is the cause of uninterrupted Linux processes that cannot be killed even though they sent a signal.
Multitasking on a slow processor or processor with multiple threads. A poor scheduling algorithm makes the situation even worse.
Since one process occupies at least one thread, the number of processes that work efficiently simultaneously is very small. It can be stabilized by a very fast processor. This leads to a long response time for events such as mouse clicks.
For x86 systems, the HLT is the only instruction that really prevents the instruction pointer from progressing.
All other cases are simply (potentially infinite) loops or program / operating system errors.