Even though the target audience may be programmers, it can still be seen by users


The access violation error message erroneously reports execute errors as write errors, which is probably for the better, seeing as end users are not going to understand the technical term "execute", and they may misinterpret it as referring to capital punishment.

While it's true that the word "execute" is the correct term for the target audience, the fact remains that this message is shown to audiences beyond its target. You therefore have to be careful not to alarm them unnecessarily. (Insert stories about people who get all concerned about their computers performing illegal operations and wondering if they're going to be arrested.)

Bonus chatter: Adam Rosenfield wonders whether this message was ever localized, or whether it got "un-localized" by Windows Vista. I went back through the history. The words "read" and "written" were never localized as far as I can tell.

Comments (48)
  1. dave says:

    Well, I cast my non-existent vote to writing for the target audience., and the devil take the hindmost.

    (1) Misreporting an error condition is never “for the better” if you want the problem to be fixed in a timely manner.

    (2) I am unable to fathom a mind that will misinterpret an execution error as “referring to capital punishment”. Have they never executed a plan? I say that “execute” is not programmer jargon, it’s just a plain old English word.

    (3) If someone is so weird as to think that “execute” means killing someone, how can they understand “write”? After all, they were not typing out a letter to their auntie at the time, so no-one was writing anything,

    (4) I’ve exceeded my lifetime limit on tolerating the “translation” of technically accurate text into meaningless pablum on the grounds that people who can’t use the information anyway will not know what the words mean.

    1. Boris says:

      But regardless of what you write in terms of a technically correct description, the average user will see it as “Something is seriously wrong with your machine; please contact an expert who can read this”. Therefore, I think it’s better for an error message just to say a few comforting words, and also include more details in a separate file, which can be viewed on clicking a button, for example.

    2. IanBoyd says:

      In the age of TOR, encryption, and bot networks, you have to be weary of your computer performing an illegal operation.

      And you don’t want General Failure reading your hard drive.

      1. Joshua says:

        “illegal operation” was a poor choice of words. “invalid operation” would have been better but “invalid operation” … “invalid instruction” is poor, and it’s the most common kind since segmentation fault gets a completely different message.

        1. dave says:

          But surely an “invalid operation” will be misconstrued as a medical procedure performed on someone weakened by injury or disease?

          ;-)

      2. Mason Wheeler says:

        And you don’t want General Failure reading your hard drive.

        Not to mention his subordinate, Colonel Panic…

    3. Darran Rowe says:

      I was beaten to this by a reply to another comment, I was slow.
      But the reporting of an access violation error is a side effect of another error anyway. So if you like, the actual error in the program is already misreported.
      The thing to remember is that the user just sees this as either “ignore and it will go away” or “must report to someone who knows more” while the developer will just look at logs, crash dumps or hook a debugger for a post mortem debug session. In the end, because the AV is a symptom, it is ignored anyway. The error could just say “the program frobbed its widget” for all people care, as long as it is understood that it means “the program crashed” that is the important thing.
      Oh and for the case of NX kicking in and it being reported as a write to a developer, this is properly reported in the crash dump and debugger when you do a post mortem debug.
      As for not fathoming people’s mindsets. If you think about it, there exists people who believe the Earth is flat and there are people who believe that space missions are hoaxes. Lack of knowledge and understanding can have a very big impact on what people think. It is also easy to forget that people who are not you can think in very different ways, so your assumptions can not apply.

  2. Stefan Kanthak says:

    Remove the “execute” permission from an executable file (.EXE, .COM, .CMD, .BAT) and try to run this executable via double-click.
    The Windows Explorer shows the following (generic) “Access denied” error message which may confuse its target audience (I’m citing the german text):
    “Auf das angegebene Gerät, bzw. den Pfad oder die Datei kann nicht zugegriffen werden. Sie verfügen eventuell nicht über ausreichende Berechtigungen, um auf das Element zugreifen zu können.”

    MANY users who see this message will try to copy this file or open it in Notepad (especially if it’s a batch script) … and succeed.
    Now tell them why they can’t execute this file, but can copy it or open it in just any program of their choice…

    1. The MAZZTer says:

      If the user is going around clearing the Execute permissions flag on their files, I would hope they would be aware of the consequences.

      As you pointed out, this is why none of the security is configured this way by default. And in fact, to clear the Execute flag, you need to delve into the Advanced security settings. The normal security dialog has a removal of execute permission also remove read permission (though you can have execute without read).

      1. Stefan Kanthak says:

        If its not the user, but their administrator who adds an ACE “(D;CIIO;;WP;;WD)” to “%USERPROFILE%” (or at least “%TEMP%”, “%APPDATA%” and the “Downloads” folder), then this (technically correct, but for users not really comprehensible) error message changes magically?

        JFTR: take a look at real^Wother operating systems, where newly created files are not created with execute permissions.
        Unfortunately Microsoft made a BIG mistake and bloody beginner’s error about 25 years ago when they decided to create files with execute permission… and allow arbitrary malware to run everywhere!

        1. 25 years ago? Try 40 years ago. Windows file system semantics are compatible with MS-DOS file system semantics, which are compatible with CP/M file system semantics.

          1. Joshua says:

            His count is pretty good. NTFS was the first Win32. There’s no reason in particular why executing files w/o execute bit could not have been banished to Win16 layer only.

          2. > There’s no reason in particular why executing files w/o execute bit could not have been banished to Win16 layer only.

            Um, Windows 95 ran 32-bit apps, and in the early days of NT, most people still used FAT, not NTFS. Basically, every installer would have broken on NTFS, which is a pretty bad compat story for NTFS.

          3. Joshua says:

            I was assuming you would track which files were executable even on FAT (which is not as hard as it sounds). The idea is to make the developers run smack into it when they build their first installer so by the time the installer ships it already knows.

            Sadly, there was little way of predicting the .exe with image icon trick followed by the .jpg.exe trick that resulted in way too many viruses spreading by email. I was there. I saw it happen. I couldn’t understand because I had turned on show extensions really early on because what the *bleep* is this file type came up so often in our switchover to Win95 that imaging why anybody wouldn’t want to change it was hard. I had yet to encounter the ignorant user though.

          4. Stefan Kanthak says:

            Neither MS-DOS nor CP/M had an NTFS filesystem nor ran Win32 applications.
            Both NTFS and Win32 were introduced about 25 years ago, and there was ABSOLUTELY no need to carry all the cruft from MS-DOS or CP/M over to the new API.
            Only the NTVDM plus the WoW subsystem which run the old 16-bit applications should have made compatible to MS-DOS and Windows 3.x!
            Existing (16-bit) installers would NOT have broken on NTFS then.

          5. > there was ABSOLUTELY no need to carry all the cruft from MS-DOS or CP/M over to the new API.

            But there was ABSOLUTE need to carry all the cruft from 16-bit Windows to the new API. Every breaking change was a reason for somebody to not port their program to Win32. And Win32 managed to ship with only 117 breaking changes.. Saying “Oh, and the file system rules are now completely different” would be a very big breaking change. https://blogs.msdn.microsoft.com/oldnewthing/20120913-00/?p=6613

          6. Stefan Kanthak says:

            You mean breaking changes like unprivileged running programs were not allowed to write their settings to %windir%\{system,win,control,…}.ini any more?
            The limitation to 8.3 filenames for 16-bit programs?
            The need to quote long filenames/pathnames containing spaces?

          7. > breaking changes like unprivileged programs not being able to write settings to %windir%\{system,win,control,…}.ini any more?
            > The limitation to 8.3 filenames for 16-bit programs?
            > The need to quote long filenames/pathnames containing spaces?

            None of those were breaking. INI mapping solved problem 1. Problems 2 and 3 were solved by short file names.

          8. Stefan Kanthak says:

            This depends on your understanding of compatibility!
            Programs using (for example) some %windir%\*.ini broke UNLESS an administrator created the INI file mapping, programs that expect 8.3 filenames break when NTFSDisable8dot3NameCreation is disabled, …

          9. jgh says:

            > The need to quote long filenames/pathnames containing spaces?

            ok, you tell me how to parse REN MAY ACCOUNTS FINAL BACKUP ACCOUNTS FOR MAY

          10. smf says:

            @Joshua

            >There’s no reason in particular why executing files w/o execute bit could not have been banished to Win16 layer only

            You want to stop malware by forcing them to write it in Win16?

            >I was assuming you would track which files were executable even on FAT (which is not as hard as it sounds).

            Tell us, don’t keep it to yourself.

          11. Stefan Kanthak says:

            > You want to stop malware by forcing them to write it in Win16?

            1. Windows for x64 has no NTVDM or WoW[16], so malware written for ancient and obsolete environments doesn’t run there.
            2. On other architectures where NTVDM or WoW[16] exist these can be disabled (that’s what every self-respecting administrator does, since many years): see MSKB 979682, 2436673 and 2859537

          12. Joshua says:

            I didn’t think I was going to reply to this thread again but smf pushed me to it.

            The other half of the malware solution is easy. Because Win16 EXEs could not directly set their icon, they wouldn’t allowed to do it in the Win32 shell. The .doc file with the generic program icon ought to have been enough to scare people off. I pondered whether making shellexecute not work for Win16 EXEs would have helped but it really doesn’t. It’s the icon change that does it.

            As for where to store the execute bit in FAT, it’s a problem that’s been solved twice. You could piggyback on LFN or you could use the solution used by the Linux umsdos filessytem of storing attributes in another file in the directory. A 16 bit program operating on a Win32 EXE is likely to revoke execute, but that really doesn’t matter because there can’t be a Win16 program designed to operate on Win32 that predates Win32. Bonus: If you take the umsdos solution and don’t hide the file from the 16bit layer, 16 bit backup software continues to work.

    2. Alex Cohn says:

      Now remove the executable permission from delete_all.sh and explain to the target audience what happens to their document when they run `source ./delete_all.sh`

      1. Stefan Kanthak says:

        You missed some alternatives!
        For *x: sh -c ./delete_all.sh or better $SH -c ./delete_all.sh
        For Windows: %COMSPEC% /C Call

        JFTR: FType batfile=%COMSPEC% /C Call ^”%%L^” %%* and FType cmdfile=%COMSPEC% /C Call ^”%%L^” %%* fixed a vulnerability present in Windows for some 20 years.

      2. Stefan Kanthak says:

        You missed some alternatives!
        For *x: sh -c ./delete_all.sh or better $SH -c ./delete_all.sh
        For Windows: %COMSPEC% /C Call

        JFTR: FType batfile=%COMSPEC% /C Call ^”%%L^” %%* and FType cmdfile=%COMSPEC% /C Call ^”%%L^” %%* fixed a vulnerability present in Windows for some 20 years.

  3. Thanks for the bonus chatter, Raymond.

    One could also make the argument that telling the user the address XX of the faulting instruction and the location YY of the invalid memory is worse-than-useless technobabble. They’re marginally useful for developers, but they’ll only confuse end users. But without a full stack trace, minidump, or full memory dump, they very often will not be actionable for developers.

  4. smf says:

    Alternatives for “executed”

    The memory could not be fetched.
    The memory could not be used.
    The memory could not be known.
    The memory could not be fulfilled.
    The memory could not be.

    Saying the cpu was trying to write the memory is just plain weird.

    1. The MAZZTer says:

      Those messages are even worse. The ACTUAL error is that the program is trying to run from a memory address that is not marked as containing code, but data… this indicates some sort of buffer overflow error or similar probably caused the code execution to jump to the invalid location.

      Your average user is not going to care about any of that. The most important thing we can tell them is that their program stopped due to a bug that is most likely in the program, That’s about it. Any further details than that are only going to be useful to developers.

      1. Joshua says:

        “The program is running data instead of code.” should cut it though.

        1. Darran Rowe says:

          Then have end users ask where their computer is going?
          The message that pops up isn’t even useful or important for a developer anyway. There are two important things to remember here. First, the access violation is always going to be the result of another error, so it doesn’t really give you more than a symptom of the actual problem.
          Secondly, as a developer, you don’t rely on that message to figure out where the problem is at all. You will always have some more accurate method of figuring out what the real cause of the problem is in place, like logging. Also, you are always going to look at the crash dump, or attach a debugger to look at the state of the program after it has failed to get more information. This is important because you get information from this that you can’t get normally about the state of the program. This means you will get the true access violation exception, along with other useful stuff.

          1. Muzer says:

            “This program has stopped working. This is usually caused by a problem in the program or in a {plugin/add-on/extension/whatever will be most widely understood}.

            Technical details: Address: 0xwhatever, Instruction: 0xwhatever, type: {read, write, execute}”

          2. Darran Rowe says:

            @Muzer:
            What Windows does by default these days is actually the best IMO.
            http://imgur.com/80oaVoA

          3. Azarien says:

            “The message that pops up isn’t even useful or important for a developer anyway. ” – well, when I was fixing an old application to run on modern systems I immediately knew what was going on thanks to this message. Adding PAGE_EXECUTE in one call to VirtualAlloc fixed the problem.

          4. Darran Rowe says:

            @Azarien:
            That says that you knew what the problem with the program was in the first place. (Or at least knew where the real problems were).
            But again, that wasn’t the point. First, you didn’t need to get the information from that dialog did you? If you attached a post mortem debugger or got it to save a crash dump then you would have still gotten the information. Visual Studio would have given you a nice message “Unhandled exception at 0x09ABCDEF in ctest.exe: 0xC0000005: Access violation executing location 0x09ABCDEF.” Windbg gives more verbose information. So you have moved from an isolated message to a full process context.
            Secondly, if you are worried about that message going away meaning you have less bragging rights “I understand that message, I’m awesome”, remember this has now moved to giving people arcane instructions to allow you to do witchcraft. This means you now look even more awesome.

          5. GregM says:

            “First, you didn’t need to get the information from that dialog did you? If you attached a post mortem debugger or got it to save a crash dump then you would have still gotten the information. ”

            I take it you’ve never had a user send you a photo of the error message on their screen as the only information about an error message.

          6. Darran Rowe says:

            @GregM:
            Interesting conclusion. Seeing a careful approach, wanting to get as much information about a problem and not relying on an ambiguous message as “never being sent a screenshot of an error”.

          7. GregM says:

            “Interesting conclusion. Seeing a careful approach, wanting to get as much information about a problem and not relying on an ambiguous message as “never being sent a screenshot of an error”.”

            Nope, it was from the comments that implied there was no reason to put any of this information in the dialog box because there exist methods that provide better information. It suggested that the commenter had never experienced a situation where that better information is not available, and thus the only information available was from the dialog box. In that situation, if the dialog box did not provide any information, then the only option would be to tell that user “I’m sorry, there’s nothing I can do for you. The next time this happens, you need to collect a crash dump.” At least with that basic information, you may be able to tell the user that you have a pretty good idea what the problem is and the troubleshooting steps to try. (Yes, this is based on real-life experiences.)

          8. Darran Rowe says:

            @GregM:
            Ah, your right. Even though I know that everyone is different, I then went and assumed that everyone is the same.
            I guess it is easy enough to assume certain things if that is what you are used to. At these times it reminds me how lucky I am being able to influence some things for the better.
            As a hint though, a process can create its own crash dump thanks to the debug help library. Also is it really bad to go back to the customer and ask for basic information, like what they were doing when it happened? Especially if the error could occur in several ways, or if it is an access violation which can happen in infinitely many unknown ways? Isn’t it also true that if you report a bug, one thing that you normally do is try to figure out repro steps, because after all, reproducing the bug is one of the best ways to get it fixed?
            This is one of those cases, like unit tests, where if you really can persuade people that its for the better then it makes a huge difference. Even if it means annoying people a bit to get better information.

      2. smf says:

        The user doesn’t care what it says, it just needs to have enough information that a developer can understand it. You could replace read/write/execute with the name of fruit and it would achieve it’s purpose.

        Sometimes all you have is the error and no way of reproducing it, logging isn’t always enough.

        1. Ivan K says:

          You’d want to be careful about which fruit you choose… wouldn’t want old Granny Smith telling everyone that her Windows got broken by a few bad apples.

  5. AndyCadley says:

    I learnt this lesson a long time ago, in the Windows 3 days, when my mum would frequently ask “Why does my computer keep telling me it’s made an illegal move? I’m not even playing chess.”

    My programs tend to die with a “Sorry. Something went wrong and its probably my fault.” message and then log real error details elsewhere. There’s no point showing techno-babble to users, they won’t even pass it on correctly even if they do read it and at worst they’ll panic about it.

  6. Drak says:

    Well, at least it says more than ‘Guru meditation’ :D

  7. Robert says:

    Some users of our software were concerned about the standard error message “Catastrophic failure” (caused by an unhandled exception in a DCOM server, so the call returned E_UNEXPECTED or something like that).

  8. Scott H. says:

    I was doing internet tech support in the ’99-’02 era, when Windows 95 and 98 were still widely used. I spent many calls comforting scared users who got the Illegal Operation crash box, and was very glad when it was changed. It’s mostly used as a joke now but it was real life for me for awhile!

  9. DWalker says:

    As has been alluded to, I think that turning off file extensions “by default” was a horrible, horrible, awful design decision. The choice should not even be there!

    1. DWalker says:

      … and I could not reply in the proper sub-thread, because it apparently was already too deep…

      1. Stefan Kanthak says:

        > and I could not reply in the proper sub-thread, because

        you are obviously not able to recognize the scheme of the URL used for “Reply”…

Comments are closed.

Skip to main content