It really is the worst. Machines custom-built thirty years ago with documentation that reflects about 25% of the current configuration. Processes that rely on five lines of code and run great for six hours before completely breaking for no good reason. Windows XP boxes that've been on continuously for five years because the moment they shut down a boiler fails that requires a 24-hour restart process. I'm incredibly glad I got out of that industry.

A 24-hr restart plan, sounds like a properly documented quality management process for a large boiler? Disconnecting the "Windows XP box" is removing the control system correct? Not really the same thing is it? There's no reason the XP Embedded hardware platform could not have been engineered with high availability in mind? It's not as if there are no comercial-off-the-shelf options here.

The company who chooses to let the bosses son, who built custom PCs in high school, design the critical process control systems, is I'd say, outside the scope of the argument here.

It was literally an e-machines desktop.

I'll just add at my current place with clustered Windows 2008 back-end, with AD and DFS, and distributed flash based , fan-less, Windows 7 embedded clients we've had zero down time in 8 years or so since it was implemented. End-Nodes provide serial data from the DFS shares to the machines. I'll grant you that is certainly easier than redundant real time control issues, a little bit. But. It's just all about planning for sure, on the software, hardware, and IT infrastructure end of it.

Haha. Been there. Seen that. I do feel for you though.

The uptime on that machine is longer than the time between new versions of windows. This is an example where software isn't like disposable plastic.