Hacker News Reader

Comment by ryacko | Hacker News Reader

The L3 cache is large enough to run an 80s operating system, there is no reason why BSODs to be so minimalistic, information about the possible why it failed could be done.

Lists of recently switched processes, or the general category of errors it falls in.

View on HN

There's a school of thought that would say that by default, error messages shouldn't be a huge scary wall of text, because you have to consider that a majority of the people who would see an error message are not developers, and have no idea what to do with that information.

It should certainly be possible for someone who can diagnose an error to see the details, but making it the default can be problematic when the message has a chance of being shown to real end users.

That sounds like airbags in a car. On the majority of trips you don't need them, but their presence is of little consequence. When you do need them, you're out of luck if they're not there.

> There's a school of thought that would say that by default, error messages shouldn't be a huge scary wall of text, because you have to consider that a majority of the people who would see an error message are not developers, and have no idea what to do with that information.

I think normal users have a pretty good idea what to do with it -- show it to the nearest tech person or paste it into Google.

Just giving it to them up front makes things easier, not harder. They need help so they take a screenshot. If it contains the relevant information, someone can help them. If it just says "an error occurred" then nobody can help with that because it contains no information. Now they have to go back and have the tech walk them through trying to extract the information from some log file, which is seventeen clicks through an interface they've never used and now there are 5000 entries and they don't remember exactly what time it happened etc.

It also deprives the user of any opportunity to learn. The user has a problem, they get a message, they ask the tech what to do and the tech tells them. Now the next time they get the same message they know what to do. But if the message is always the same regardless of the cause then they lose the ability to match known problems with known solutions and give up.

Not all users care to learn that sort of thing, but you take it when you can get it, not purposely inhibit the user from doing it.

Thank you for that perspective - I've never thought of it that way before. Would it be worth appending "if you don't know what this means, ask your local nerd"?

Sure. You don't have to take over the whole screen with a gdb console they don't know how to use. Make the message as friendly as possible, but it still ought to actually contain the information necessary to identify what happened.

I suspect the modern trend of making problems opaque comes from companies that do it on purpose. If the user can solve their own problems, what do they need with your expensive support contract? Why have the user fix problems with their existing device when you can sell them a whole new one the first time anything happens?

And then other developers who don't even use those business models still cargo cult the same UX.

Not to mention that Intel chips are already running Minix ...

x86 used to support coprocessors and has the lock instruction for it. They should have added the security module as a PCI card.

First of all, how would you localize it? English-only errors would not be acceptable today like they were in the 80s. Secondly, what if accessing/storing that diagnostic data is what caused the crash?

Yeah, given the choice between a translated message that is utterly useless and an English-only informative error dump, I'm gonna bet everyone remotely capable of dealing with the error would choose the latter every single time.

> everyone remotely capable of dealing with the error

Already this excludes most people who will see the error. Meanwhile, experts already have more sophisticated tools available to them like the event viewer. Obviously that wouldn't be useful in a situation like this where boot-up is blocked, but like I mentioned previously, there's only so much diagnostics you can reliably provide on a system that is in the middle of crashing.

The people who see the error will be the ones who screen shot it and send it to people can deal with the error.

So both sides have to be able to see the details.

Well, you can't screenshot a BSOD, so I assume you mean they would take a photo of it (which would be awkward as hell just getting a high enough res copy from them that I could read it) or more likely they would just tell me the error message verbally and leave out all the advanced details. So I'm not sure this is really that good of a justification to make the BSOD screen more detailed.

A BSoD screen could display a QR code that encodes a URL at microsoft.com that unpacks all the data after the '?' in the URL, and provides an option to change culture and locale, including links to support pages known to be associated with that error, and a button to Bing-search for more information on the error. They could then copy-paste the URL for that page using their phone into a text or email to their favorite technical adept.

They actually do exactly that already! You can see the QR code right in OP's pic.

I meant that the QR code should be larger, to encode the additional information shown after the registry patch as additional URL parameters. On re-reading, I did not make that clear.

Nobody is decoding QR codes by hand, so it isn't that big a deal to go from "https :// www.windows.com / stopcode ? code=ACPI_BIOS_ERROR" to "https :// www.windows.com / stopcode ? code=ACPI_BIOS_ERROR & p1=0000000000000002 & p2=FFFF9A0..."

Ah, you're right. I didn't realize the bugcheck parameters weren't included in the code, that's definitely something which would be helpful. However then you still might run into the second problem of not being able to reliably render it in a crashing state. That's the only reason I could think why they would not include those parameters in the QR.

Not acceptable? English is the lingua de franca of technology.

I rather have a detailed error report in one language and then have to find someone who speaks it to translate it (if Google doesn't do a good enough job), than fifteen poorly written versions. Not to mention, those error screens should be as minimal as possible in terms of features so less goes wrong.

I don't want animations, fancy colors, dealing with the horror show that is localization, or anything of the sort. Because the system when it hits a bsod is in an undefined state, so it's best to exercise as little as possible of the system, just enough to get the error message out.

Exactly what I'm saying! If all it does is show a bitmap, that's the simplest possible way of getting the error message out. The more detailed you want to make the BSOD screen, the more chance of something going wrong while rendering it. Localization is just one problem with making it detailed, but there are plenty of others too even if you settle for English-only errors.

If the info is for the vendor who deals almost exclusively with English then localization is pointless.

If it is for the user then being able to google the exact error is going to return more results than 47 translations.

Most users will in fact do nothing but report said error to their vendor whom will refer to their English language documentation.

In other news most programming languages aren't localized for example.

> If it is for the user then being able to google the exact error

And they already provide just enough information to be able to google the error. I am just opposed to adding more detailed information, the kind of information that's only relevant for experts and is not guaranteed to be available in the middle of a crash.

> In other news most programming languages aren't localized for example.

Programming languages aren't consumer products like operating systems are

Error messages aren't really consumer products either.

Reply on news.ycombinator.com