Weird Board Freeze

I have had this happen five times now. I am working on a small show on the full console. Client/Server, only 4 universes, and barely at that. I am programming along, not too fast and not slamming too many things at once when the board screens all go black and the mouse turns to an x and I can't restart any engines using pig open backspace. No response at all. So I have to reboot. I thought it was the one console I was using, so I switched the desks and rebooted (the one I was programming on I switched to my left and I started programming on the desk that was fine) and the SAME behavior happened. I had a wireless router in, so I unplugged that, and switched out some cables. I only programmed for an hour or so ater the last one, so I'm not sure if I solved it. Anyone had this happen?

The screens look EXACTLY like they do when you tell the console to quit and the screens go black before it tells you it's safe to shut the board down.

Any help would be great.

2.6.0 software, one ELO touchscreen in, one LCD monitor.
Parents
  • The fact that PIG+OPEN+BACKSPACE does not open the task manager on the H3 indicates that either the FP driver process has crashed or that the front panel has just gone off into the weeds. This is a pretty hard crash and it is rare to see FP driver crash but when it does you are correct that the only way to recover is through powercycle.

    In the event that this is a software problem it's difficult to debug because of the fact that it is so random and also because we don't have any dmp logs or stack traces to look at on this one.

    We do tons of mundane patching and lamp strike stuff here in our test lab everyday and I can honestly say we have not been seeing this.

    If this is somehow hardware related, the only common item I am seeing in this thread is the use of an ethernet switch.
Reply
  • The fact that PIG+OPEN+BACKSPACE does not open the task manager on the H3 indicates that either the FP driver process has crashed or that the front panel has just gone off into the weeds. This is a pretty hard crash and it is rare to see FP driver crash but when it does you are correct that the only way to recover is through powercycle.

    In the event that this is a software problem it's difficult to debug because of the fact that it is so random and also because we don't have any dmp logs or stack traces to look at on this one.

    We do tons of mundane patching and lamp strike stuff here in our test lab everyday and I can honestly say we have not been seeing this.

    If this is somehow hardware related, the only common item I am seeing in this thread is the use of an ethernet switch.
Children
No Data
Related