You may rightfully say that crashing is always bad, and having a server-class app background, I agree. Crashing means you made a mistake, bad programmer, no biscuit. However, crashing may be the lesser of the evils in many places. In the event that our apps crash, we have recovery mechanisms, ways to report the crash so we know what function had the problem, and so on. I really take issue with those who would characterize a client-side crash as a denial of service. If you can crash my app so that I can't restart it, or have to reboot my system, well, OK — that's a DoS. If you blew up my app, and I just don't load that document again, big deal. On the server side, all crashes are bad — though it is still better to drop the service than to give the attacker a command prompt.

So can we expect to see that approach in other products that use Windows Embedded? Like maybe...a TV that, when the cable service goes pixellated, shorts out all the circuitry in your house? ("Users can reset circuit breakers to resume normal operations.") A car CD player that, when it's fed a scratched disc, disconnects the steering and brakes and disengages the clutch? ("Users who survive can restart the car to resume normal operations.")

If your application code is in control, it can gracefully reject bad input. If your app code ISN'T in control, you crash. You're already owned. This suicide-before-capture approach isn't "by-design" behavior. It's lack-of-design behavior.