Yes, it is possible. Indeed there has to be something very unusual about what I am doing.

The only software I can think of common to all 4 PCs were MS Office, Visual Studio and Eclipse, Chrome and Acrobat Reader all of which I would expect many Mathematica users to also use. Also Norton Internet Security would be on all of them.

One of the 4 PCs is only accessible through a remote desktop and has no graphics card, so I can cross off a wide range of video and graphics-intensive programmes or games that would never have been installed there.

In the past, I thought it could be a MariaDB JDBC driver as the vast majority of my notebooks read from a centralised database and this driver would be on all PCs, but later I have had examples fail that didn't use the database at all and the failures were certainly not commonly happening during database functions or commands in Mathematica.

I also wondered about network devices, especially printers and have tried removing these from the PC I am currently using, but haven't found a culprit yet.

However, I think your direction is a good one to reflect on.

Is there any chance you can pare down to a smallish example? It is likely to be something along the lines suggested by Szabolcs Horvat. So the smaller the MCE ("minimal crashing example") the better, in terms of likelihood we might track it down.

Mathematica Kernel will quit due to "a malformed program" and or "syntax error" in the case your running several expressions: it stops to prevent mis-use of the kernel - which could effect "other things" if it were to continue wildly (the kernel by default has access, via your code, to your disk - you wouldn't want a stray program messing your files up).

New users also tend to have problems with Context[] and "already defined variables". (they try to evaluate expressions using "x" but it is already defined, and they become confused that the result isn't what they expected)

Also - installing "malware" or poorly conceived 3rd party software can effect your OS Desktop libraries, causing unexpected closures of applications.

I will not prescribe to 12.1 has new bugs until one has been identified. We have not identified a bug nor shown it to be repeatable, here, yet.

"This happens seemingly at random every 3 hours or so and if I re-evaluate the notebook it usually runs fine."

This is the strongest clue Mathematica has nothing to do with what is going on. I strongly suspect the Mathematica app isn't the only software on your PCs that is effected.

Let me ask: do you have video drivers that update every 3 hours? your using windows10 and have enabled continual updates for drivers maybe?

Is the problem appearing with every notebook you use? Or is it specific to notebooks that exercise a particular set of computations? I am guessing the latter since this does not seem to happen to other users, at least not at the rate you describe.

A further guess has two possibilities. (1) Some of your code uses functions that make themselves use time constraints internally. This can account for the stochastic nature of crashes that you experience. Again, if you can isolate an example that is likely to crash given sufficient time, we can have a look. (2) This happens when you are using a Front End and mousing around during a computation. In some cases the FE triggers a Kernel computation, and if the Kernel is in uninterruptible (e.g. library) code a lock-up can ensue. I believe most issues of this sort were addressed with the release of 12.0, but perhaps some still linger.

As currently described, the problem remains too vague to really diagnose.

(1) What I stated about not seeming to happen to other users was correctly worded. Of course I cannot know this for a fact. But when an issue of this sort is recurring, Technical Support has a way of letting that be known.

(2) That x=5 example is possibly an anomaly. My unruly Linux OS has a habit of occasionally bringing up moribund windows for Firefox, Thunderbird new messages or replies, and Mathematica. The typical symptom is that the window will require several seconds to register key strokes, and will be extremely laborious to scrol throughl. This is very clearly an OS/hardware issue, it is sporadic, and it is the type of problem that could perhaps also give the sort of Mathematica behavior you indicated with that particular example. Another possibility is that that particular starting of the Kernel process happened to run you out of RAM on that occasion. But I suspect the more typical crash case you report is caused by some specific issue inside the Mathematica Kernel rather than issues with your OS/hardware configurations, if (big if) most of the instances share a small group of types of computations, e.g. machine arithmetic linear algebra, or symbolic definite integrals, or linear optimizations, or...

(3) Do you have a TS report number? I can probably track down a crashing example notebook with that information.

Has anyone else had this problem and found a solution?

This is not a general problem, but a crash bug triggered by something specific you do. Wolfram will only be able to fix this if you can identify the specific command, or sequence of commands, that causes the crash. Sometimes crashes are not fully deterministic, but there is still one specific evaluation that causes them (just not 100% of the time).

In short, the only thing that can be done is to track down the offending evaluation (which, admittedly, is often a lot of work). Once you do, report it, and hopefully Wolfram will fix it. You can also ask here (or on https://mathematica.stackexchange.com/) for an alternative way to perform the same operation without a crash.