Craziest fix that actually worked

[LordWabbit1]

One company I worked for rebooted their Red Hat box every day at 4 in the morning, otherwise it would inexplicably freeze and drop messages (ie. money). It was not the OS's fault though, it was the crappy java/jboss app that did the messaging from the mainframe to swift and back. The log files it produced were over a gig each day and everyone spent some jail time sifting through them to try figure out what exactly caused the freeze. AFAIK they are still rebooting them every day.

[G Tek]

That is hilarious. I actually a lol moment when I read that. So all these years that I've made fun of people that continuously "exercised" their mouse while waiting for results (I've been guilty myself) and you're telling me that it's a legitimate solution? Too bad they don't give the explanation behind why the method works.

[englebart]

A person that used Scantron sheets for data entry upgraded their computer. After the upgrade, the computer could no longer communicate with the Scantron reader. It was a simple RS-232 interface. Reconnecting to the old computer, I noticed that the Scantron "ready" light would activate for about 30 seconds during which time the sheets would be successfully fed. With the new computer, the Scantron "ready" light would activate for about 0.2 seconds. Solution: toggle "Turbo" mode off for reading Scantrons. This gave them about a 5 second window to feed the sheet. Dang hard coded delay loops!

[Eric Whitmore]

I once had network problems at 10:12 am every morning. It turns out that the static electricity produced by office staff walking on the carpet at the office was running up an unplugged cat5 cable short circuiting the cheap hub we had. Unplugged the cable from the hub completely and no more problems. craziest problem i have ever had to solve.

Eric

[DerekT P]

My very first paid job involved some Fortran development on an IBM360. I'd go home at 5pm each day, having logged out and powered down my terminal. (I don't recall what system we used, but this was 1977). Each morning I'd find the other staff scratching their heads about the mysterious crash of the '360 the evening before. This happened each day for a week until I overheard one of them saying "the only thing I can think causing it is someone's powering down their terminal". I left my terminal on after that and the daily crashing problem "went away". I never did own up.

[Ennis Ray Lynch Jr]

What a weird response, suggesting that somehow skype an use port 80 and not interfere with XAMPP but that somehow my code would have a problem. Normally, I would just say it is a little too late to go back to that decade and change code mandated by a very large client who would only open port 80 and just say, but only because I think honesty is the best policy, maybe you should go and learn how TCP/IP works.

Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch

[Chris Quinn]

There was a problem with earlier versions of MSOffice where it would not install or run properly unless you renamed a particular TrueType font file (Hattenschwiller) - See here:[^]

---

It's well known that if all the cat videos and porn disappeared from the internet there would be only one site left and it would be called whereareallthecatvideosandporn.com

---

[GenJerDan]

It happens with hardware, too. Our satellite dish would simply not track the damn satellite. I fixed it by disconnecting a blue wire. No idea what that particular blue wire was connecting...there were hundreds of them in there and we didn't have detailed schematics available. And, yes, the report we sent in closing the ticket did say "disconnected a blue wire". :laugh:

YouTube and My Mu[sic], Films and Windows Programs, etc.

[kalberts]

Removing the PC cover to give the program enough space to fit in... This was back in the DOS days. It kept our hardware service guy puzzled for a week: As long as the cover was off the PC, the application ran flawlessly. Once he put the cover back on, the application crashed. The reason was that the program was too big for the physical memory, with no check for this to give a reasonable error message. Some PCs in those days had covers that slid backwards: You simply had to unplug the power cord and everything else before getting access to the inner workings. This was a deliberate security measure. You had to plug in the cables again after removing the cover; presumably the service man knew to be careful. After sliding the cover back on, he plugged in everything, including the mouse. We were running Win 2.11 at the time, starting Windows only for those special applications needing it. So during the boot, the driver tries to make contact with the mouse, succeeds, and stays in RAM. This DOS application didn't use the mouse; it was a pure command line application. At the hardware service bench, it failed to find any mouse (because it wasn't plugged in), terminated, and a couple hundred bytes were freed. Enough to make the application run. Obviously, we didn't really need to remove the cover - unplugging the mouse and rebooting would do the trick. But for a week, until we saw the light, the only way we knew to avoid the crash was to remoe the cover.

[BrainiacV]

Erudite_Eric wrote:

Taking a space character out of a modem name string on Windows.

Yeah I had something like that, I had to take the space out of a window name. Only MSIE freaked when it had one.

Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.

[PIEBALDconsult]

Naerling wrote:

A Thread.Sleep(500) fixed the problem!

I've used a Sleep(50) between reads of a socket to ensure unique timestamps for each message. :rolleyes:

[kalberts]

