BSOD Makes Appearance at Olympic Opening Ceremonies 521
Whiteox writes "A BSOD was projected onto the roof of the National Stadium during the grand finale to the four-hour spectacular at the Olympics. Lenovo chairman Yang Yuanqing chose to go with XP instead of Vista because of the complexity of the IT functions at the Games. His comment on Vista? 'If it's not stable, it could have some problems,' he said. Evidently Bill Gates attended the opening ceremony, so he must have witnessed it."
Re:well (Score:2, Informative)
IIRC the commentators stated the amount spent on the ceremony was $30 million. The total renovation of Beijing to host the ceremony was $40 billion.
Either way it's quite sad that one of the only glitches in such a spectacular show was with a MS product.
They were Axon mediaservers running WinXP Embedded (Score:3, Informative)
They were Axon mediaservers running WinXP Embedded: http://www.windowsfordevices.com/news/NS4787005167.html [windowsfordevices.com]
Some of the video projectors (70 of about 160 if I recall correctly) connected to those mediaservers were equipped with HES Orbital Head ( http://www.highend.com/products/digital_lighting/orbitalhead.asp [highend.com] ), which can explain the odd positioning of BSOD.
Re:well (Score:4, Informative)
Re:well (Score:5, Informative)
Just a heads-up... the ROC initials usually refer to the Republic of China, which is the government in control of Taiwan. The Chinese mainland is controlled by the People's Republic of China, initials PRC. This is a really, really big distiction.
Re:Doesnt look like a BSOD... (Score:4, Informative)
Um... Mac still has them, they're just grey screens of death with an apple logo and an even-less-informative error message (in half a dozen languages).
BSOD in projection system (Score:2, Informative)
Re:Oh, stop it! (Score:3, Informative)
BSOD's are no longer a problem! They haven't been since Windows XP! BSOD's were only a problem in the Win 9x days!
Strictly speaking BSODs were never a problem in Windows 9x because, originally, BSOD was an NT-specific term for the kernel dump screen.
The explosion of ignorance on the internets in the late '90s, however, means that even the Windows 95 errors that popped up a blue DOS screen are now referred to as BSODs (even though they frequently lacked the "OD" part).
DL3 media server failure (Score:5, Informative)
I believe most of the projections were handled by HighEnd Systems DL2s and DL3s. Essentially a projector on a moving yoke, with a few extra features. Each DL2 or DL3 has its own built-in media server running Win XP Embedded.
Even if the built-in media server fell over (which is what this looked like), there is still DMX control over the unit. Pan, tilt, focus and more importantly beam blanking and projector power are still controllable. It would have been easy to shut the faulty unit down and still carry on with the show (and yes, I do work with this kind of gear).
On this scale of event, they would have had multiple operators dedicated to watching over particular areas in case of such a fault. It looks like someone wasn't paying attention.
Re:Here's a game (Score:5, Informative)
Better pic here [livefilestore.com]. Perhaps Lenovo should have used Red Flag Linux [wikipedia.org] for this mission-critical application?
Re:In fairness to software engineering (Score:5, Informative)
Re:Oh, stop it! (Score:2, Informative)
Stop this revisionist nonsense. The phrase was first used in reference to Windows 3.1. Win XP's architectural changes eliminated entire classes of BSODs, but they were still legitimate BSODs. They could even be worse than kernel panics -- a "recoverable" error often lead to a system freeze minutes later.
Re:well (Score:3, Informative)
Yes, it "shouldn't" be able to. And celebrities and sports stars "should" be paid relative to their contributions to society. And you "should" treat all women equally, no matter how attractive or unattractive they are.
You're talking about an ideal, the ideal that drivers should never be able to take down an OS doesn't work here in reality. It doesn't work in Windows, it doesn't work in Linux, it doesn't work in OS X. So while it's a fine ideal, stop talking about it as if it has some relevance in real life.
(Now, when you manage to code-up an OS that implements this ideal 100%, then you can start being snide.)
When at the Olympics (Score:3, Informative)
you perform your very best.
lets face it, BSOD is the face of Windows.
you cannot have Windows at a major event without it participating, by doing what it does best. just like the athletes.
Re:In fairness to software engineering (Score:2, Informative)
Even microkernels such as Mach are prone to these problems.
Can, but comparatively how often?
Err , if the projector driver had failed... (Score:3, Informative)
... the BSOD wouldn't still be being projected onto the roof!
Re:Here's a game (Score:3, Informative)
0x000000F4: CRITICAL_OBJECT_TERMINATION
One of the many processes or threads crucial to system operation has unexpectedly exited or been terminated. As a result, the system can no longer function. Specific causes are many, and often best resolved by a careful history of the problem and the circumstances of the error message. One user, who experienced this on return from Standby mode on Win XP SP2, found the cause was that Windows was installed on a slave drive; compare KB 330100.
That's probably it.
Re:well (Score:3, Informative)
Ubutnu hangs whenever I try to force the mounting of a "dirty" ntfs volume (ie window didn't shut down correctly) with ntfs-3g through truecrypt.
That's technically a Microsoft thing. While Ubuntu should probably handle the error better and anticipate that sort of thing, NTFS is designed not to mount if chkdsk has not been run after a bad restart from the Windows side, and no substitute for chkdsk has been developed (that I know of). This could easily be avoided by removing all of the important data from your Windows partition and and deleting that partition :).
Re:In fairness to software engineering (Score:5, Informative)
and now, with Vista, display drivers are back to being in user-mode [microsoft.com]:
At a technical level, WDDM display drivers have two components, a kernel mode driver (KMD) that is very streamlined, and a user-mode driver that does most of the intense computations. With this model, most of the code is moved out of kernel mode. That is, the kernel mode piece is now solely responsible for lower-level functionality and the user mode piece takes on heavier functionality such as facilitating the translation from higher-level API constructs to direct GPU commands while maintaining application compatibility. This greatly reduces the chance of a fatal blue screen and most graphics driver-related problems result in at worst one application being affected.
Re:DL3 media server failure (Score:1, Informative)
The scale of the event from a tech point of view is huge:
Think they didnt use the DL2/3's because the brightness is only about 6.5k lumens if I remember correctly, vs. 20k from the projectors they used. Considering they are already using 150 projectors, along with the long throw/brightness issues and limitations on the lens for the DL2/3's, dont think they could have used them.
The Christie's dont have DMX control (they do have other forms like RS232 and proprietary solutions) so they should still have been able to take the feed offline however.
Re:well (Score:4, Informative)
IIRC, the default was actually changed to automatically reboot back with Windows 2000. (And, I want to say that NT4 Server also automatically rebooted.)
Re:well (Score:1, Informative)
It wasn't pirated. The following link (in Chinese) [mydrivers.com], which is traced from this other link [live.com] (which comes from the Gizmodo article [gizmodo.com]) says they were 120 HES Axon Media Servers running XPe (Windows XP Embedded).
Regardless, I can see some heads rolling as result from this failure.
Re:In fairness to software engineering (Score:3, Informative)
I'm sorry, do you know of an operating system where talking to hardware cannot cause a panic?
[...]
If you can name one system ready for general purpose for which this isn't true I would love to hear about it.
I haven't worked with QNX lately, but it has historically been a very tolerant OS in my experience. You are correct that at some point the OS MUST access hardware directly, and that faulty hardware will cause a software crash...but there are degrees of vulnerability here.
Microkernel OSes, especially those like QNX that are used in embedded and/or real-time applications, are extremely fault tolerant. Because hardware subsystems are each accessed by separate, self-contained low-level processes, a hardware fault in fact will NOT cause a systemic software failure as you assert. You DO in fact have to "try" to "bring down a whole system" through hardware faults in such architectures.
Nothing will stop systemic hardware faults from causing systemic software crashes, but the fact is that when it comes to Windows (and to a lesser but still significant degree, Linux and Mac OSX) hardware fault tolerance is absolutely wretched compared to what it COULD be. Microkernel architecture helps but isn't the magic bullet either--remember that MacOS X AND Windows are BOTH technically "microkernel architectures" and that doesn't keep them from falling over due to a hardware fault or bad driver.
There's a basic design flaw in how normal computers operate that requires this sort of behavior from kernels
Linux is very stable relative to Windows even though it is a monolithic kernel architecture because it is a better engineered platform overall, both in terms of security AND because drivers are much better written (owing to the fact that the bulk of drivers are community-written and/or open source instead of supported by an overworked small team of programmers employed by a hardware company that chronically under-invests in software development for its revenue-generating hardware products). In all but TWO cases (one case being a total hard drive failure where the system continued to run without HD access until a page swap was required, and another where several cheap Chinese capacitors dried out and popped in another system, which also would boot and run for hours to days nonetheless) my 11 years of extensively using Linux ALL kernel panics have been due to SOFTWARE bugs in drivers, and in most of those cases they were CLOSED drivers (I'm talking to you NVidia!).
Even with the problems I've had with closed drivers in Linux, the problems are very small in number and severity in comparison with Windows. NVidia drivers still are relatively unreliable however when there is a problem in Windows it can make the system BSOD. A similar bug in Linux is most likely to cause a fault in X but the rest of the subsystems are unharmed--in fact the latest NVidia drivers haven't caused me a single kernel panic yet. There is no "basic design flaw" in modern hardware systems that cannot be kept to a very small minimum without proper SOFTWARE design.
Re:In fairness to software engineering (Score:3, Informative)
I know I'll be modded down to -infinity on this, but seriously - my Mac G5 has kernel panicked more than my Windows XP box (keep in mind my G5 has done this maybe twice last year?)
Re:What's their motivation.... (Score:5, Informative)
This has actually been proposed a number of times (without the personal attacks), but rejected for two reasons:
The latter problem is more important. Problem is, kernel mode code can do *anything*, including write to other modules' memory space. So if a driver "baddisplay.sys" accidentally wrote to an uninitialized pointer that just happened to point to the memory space of "goodprinter.sys", but didn't fail as a result (remember, no real memory protection in kernel mode), and "goodprinter.sys" later reads the screwed up memory and fails, it will look like a problem in "goodprinter.sys", even though "goodprinter.sys" behaved correctly (dying when faced with an irrecoverable error).
This is why the "Problem Reports and Solutions" only provides information after conferring with MS. When it gives you an answer, it's because someone at MS took a look at your crash dump (or someone else's dump which exhibited the same problem), figured out the actual cause of the crash, and linked the crash and solution together. If it blamed the module automatically, you'd spend time harassing a perfectly innocent printer manufacturer, and MS would need to hire even more lawyers.
(Disclaimer: Former MS employee, this is only what I was told)
Re:Doesnt look like a BSOD... (Score:4, Informative)
More accurately, you pay Apple a great deal of money so you have exactly one person to blame if you get a crash. BSODs in Windows are (99% of the time anyway) a matter of bad third party drivers. Apple has an easier time of it because they only support a small range of hardware in predictable configurations; MS has to test enormous numbers of drivers for every conceivable x86/amd64/ia64 configuration. Linux splits the difference; in theory they support the greatest number of configurations, but in practice support for new hardware comes slowly, and with no guarantees.
Re:In fairness to software engineering (Score:1, Informative)
Re:In fairness to software engineering (Score:4, Informative)