Why does the access violation error message put the operation in quotation marks, redux


Following up on Why does the access violation error message put the operation in quotation marks? Is it some sort of euphemism?

Recall that when an application crashes with an access violation, the error message says something like

The instruction at "XX" referenced memory at "YY". The memory could not be "read".

The word at the end is "read" or "written", and we saw earlier that it is in quotation marks for localization reasons.

Okay, now some follow-up discussion:

The code that decides whether to use "read" or "written" was not updated to support the new access violation code added by Data Execution Prevention (DEP), also known as NX (no execute).

Code Meaning
0 unable to read
1 unable to write
8 unable to execute NEW

The code assumes that any nonzero value means "unable to write". Therefore, if you encounter a DEP violation, the error will say that "The memory could not be written" instead of "The memory could not be executed."

Which is maybe a good thing, because it sounds scary when you say that memory couldn't be executed. Like the firing squad didn't show up or something.

In Windows Vista, all the quotation remarks were removed, so now the message just reads

The instruction at XX referenced memory at YY. The memory could not be read.

At least now it doesn't look like a euphemism.

However, the words "read" and "written" are not localized. They are hard-coded in English. This means that in German, you would get

Die Anweisung in XX verweist auf Speicher YY. Der Vorgang read konnte nicht im Speicher durchgeführt werden.

with an English word (highlighted) inserted into the middle of a German sentence.

Localizability FAIL.

