Personal craziest was an Oracle performance problem on Windows NT in the 90s. Slow as hell. Going to the server, logging in, checking everything: Blazing fast. Back at the desk, slow as hell. Problem was the GL tube screen blanker with software rendering :-)
Bug report from a bank said that a customer's birth date was not accepted when trying to open an account - they'd tried and found that any data within a range of about a month in the summer of 1945 was not accepted. This was a German bank, and the application was written in Java.
I could reproduce the bug and found that the date was rejected at a very low technical level in the Calendar class (long before any domain validation happened), just as if you'd entered the 30th of February. Some debugging sessions later I found that the Calendar class calculates a lot of internal date and time fields, and the daylight savings time field containd a value of 2 hours, which was rejected by internal sanity checks.
The name of that field led me to a Java API bug report which explained everything: The Locale for Germany is "centered" on Berlin, and in the summer of 1945 Berlin and the Soviet-occupied zone of Germany actually did have a 2 hour daylight savings time (which happened to be identical to Moscow time). Some smartass in the Java development team had "corrected" the sanity check in Java 1.4 because he believed 1 hour DST to be the maximum - but Berlin is in fact not the only timezone which had a 2 hour DST at one time or another. The bug was fixed in Java 1.5
Anyway, eventually my colleague wrote a small VB program that maximized and minimized the window every few minutes. Cured the problem.
Cached version http://webcache.googleusercontent.com/search?q=cache:http://...
Turned out it was the 'power saving' setting on the PC. To save a couple of watts it slowed down the CPU, and screwed up a furnace that burned megawatts. Probably wasted more electricity in a day than the 'power save' feature saved in the whole US for a year.
We worked hard and fleshed out a good design quickly. We iterated a few times, then released. We soon got a major bug report from the field: the server would lock itself up after some time! I was baffled; I didn't write much in the way of threading code. I pored over the entire codebase several times looking for any possibility of deadlock. Nothing.
Finally, I went out to the customer site when it happened again. Someone had selected text in the console window the server was running on, which effectively halted the process. I wrote a small wrapper around the server that launched it as a service, and that fixed it.
(I probably should have written it as a service originally, but I was fresh out of school, so I instead took it as a hard knock.)
Users should learn how to deal with console windows.
It was an oversight somehow - upgraded hardware but didn't complete the install checklist which included disabling powersave. People make mistakes.
But the site uses a fully-qualified link to its stylesheet and so won't render.
http://fxr.watson.org/fxr/source/i86pc/ml/locore.s?v=OPENSOL...
