Why is the Microsoft Protection Service called "msmpsvc"?


(This is the first in a series of short posts on where Microsoft products got their names.)

The original name for the malware protection service was "mpsvc" the "Microsoft Protection Service", but it was discovered later that that filename was already used by malware! As a result, the name of the service had to be changed by sticking an "ms" in front, making it "msmpsvc.exe".

Therefore, technically, its name is the "Microsoft Microsoft Protection Service". (This is, of course, not to be confused with "mpssvc.exe", which is, I guess, the "Microsoft Protection Service Service".)

Fortunately, the Marketing folks can attempt to recover by deciding that "msmpsvc" stands for "Microsoft Malware Protection Service". But you and I will know what it really stands for.

Comments (40)
  1. Lauren Smith says:

    Microsoft Protection Services?  Is that where you pay them insurance money so that you don’t have an unfortunate accident?

    Any idea why they left the extra ‘m’ in there?

  2. Anonymous says:

    This might be a stupid suggestion, Raymond, but… Wouldn’t "Microsoft Protection Service.exe" be a much, much better name?

  3. Peter Ritchie says:

    Love this series.  Thanks

  4. Anonymous says:

    > Wouldn’t “Microsoft Protection Service.exe”
    > be a much, much better name?

    Personally, I hate file names with spaces in them, but generally having more descriptive long  filenames would seem like a good idea. What is the fetish with 8.3 naming in 2006 all about? Aren’t we past that now?

    For .NET binaries, the standard is to use a whole unique <Company>.<Component> namespace to name the thing: Microsoft.VisualBasic.Vsa.dll, Fabrikam.Security.dll. At least for shared assemblies. This is from the Framework Design Guidelines chapter 3 Naming Guidelines Setion 3.

    I guess sqlwb.exe (SQL Server Managment Studio nee SQL Work Bench from SQL Server 2005 client tools) is an example of a .NET binary that uses 8.3 naming.

    [Response. -Raymond]
  5. Anonymous says:

    Sort of like how in the Alpha Longhorn days, we had the "Rover Service, not to be confused with the "RoverService" which also was in the builds but was something else entirely.

  6. Mike Dunn says:

    Restricting filenames to 8.3 means the CD can be plain-jane ISO9660, not Joliet, which simplifies building the CD and the installer.

  7. Anonymous says:

    I agree about filenames spaces. I’m ridiculously happy that Vista has changed "C:Documents and SettingsPaulMy Documents" to the much more sensible and type-able C:UsersPaulDocuments. I don’t know why they didn’t change "C:Program Files" to C:bin, but I’ll probably just do that myself.

    When it comes to service filenames, though, I’m actually happy with a concise mnemonic. I spend a lot of time poking around in the task list, and I can skip over most of the common ones. Anything that’s the least bit off quickly catches my eye.

    PMP

  8. Anonymous says:

    I agree that long filenames aren’t useful as a security feature, but neither are metadata and signed files.  Joe User isn’t going to check any of that stuff, he’s just going to click on it.  

  9. Anonymous says:

    Why do people hate spaces in file names? Unquoted values are just exploits waiting to happen, if you assume file names (and paths) will not have spaces in them and don’t quote it’s easy to give your code a value with a space to make it do things it isn’t supposed to do.

  10. Anonymous says:

    So, "Microsoft Malware Protection Service" protects malware? :)

    Good series, looking forward to the next one.

  11. Anonymous says:

    Lisa: [reading Homer’s invitation] "Come to Homer’s BBBQ, the extra ‘B’ is for BYOBB."

    Bart: What’s that extra B for?

    Homer: Oh, that’s a typo.

  12. Anonymous says:

    Wasn’t the space in "Program Files" done with the explicit intent of forcing app writers to actually have thier apps work when handed paths/filenames with spaces?  I remember there were a ton of buggy apps early on that didn’t handle them at all.

  13. Anonymous says:

    Long, English file names are no more or less a security risk than short, obfuscated file names.  But there must be a fantastically good reason why they’ve stuck with 8.3 names all this time, because it’s an otherwise real pain for users.

    Or is it because these names can’t be localized, so they’re obfuscated instead?

  14. Anonymous says:

    Long filenames are harder to type in, and putting spaces in the name adds 2 additonal characters to the effective length (the quotes).

    Long filenames are hard to see on the screen because they get truncated. It’s a lot easier to tell what "msmpsvc.exe" is than "Microsoft P…" — of course you can expand the filename listing to show the whole thing, but then you waste a lot of space because most filenames aren’t that long, and you end up not being able to see as much on a screen.

    Long filenames do not fit on an ISO 9660 CD filesystem, so either extensions have to be used or there has to be a way to know what the long name should be from looking at the ISO 9660 name.

  15. Anonymous says:

    "is it because these names can’t be localized, so they’re obfuscated instead?"

    The computer manufacturer that bears a fruit name has solved this. The folder named Pictures will show up in all applications as Bilder on my system set to Swedish locale, but will still be Pictures when you are placed in a shell. Magic.

    "Long filenames are harder to type in, and putting spaces in the name adds 2 additonal characters to the effective length (the quotes)."

    When you want to start an application, which one of these methods do you use:

    1) Click Start, select the application you want to launch, click it.

    2) Press Win+R, type in the full path and name to the application you want to launch, press Enter.

    If you chose method #2, you’re very much a minority.

    "Long filenames do not fit on an ISO 9660 CD filesystem"

    I don’t really buy the ISO 9660 file system theory. We have this new space-age technology available now: it’s called a zip file. It’s used as a container for several other files – it even remembers the full name of them!

  16. Jens: Windows has had that same feature since Windows 2000.

  17. Anonymous says:

    I don’t know why they didn’t change "C:Program Files"

    >to C:bin, but I’ll probably just do that myself.

    Backwards compatibility probably. When you change it yourself, you’re gonna eventually run into trouble with some installer defaulting to program files or failing with an error because program files doesn’t exist.

    Jens Bäckman: Win9x/me did that, it used CAB files, but they still have 8.3 filenames. But I guess thats because sometimes you lose the long file names (for example with scandisk, or in plain DOS outside of windows).

  18. Anonymous says:

    Backwards compatibility probably. When you change

    > it yourself, you’re gonna eventually run into trouble

    > with some installer defaulting to program files or

    > failing with an error because program files doesn’t exist.

    The Program Files folder name is localized, so the actual name was never guaranteed.  But you’ll always run into a few oddball installers that use a hardcoded English path instead of %PROGRAMFILES%.  They don’t fail, they just end up creating their own Program Files folder.

    I haven’t had much luck renaming Program Files after the fact, though, since Windows puts so much stuff in there during a fresh Windows install it’s difficult to get rid of.  I have used Junction.exe to create an ‘Apps’ alias/link to Program Files, but that has created a whole other mess of problems.  

    I have successfully renamed ‘Documents and Settings’ to ‘Users’ without much grief, however.

  19. vince says:

    To all those claiming some sort of "ISO 9660" explanation… Linux distributions have shipped with long filenames on CDs for 10+ years now.  If you use the Joliet or Rock-Ridge extensions the long filenames gracefully fall back to 8.3 names.

    It’s a bit rediculous that in this day and age Windows might be hampered by an old CP/M limit.  I mean come on, my Apple II could do 20 character filenames (with spaces) no problem, and Apple DOS came out before MS DOS did.

  20. Dave says:

    If a mistake was made, it was by the people using a file name alone for identifying a file. The Microsoft file should have embedded vendor/product information saying it’s from Microsoft and will be cryptographically signed by Microsoft. Similarly-named malware won’t be signed by Microsoft, unless Verisign slipped up *again* and issued another bogus certificate.

    Long descriptive names are just as much an opportunity to malware makers as they are to legit software developers. Gee, why would you want to stop a file named "Critical Security Update Service.exe" for example?

  21. Anonymous says:

    Wednesday, April 12, 2006 12:17 PM by Mike Dunn

    > Restricting filenames to 8.3 means the CD

    > can be plain-jane ISO9660, not Joliet, which

    > simplifies building the CD and the installer.

    My intuitive feeling is the same, but I’m pretty sure I saw some 9.3 filenames on the screen during the text-mode portion of a Windows setup.

  22. PatriotB says:

    Long file names for system components are becoming a lot more common.  Vista includes a bunch, not to mention .NET assemblies.

    "I don’t know why they didn’t change "C:Program Files" to C:bin, but I’ll probably just do that myself."

    Maybe because 99% of Windows users wouldn’t have any clue what that means?  At least by naming it "Program Files", they make it pretty obvious to novice users what is contained inside.

  23. Anonymous says:

    "Unquoted values are just exploits waiting to happen"

    They are if your code has an exposed surface.  It gets really unhappy when you need to mix tools that started life 20 years ago on Unix together with tools that started life 15 years ago on Windows.  And if it’s for a 100% in-house tool, you just don’t care about exploits.

  24. Anonymous says:

    As someone that spends a lot of time in the command prompt, I don’t much mind long descriptive names since the shell offers auto-completion (though they make many commands wrap to 2-3 lines), but spaces are a pain.

    Hard links offer an escape hatch, but a tool that I use that displays hard disk usage as a treemap isn’t aware of them so I get skewed results.

    All in all, it would help if Vista removed spaces from standard directories and used Users and Programs instead. And I wouldn’t object if various programs installed themselves in, say, ProgramsMicrosoftOffice13 instead of "Program FilesMicrosoft OfficeOffice13".

    Dejan

  25. Anonymous says:

    "I don’t know why they didn’t change "C:Program Files" to C:bin, but I’ll probably just do that myself."

    That wouldn’t really be appropriate, since there’s program data, libraries and more often than not configuration settings in Program Files. The traditional use of bin folders is just for binaries.

    I’ll chime in against 8.3 naming – I frequently find myself stumped at what processes I’ve got running. Norton AV has one or two that aren’t obvious at all, and often drivers have some daft application lurking about with an arcane name ("khalmnpr.exe" = some useless thing for Logitech mice).

    I don’t buy the iso9660 argument, since the files on them are compressed anyway (Windows now being a bit bigger than 650MB) – so why not roll them up into .cab’s or whatever is the flavour of the minute?

  26. Anonymous says:

    Why not "bin"?  Because a bin is something you put garbage in.  

  27. Anonymous says:

    > "I don’t know why they didn’t change "C:Program Files" to C:bin, but I’ll probably just do that myself."

    That wouldn’t really be appropriate, since there’s program data, libraries and more often than not configuration settings in Program Files. The traditional use of bin folders is just for binaries.

    You’re right. That said, c:programs could have been a better choice.  Or at the very least, they could have kept "c:program files" on every language. And they could have found something less aberrant than "c:program files (x86)" :(

  28. Anonymous says:

    BTW, about the cab files… dosx/miniwindows (q stripped down windows 3.11) was used to install 9x, so it couldn’t ever use LFN, also you could start setup from MSDOS 6 iirc. So even though all of this would be no problem with winnt/2k/xp, many files have to stay 8.3 for BC all the way to 3.11 basically.

  29. Anonymous says:

    "You’re right. That said, c:programs could have been a better choice.  Or at the very least, they could have kept "c:program files" on every language. And they could have found something less aberrant than "c:program files (x86)" :("

    I assume %PROGRAMFILES% is constant – one of course shouldn’t worry about the actual path. If nothing else, you stand at least some chance of it being d:program files.

    Is the (x86) from the amd64 version of XP? It’s moderately awful, yes, but they probably needed something. I’ve got /lib32 and /lib64 on here, so MS aren’t the only ones doing this sort of thing, even if it is a bit less elegant.

  30. Anonymous says:

    > I assume %PROGRAMFILES% is constant – one of course shouldn’t worry about the actual path. If nothing else, you stand at least some chance of it being d:program files.

    Both this and "c:program files (x86)" are not a problem for programs, but an inconvenience for advanced users.

    Using Win+R, or the command line, or typing the filename instead of browsing etc with such a complex path (and c:documents and settings is brain damaged too, but at last corrected) is uselessly complex. c:programs and c:programs32 (or c:programs32, c:programs64, or whatever you like best) is much much faster to type.

  31. Anonymous says:

    what’s wrong with using "c:progra~1"?

    I am sure there’s something but it has done me for years…

  32. Anonymous says:

    what’s wrong with using "c:progra~1"?

    Doesn’t exist on all file systems. 8.3 alternate name generation is a crutch for ancient or defective programs, and can be disabled if you’re confident you don’t (want to) run old crap.

  33. Anonymous says:

    Doesn’t exist on all file systems. 8.3 alternate name generation is a crutch for ancient or defective programs, and can be disabled if you’re confident you don’t (want to) run old crap.

    Surely ancient programs wouldn’t know about it and so couldn’t use it?

    As for defective, you could say that any program that hard-codes this path (whether 8.3 or other) is defective.

    As for running old crap, my use is for those of us (the minority apparantly) who do type into the ‘Run Bar’ or ‘knock up’ batch files for use on PCs we know support it.

  34. Anonymous says:

    It was already taken, but that’s okay.

  35. Anonymous says:

    Thursday, April 13, 2006 1:07 AM by Dejan Jelovic

    > And I wouldn’t object if various programs

    > installed themselves in, say,

    > ProgramsMicrosoftOffice13 instead of

    > "Program FilesMicrosoft OfficeOffice13".

    You mean Progra~1Micros~1Office13?  Have you looked in your registry to see how many shorticated paths programs are still recording for themselves?

    Thursday, April 13, 2006 5:48 AM by 0xF00D

    > Or at the very least, they could have

    > kept "c:program files" on every language.

    You mean they could have kept "D:実行可能ファイル" the same in every language.  (Not a perfect example because in Japanese Windows they do still name this folder in English instead of Japanese.  But still, think about it, that would deliver what you asked for.)

  36. Anonymous says:

    The last time I tried to make my program’s file association registration use long path names, it broke opening files from Explorer through DDE, so I gave up, and even ended up renaming my EXEs so they were 8.3 or less.

  37. Anonymous says:

    "And I wouldn’t object if various programs installed themselves in, say, ProgramsMicrosoftOffice13 instead of "Program FilesMicrosoft OfficeOffice13"."

    I would. Whats wrong with "Program FilesOffice13" or at a pinch "Program FilesMicrosoft Office13"? Why should I ever care about what company wrote the program? Half the time I can barely remember what the program was called, let alone who made it, and it’s really annoying having to look through several folders of random companies.

  38. Anonymous says:

    ICR wrote: "Why should I ever care about what company wrote the program?"

    In most cases one company writes few product which can interact, have something common etc. For such purpose I feel practical to have anything from Adobe installed in "Adobe" folder etc.

    Also, including manufacturer name minimizes name conflict. Especially in "obvious" names you can’t be sure that there is not another program with similar name. So I’d rather have C:Program FilesMicrosoftOffice and C:Program FilesCorelOffice than "Office1" and "Office2".

    Yes, there are other solutions, but this one – if well used – is simple and works.

  39. Anonymous says:

    "8.1 is enough for everyone"

    ISO 9660 can handle 32 chars, which is enough for Microsoft Protection Service.exe

Comments are closed.