Comments (39)
  1. Joshua says:

    Shrug. For the strangest reasons, not localizing a degenerate error message like this one works better. The real audience isn't the user anymore.

    Too bad 8 didn't become "run".

  2. Ben Voigt says:

    @Joshua: Well, "run" might be more meaningful to the end user, but as you just pointed out, they aren't the audience for the error message.

    "execute" definitely is much more accurate and meaningful to programmers.

  3. Smithers says:

    @Joshua: Why shouldn't it be localised just because it's aimed at programmers? Programmers can be German too, you know.

    Then again, I suppose German programmers are already used to writing language keywords and functions in English. Unless, of course, they habitually write Sorted! (p-nand-q.com/…/index.html).

  4. Adam Rosenfield says:

    Was this message ever localized, before Vista added the "executed" status?  Or was the FAIL that Vista *removed* the localization?

  5. PastorGL says:

    I always wondered why it looks so badly translated in Russian. «Память не может быть read.»

    Epic.

  6. Voo says:

    @Smithers Because the lingua franca of programming is English these days. Any programmer worth their salt can at least read English decently (although being able to write good documentation is pretty much a requirement too).

    And I say that as someone whose first language isn't English.

  7. Joshua says:

    @Smithers: The problem is the user's language is far more likely to be unintelligible to the programmer than English. Thankfully the limited technical vocabulary of programming concepts is nearly universal for programmers.

  8. Azarien says:

    The first thing wrong was assuming that you can replace just one word from "read" to "written" in every language. Don't do that assumption when localizing software. Many languages have complex inflections that make this sort of one-word change impossible. Make it two separate, localizable messages.

  9. Hans-Werner says:

    As a German, I prefer to get error messages in English – simply because it is far more likely that I'll find something useful if I bing the English phrase rather than the German one.

  10. alegr1 says:

    @Hans-Werner:

    Try to google the messages instead.

  11. Lev says:

    I always assumed that it was for laypeople, who think that "read" without quotes means "read actual letters visually".

  12. Chris Warrick says:

    @Adam Rosenfield:

    1. DEP added status 8.  DEP was added in XP SP2 (or so says Wikipedia).

    2. The error handler works on zero/nonzero, thus "executed" is never shown (not even coded in).

    3. But none of this matters for the l10n part of this post. The message was never localized in the first place. It used "quotes" to mark the English string, which dumbly inserted using something like sprintf.  This message is useless to non-programmers anyway, so it was good enough.

    4. Vista removed the "quotes", and the message now looks weird in non-English locales.

    The correct implementation would use two or three distinct localizable strings, which means there would be no English words in the message in non-English locales.

  13. gdalsnes says:

    Was it not possible to just remove the "quotes" in the English language(s) and keep the "quotes" in all other languages? Maybe this was the intention, but the translators messed up?

  14. JM says:

    The only thing most localized error messages are good for is a laugh. Once I'm done sniggering at the weak grammar and interesting neologisms the translator came up with, I translate the message back to English (usually a simple word-for-word translation will do) so I at least know what's going wrong.

    I firmly believe that error messages of operating system kernels, frameworks, libraries and the like should not be localized. These errors are not supposed to be shown as-is to the end user, but if your application developer is lazy and does so anyway (rather than saying "this particular action failed, the following is the technobabble"), at least you'll have more luck looking up the English message. Including some sort of systematic code (be it an HRESULT or something else) that is language invariant is also helpful.

  15. Alex Cohn says:

    This message was born in sin, and the failures to get it localized only expose the root problem. The error messages should be legible to non-technical users, people who don't know English alphabet, and may even have problems with the arabic digits (i.e. 1,2,3). The operating system should also provide a reasonable channel for the end user to send information about crash to the developer. There is little reason to have this system information localized: should it be localized to the preferences of the end user? OS? Developer?

  16. Anonymous Coward says:

    @Alex Cohn:

    Your choices are this, or "The program crashed. Sorry :("

  17. Alex Cohn says:

    @Anonymous Coward:

    Don't you agree that the latter is less intimidating?

  18. boogaloo says:

    @Alex Cohn: You can take out all the hard questions in exams to make those less intimidating too.

  19. Danny says:

    @Ray

    "…with an English word (highlighted) inserted into the middle of a German sentence."

    And for rest of us who hate bing, here it is:

    lmgtfy.com

  20. Alex Cohn says:

    On PC DOS circa '93, IBM decided to go more global and made sure that all system messages were localized. One of the best was the "Non-system disk" error that is embedded in the boot sector. In such case, the black screen showed one word: A000085 (maybe the number was different, please forgive my short memory).

    The idea was that the end user would pull the "PC DOS Command Reference and Error Messages", part no. 83G9309, brochure from their bookshelf (unfortunately this book does not seem to be available online today), and find the description in your favorite language (the language of *your* manual, not the language of the system used to format (without /s) the diskette.

  21. Alex Cohn says:

    @boogaloo: the end users do not deserve this. They run an application, and it crashes. I have no objections to intimidating the developer in such case, but not the end user.

  22. The Bart, The says:

    Is there a way to tell an automatic translator not to auto-translate a particular section of text? In English->German using the Microsoft translator thingo on the side you get "Sterben Sie Anweisung XX Verweist Auf Speicher YY. Der Vorgang Lesen Konnte Nicht Im Speicher Durchgeführt Werden.", with the box around "Lesen".

  23. Jonathan says:

    @Alex Cohn: The user, intimidated as he might get, may forward the error to a developer or a more technical user. This happened to me, when my mother read an error message to me over the phone, and I managed to search for the error code (0x80030001) and find a good answer: superuser.com/…/117691

  24. 640k says:

    Windows in standard mode had this 25 years ago.

  25. Yuhong Bao says:

    @Alex Cohn: I think OS/2 did this too.

  26. Alex Cohn says:

    @Jonathan: I am really impressed. But keep in mind that at least for your mother there was no language barrier.

  27. Jonathan says:

    @Alex Cohn: Yes there was! Me & my mother are native Hebrew speakers. She does read English well enough to read messages of the English Windows (maybe I'll set it up in Hebrew next time), and that was enough for me to find the solution.

  28. DebugErr says:

    This is one of the reasons I dislike translated applications. Error messages sound bad, mixed with English, and cannot be googled well (or at least, with less results).

    You've probably heard of the German translation bug in Windows XP. If someone stopped the Help & Support service and you tried to start this feature, the English error message correctly said "Help & Support could not be started. Start the Help & Support service to fix this problem". In German, they accidentally forgot the "service" word in there, so it just read "Hilfe & Support konnte nicht gestartet werden. Starten Sie Hilfe & Support, um das Problem zu beheben." (which translates as "Help & Support could not be started. Start Help & Support to fix this problem."). Die deutsche Übersetzung bewerte ich mit "fail".

  29. Anon says:

    @Alex Cohn

    There's nothing worse than an error message that doesn't provide *any* information on how you *might* be able to solve the problem. There are thousands of forums around for technical support, not to mention social media. Plenty of us can help users resolve issues, if you give us detailed error messaging and logging.

    A generic error message for every problem means your users are going to start assuming that Random Thing X fixes all problems with your software, which causes *more* problems when it turns out Random Thing X breaks things in the background.

    To wit, assuming all your users are idiots results in only having users who are idiots.

  30. Dave Bacher says:

    On OS/2 Warp 3 and later (the versions IBM worked without Microsoft), each error message had a three character subsystem code followed by a four digit number.  You could type the error code with the help command at a DOS or OS/2 command prompt, and it would break that down — PC-DOS 7 did this as well, as indicated above.

    When the same error was displayed in the UI, it was roughly:

    [Code]: [Title]

    Description: [one to two paragraphs, similar to MSDN KB article]

    Cause: [one to two paragraphs, similar to MSDN KB article]

    Remedy: [one to two paragraphs, similar to MSDN KB article]

    Starting with OS/2 Warp 4, users had "levels" assigned via user manager or at the first log in.  When you logged in, it asked you to pick a level from 3.  The level of details in the message was keyed off this — and so it automatically scaled back the help for people who would complain about it, and automatically stepped up the help for people who needed it.

    Apps were encouraged to start from the OS default level, but to have their own, separate level.  Apps were also encouraged to use this same pattern for their error/message codes.  The idea behind this was that it was something easy to index and search on, so it would improve support.

    If you play Civilization V or Beyond Earth, it's like the advisor functionality there.

  31. bzakharin says:

    I agree that it would be better to just leave the whole error (or at least the sentence in which the non-English word occurs) in English if it is partially untranslatable. Either that or show a non-human-readable error code. Either would be less jarring to both the user and the person who has to interpret the error.

  32. Joshua says:

    And the main problem to implementing Dave Bacher's ideas is the nonsense in SQL Error message. From all the years starting with the earliest wrappers until the present day, SQL errors are not presented to the programmer in a way the programmer has a ghost of a chance of writing code to distinguish between a SQL programmer error and a system error, let alone what the system error might be.

  33. Alex Cohn says:

    @Jonathan, even if we neglect the language barrier, your mother and you did a miracle, and deserve highest respect.

    @Anon, I have never suggested to turn all error messages into "Your app had a problem, you idiot". Even in the case when the user has no obvious ways to resolve the problem (e.g. "not enough space on disk D: to store 'homework.doc'"), a button or hyperlink to a more detailed explanation should be available. The technical data like hexadecimal error code, crash address, etc. belong there, not on the first screen (and I am not speaking about the BSOD where there is no second chance to display such data). And better make it easy to send this technical data, without struggling to read it out loud on phone, straight to Jonathan.

    The first screen requires careful localization, including whatever cultural codes that could help the user not feel guilty for the error (and I see it quite often when my mother interprets innocent error messages as her personal fault). The second screen, IMHO, should be deliberately not translated, to enhance discoverability in search engines. If the error message has some "variable" part irrelevant for search, e.g. process ID, then the format of the message should help the not-very-professional user to drop this part when copy/pasting the message for internet search.

  34. Chris Crowther @ Work says:

    Localized error messages are the bane of my existence.  It's very nice that you localized an error message that will mean nothing to our customers.  Unfortunately you also localized it in to Korean, so it means nothing to me either.

    On the plus side we do have a pet junior developer who speaks Russian now, so at least we can read those ones.

  35. ender says:

    To everybody complaining about translated (error) messages: there are tools like Unlocalize that translate them back to English, and even Microsoft has an online database somewhere which lets you do the same.

    IMHO, if there's an error that's not something the user can remedy, it should still be localized, just include a unique (but as short as possible) error code somewhere, which would make the error easy to search for (assuming you can get the user to actually read it, which is another problem).

  36. Max says:

    Application crashes are already intimidating, by default. If you're going to show an error message it'd better be a useful one; simply informing the user that their application has crashed just adds insult to the injury of losing all their work.

  37. Tim says:

    Maybe they're scare quotes. Imagine what the CPU was /actually/ trying to do to that memory.

    "If you're going to show an error message it'd better be a useful one; simply informing the user that their application has crashed just adds insult to the injury of losing all their work."

    I'm not in love with this ethos, but it's becoming more common. There's a popular OS now that just kills applications and returns you to the shell when they crash with no message at all. Presumably this is the friendliest possible option to most users but when things go wrong, experienced users aren't getting any useful information that might help them figure out how to fix it.

  38. Anon says:

    @Alex Cohn

    The feelings of the user are largely irrelevant. Maybe they DID cause the problem, and you need to tell them to never do what they did, such as ripping a jumpdrive out in the middle of a write.

    What's important is that you provide all the relevant details. The only reason users panic when they see technical details is because no one ever shows them technical details. But that's not the user's fault, that's the developer's fault.

    You see the same thing when people from areas with full-service-required gas stations go to other states. They can't figure out how the gas pump works, despite having clear instructions on the pump. The solution is *NOT* to require that the station provide full-service to anyone who can't figure out the pump.

  39. Alex Cohn says:

    @Anon, the solution to full-service adicts seems to be simply to provide full-service for them at premium price; you would be surprised how many will immediately understand the written instructions if the penalty is $1/gallon.

    Regarding the relevant details, yes we should tell the user "you should not have ripped the jumpdrive in the middle of write", but we should show this message timely, use language that the user is expected to understand (e.g. not "H/W device S/N 213423 was detached during x353345 operation at I/P 0xZZZZZ").

Comments are closed.

Skip to main content