In the late 1970s when 64 kbit RAM chips (yes, 8 kbyte) were appearing, they were plauged by bit errors said to be caused by alpha radiation from outer space. People were worried that no denser memory chips could be made. (I have no idea how they got around that problem, but that is irrelevant to this story.) Norsk Data, a Norwegian manufacturer of 16-bit minimachines, increased the number of ECC bits from five to six per 16-bit memory word (from 21 to 22 bits/word) to cope with the high bit error rate. Every time an error was corrected, a red LED on the memory card would flash up. If the LED was more or less constantly flashing, that card should be replaced. (Usually, it was sufficient to replace one or more unreliable RAM chips on the board - the chips varied in their sensitivity to this alpha radiation.) One of my colleauges was working at a satellite ground station - actually, the one used for the very first transatlantic Internet connection. It just had to be operational 24/7; computers couldn't be turned off to replace a memory card. So for this project, my colleague set up one of these minicomputers with 22 memory cards (!) which he had rewired to store one bit per card, rather than full words + ECC on one card. Now, if the warning LED was too busy on one of the cards, he could snap it out and insert a new one while the computer was running at full speed. Of course there would be a lot of bit errors while one of the 22 cards were missing, but the ECC could handle all 1-bit and most 2-bit errors (all? That math has left my brain...) until the new card was in place. This setup was used for actual production work for months (maybe years, I wasn't invoved myself). They kept a supply of tested spare memory cards, gradually weeding out those populated with less reliable chips, so the replacement rate was gradually falling. If anyone can point me to info on how the REAL problem was fixed - the alpha radiation sensitivity of the RAM chips - I would be curious to know!

[eFotografo]

Many (many!) years ago, I hooked up (soldered!) a second tape recorder to a standard Commodore VIC20 tape recorder, so I could (ahem :-)) "backup" game cassettes. Curiously the "backed up" cassettes would only load correctly (and only from the Commodore recorder) when the second tape recorder was still attached (but not recording) and only then if the speaker was switched on and at high volume.

[RafagaX]

This a known error for those who use Excel Interop and also want to use it with a system account (mostly Windows services), and actually I encountered this problem once, the solution was that the installer of our application will create this folder if it didn't exist.

CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...

[costas0811]

Had built a Slot Machine game that was meant to be played on the iPad. When you spun the slot sounds played normally, but I guess there are restrictions so that sounds cannot be played unless it is a user event that spawns them. So I was at a loss. A slot machine without sounds is actually pretty lame. Friend suggested - as a complete guess - that I edit all the sounds into one massive wave file with gaps of time in between and that on the other timed events I just forward to the index where the sound plays that I need. It was so ludicrous that I did it as a joke to prove how badly it would not work, but of course it worked perfectly. Still can't believe that one.

[patbob]

HW: video/audio recorder app running on a dual core laptop. Had to use windows boot options to set NUMCPUS to 1 so the video viewfinder display update wouldn't stop when the user stopped recording the audio. SW: Same app, video arrived as a series of undelineated JPEGs in a byte stream, 90 per second. 700 MHz computer couldn't run a loop to find the jpegs fast enough (it had to look for the first four bytes of a jpeg). Had to add an if at the top of the loop to check if the next couple of bytes in the byte stream were the first two bytes of a jpeg and continue if they were not.

We can program with only 1's, but if all you've got are zeros, you've got nothing.

[erzengel des lichtes]

I'm actually guilty of writing a program where, in one version, "move the mouse" was required to keep it from getting stuck while processing in certain conditions. In my case, I neglected to close a file that was reopened later. It got stuck because it was waiting for someone to release the file, but it was holding the file itself. Moving the mouse produced enough garbage to trigger the garbage collector, which then closed the file that was no longer in use. Once the finalizer had closed the file, the app was able to open the file and continue. It wasn't caught in QA because usually enough work was done in QA's tests that the garbage collector would be triggered at least once... Technicians only had to move the mouse for a few days while the patch went through QA...

[Mike Riley QUSA]

I worked for a company where a small group of us had created a multi-user OS that ran on x86 CPUs. I had created the filesystem design and all of a sudden we ran into an issue where directory blocks where somehow being written to the wrong place in the directory. This wiped out the entries that had been in that block and created duplicate directories entries for the files in the block that had been copied. We couldn't figure out the root cause, because it happened so rarely and only some customers saw it more than once. I used a spare dword in the header block, which stored the allocation block numbers for the file data as well as file attribute info, and stored the block number for the directory entry it should be using. There were then checks made in utilities for directory listings and file searches that checked that the correct directory entry was being used and reported an error if it saw a mismatch. So now duplicate directory entries showed as bad entries when doing a directory listing, but it didn't do that until well after it had occurred. So I added a check in the write directory block routine to also do the check. It would generate an error if it had ever been told to write a directory block to a sector that did not match what was in the file header. This would only happen during a create, close, or delete operation. Once the code with that check went out the error never happened again. No fix was done. I had only created a check to report an error to catch it happening before it wrote to the wrong directory sector. I called it the Schrodinger's Cat bug. Just looking in the box prevented it from ever happening. Mike

[Member 3257606]

I read about a ground fault circuit trap tripped an old computer way back - but only after hours. The guy who tried to find it could watch it run for hours, and every time he came back after taking the elevator to get a cup of coffee, the computer would be down... My favorite fix came around February 2000 - a customer using an imaging system (third party software we provided running on SQL Server 6.5) was suddenly experiencing major performance issues and consistently timing out against the database. We couldn't change the app or the query it issued. The database seemed to be working fine, except for the one query, which had been working great until it suddenly started timing out. No amount of basic database repair or index tweaking seemed to help. We finally decided that the selectivity of one of the main indexes for the application caused the wrong plan to be chosen. Solution: Insert 40 thousand dummy records with the only purpose to change the selectivity of the index. Worked like a charm. I should mention that a subsequent service pack update to SQL Server allowed us to remove the dummy records.

[Member 3257606]

ND was a great place to work!