Why do my PDF file associations get reset every time I restart?

A customer reported that each time they restart their Windows 10 PC, the file association for PDF documents keeps getting reset to the default, which is Microsoft Edge. They use the "Set Default Programs" control panel to change the default handler to Program X, but the changes don't stick past a reboot.

The feature team for file associations explained that Windows 10 changed the way the user's file associations are recorded. Program X wants to set itself as the user's preferred handler, but they want to do so without requiring the user to confirm the change. How considerate of them. So they manipulate the registry keys directly. (I bet somebody got a really nice bonus for that feature.) But they are manipulating them the pre-Windows 10 way. This means that Windows 10 detects the settings as corrupted and throws them away, causing the handler to fall back to the system default.

The customer has a few choices here.

The obvious choice is to stop using Program X. Easier said than done. Program X is probably essential to the customer's workflow. That's why they want to set it as the default!

Another option is to work with the vendors who produce Program X and get them to stop mucking around in internal registry keys. (Good luck with that.)

Yet another option is to set the system default handler to Program X, so that when Program X accidentally-on-purpose corrupts the user preferences, Windows 10 falls back to the system default, which now happens to be Program X.

It does mean that the user won't be able to change their default handler to anything other than Program X. But given that Program X is corrupting the user preferences, this is the best you can hope for, assuming you are required to keep using Program X.

Comments (64)
  1. Karellen says:

    Of course, TRWTF is that Program X is continually trying to set itself as the default handler, without asking the user if that’s what they wanted.

    We know this is the case because, if Program X did ask the user for confirmation, the user could just say “no” and keep the preference they’d made in the “Set Default Programs” control panel – which was Program X!

  2. skSdnW says:

    So Program X is overwriting the HKCU FileExts preference values even if it is already the default? I guess the lesson is, only be evil when you need to be, being evil all the time gets you in trouble.

    (I’m kidding of course, the user should always be in control of their machine and its preferences)

    1. Program X thinks that the registry setting is corrupted (because it’s expecting the pre-Windows 10 format), so it helpfully “fixes” it. “No need to thank me. Just doing my job.”

      1. skSdnW says:

        IApplicationAssociationRegistration::QueryCurrentDefault has been around since Vista so there is no excuse for using hacks for the detection part of this evil operation.

        1. IanBoyd says:

          That API, IApplicationAssociationRegistration::QueryCurrentDefault says it’s not intended for Windows 8. What would be the correct API to register file associations? MSDN documents the registry keys that must be manipulated directly in order to register an application with a file type.

          1. skSdnW says:

            You need to read a little between the lines here. The interfaces “root” page says “Note As of Windows 8, the only functionality of this interface that is supported is QueryCurrentDefault.” and some intern probably got carried away with the copy and paste. On Windows 10 you can use the Assoc* API and ASSOCSTR_PROGID if that makes you feel better.

      2. Joshua says:

        Unfortunately the current recommendation is broken. The UI cannot add a new file association that requires a command line argument. Also, that UI is pretty clunky; a program whose sole purpose is to edit file associations should be able to exist.

    2. morlamweb says:

      I suspect that Program X is writing to the registry on it’s startup. Many programs have a “check to see if I’m the default” setting within their options. This program likely is checking the file association due to that option being set, finding the program association to be “corrupted”, and “fixing” it. If my guess is correct, then clearing the “check to see if I’m the default” option should also help.

      1. Karellen says:

        If that were the case, I expect Raymond would have suggested that as one of the customer choices.

        That he doesn’t implies to me that Program X is one of those user-hostile programs that just assumes it’s the best thing ever, and always unconditionally tries to set itself as the default handler for every filetype it knows how to handle – and probably a few that it doesn’t.

        1. morlamweb says:

          We won’t know if that was the case for Program X, because we don’t know it’s identity. The general point is worth remembering for these types of cases.

    3. Medinoc says:

      Which reminds me, I’ve always wondered how the FileExts system interacts with the other association systems (such as HK??\Software\Classes, and I’m not sure there isn’t a third one somewhere), and which one was actually recommended nowadays.

      1. skSdnW says:

        The classes key has been the documented location since forever (The Applications key and the Default Programs registration also play a role). FileExts has never been documented AFAIK and is used to store “discovered” open-with entries and their order and other file type user preferences, applications should not write there. The shell will write there for the user.

    4. DWalker07 says:

      Yes, the user should be in control of their machine and its preferences. However, if the user puts something into the registry in the wrong format, shouldn’t Windows revert it? (Which is basically what Raymond is saying here.)

  3. Cmdr says:

    So, how do you set the system-default handler if you were a user encountering this issue?

    1. Entegy says:

      You would need to set it with an account that has admin access on the machine.

  4. AMX says:

    How about changing the permissions on the registry key, so Program X can’t corrupt it any more?

    1. morlamweb says:

      I can see two problems with blocking it via registry ACLs: 1, the user wouldn’t be able to set their own preferences via the Control Panel for that file type; 2, who knows how Program X will react if it can’t mess with the file associations? Best case, it’ll handle it gracefully and ignore the error, or display a message box; worst case, it’ll go unresponsive and crash or require killing the process. Given the hacky nature of their file association routines, I’m not betting on it handling things gracefully.

      1. AMX says:

        Re 1, it would be rather circuitous (un-protect key, possibly requiring an admin; change default; re-protect key, again possibly requiring an admin) but changing your defaults is not exactly a daily task…

        Re 2, you have a good point there.

        1. morlamweb says:

          Changing the defaults is a daily task with Program X on Windows 10. That’s kind of the point of the article. And why make a task more difficult even if it’s not an everyday task?

          You’re also presuming that the user has permissions to change the ACLs on the relevant reg keys. If the user is not admin – which they shouldn’t be – then they can’t unblock the reg keys.

          1. AMX says:

            But it’s only a daily task because the program keeps corrupting the registry key – if you prevent it from doing that, it becomes a one-time task.

            No, I’m not – that’s why I have “possibly requiring an admin” in there…

          2. morlamweb says:

            @AMX: and if “possibly requiring an admin” involves calling IT to perform the task, then you’ve just made the task many times more difficult for yourself. That’s not terribly helpful.
            Also, consider the case that Program X is not actually essential to the users’ workflow. That was a core assumption on Raymond’s part, but in many cases, X can be replaced with Program Y, Z, A, whatever, or the user just wants to try a new PDF program. Then they set the default to be Program Y, except that they can’t; they have to call up IT to make the change for them. Repeat for Program Z, A, B, etc.
            It’s best not to mess with ACLs on system registry keys. Doing so usually invites a support nightmare and unintended consequences for yourself.

    2. Damien says:

      *Programs* don’t have permissions, *users* do. I’m sure Raymond has explained this himself in the past.

      1. AMX says:

        I don’t see how that’s relevant?
        Once the file association has been configured, the user does not need write permission for the reg key any more, so you can set it to read-only to protect it from any programs running in that user’s context.

        1. GL says:

          Users might want to change the default, say, if the current default program is uninstalled, which might include the case where the current default program is updated and the new version has a different ProgId for the handler. Another case is when the user installs another software that he wants to be the new default.

          1. AMX says:

            Uninstalling the program would make the workaround unnecessary.

            Adding another program is a scenario I had not considered, yes.

  5. DWalker07 says:

    How is “setting the system default handler to program X” different than using “set default programs” to set the handler to Program X?

    I might be able to figure this out, but I didn’t know that we could change the DEFAULT handler for a program. At least, not without mucking around in the registry.

    1. Karellen says:

      “set default programs” sets the per-user default handler, rather than the system default handler.

      1. DWalker07 says:

        Ah, thanks.

  6. Entegy says:

    Just FYI, I believe version 11 or above of Program X use the correct methods to set PDF associations.

    Is that vague enough? We all know who the culprit is here right…?

  7. jon says:

    A related question would be, why does Microsoft invent a whole new file association system every time there’s a new version of Windows?

    1. Mantas says:

      Precisely because of such programs, I would assume.

    2. Entegy says:

      It doesn’t. The current system has been in place since Vista. 10 finally enforced it.

    1. Darran Rowe says:

      What he means is that for any extension, there are now at least two keys to control what program opens a file extension. The one for the extension itself (.myext) and the one that contains the information to open the file with a program.
      This application that is being kind is probably updating the .pdf registry key directly, not having a separate pdffile or whatever key that has all of the commands to open the file that the .pdf key would then link to.

      1. IanBoyd says:

        What is the documented way to register my application to open a particular file extension? The documentation is to use the registry.

        1. You use HKCR to declare that your application can handle a file type. But you let the system manage the default.

          1. DWalker07 says:

            The linked article does not make the distinction (between being able to handle a file type, and being the default handler) very clear.

            It says “To associate the file type with an existing application, …” you muck around in the registry. “Associating” sounds like “setting the program that will handle the file type”.

    2. GL says:

      Registering a file association is NOT setting it as default also. If the extension has not a handler yet, the newly registered handler will become the default. If the extension already has a handler, Explorer will ask the user if they want to use the new handler the next time the user opens the file. That’s basically how it works.

      1. Jason says:

        I hope the “Do you want to keep using Program X” prompt gets eliminated. That seems to annoy my users more than anything.

  8. littlealex says:

    Isn’t this something that can be fixed by using a Shim?
    “Hey, Windows, when this software here tries to access the registry key for old stlye file extensions, please redirect it to this newly created harmles key, where it can do no damage, kthnxby”.
    Something like:
    VirtualRegistry: AddRedirect(originalkey^fakekey)

    It should be possible, if I recall correct, for the user to create this shim for himself and use it on his own computer, no?
    Con: Shims aren’t very easy
    Pro: The user can now set any program he wants as PDF handler, without Program X messing up his setting.

  9. Leo Davidson says:

    It sure is great that the file association system in Windows is now so complicated, involving about 10 differetn places in the registry and obfuscated data (and don’t even get me started on Metro apps which you can’t even get the NAME of from the Win32 side).

    Debugging problems with it, or trying to replicate the system but with slight differences (say if you want to let people override what happens for some file types, but only inside your application, or if a key is held down, for example), is a nightmare.

    All to perpetuate an endless arms race between “bad” apps (which are often just doing what the user actually wants them to do) and the OS, which the OS cannot win as there is always a way around it, resulting in yet another layer added on top in a future version of Windows.

    Ditto pinning things to the taskbar (which Microsoft do with their own apps, against the rules, and which another popular browser has worked out how to do).

    Ditto pinning things to the Start Menu, which now seems to be restricted to Explorer.exe and does not work from any other process (even the FIle Open dialog in Notepad, so it’s still the same shell code), despite putting the option in the context menus in all processes. The menu item is there in other processes but does nothing, so we start fielding bug reports. But any app that really wanted to break the rules could fairly trivially run the context menu command inside Explorer.exe via various routes.

    Writing for the Windows shell is really annoying these days.

  10. GL says:

    I love the hash mechanism, but it can be worked around by simply removing it. See https://ardamis.com/2015/12/01/configuring-a-default-application-for-protected-file-types-in-windows-10/ . This new mechanism makes it hard to deploy policies :-(

    BTW, my guess is that X is playing with the UserChoice and cannot fill in the correct hash, which corrupts the association choice.

  11. Matt Seitz says:

    You don’t ask the producers of Program X to stop using registry keys. You tell the producers of Program X that you can’t set their program as the default.

    Since being the user’s default is apparently very important to the producers of Program X, I expect they will be highly motivated to fix this problem.

    1. GL says:

      ROTFL this is a perfect example how to do something by not doing it.

  12. Before Windows 10, I could set the file associations for other users and they were all set when they first logged in. Now, I have to teach them how to do it, per system × person.

    1. GL says:

      You still can, see the link I mentioned in an earlier reply. Bra you can use GPO, which is documented.

    2. Entegy says:

      You can do this: https://technet.microsoft.com/en-ca/library/hh825038.aspx

      Users who already have a profile on the machine aren’t affected, but new users logging in will get your customized defaults, and then can change it based on their preferences later. Or if you don’t want your users to pick their own file associations, GPO.

      1. Er… Your link seems broken.

  13. Timm says:

    Now if only Windows 10 would respect the defaults when they are set properly, and not decide to make sure I don’t want to use Edge or something else I intentionally changed from default (“Keep using…”)

  14. Erkin Alp Güney says:

    I know who did that but rules prevent me to post it

  15. xpclient says:

    I think Windows 8 (and Window 10) is to be blamed for this. Windows 8 removed the ability to programmatically change defaults. While this was done in the interests of protecting user choice, it greatly inconvenienced everyone including users. The correct way would have been to allow programmatic default changing but show a notification to the user that the defaults have changed. When the user clicks the notification, the change in defaults gets undone/reverted.

    By crippling installers and programs ability to change defaults and exclusively allowing the Default Programs page to change them, Microsoft created this mess.

    1. And then you get this, where two people keep fighting over the association. Program X changes the association, then Windows displays a dialog box and resets it, then program X changes the association again, then Windows displays a dialog box and resets it etc. The user is now stuck in an infinite loop of dialog boxes.

      1. xpclient says:

        Sure, the OS can’t protect against all badly coded apps but at least such a design would inform the user immediately (as soon as the app or its installer steals associations) that program X is that badly behaving app repeatedly stealing associations. At that point, it’s the user’s decision whether to continue using the badly behaving app or uninstall it.

        The current behavior in Windows 8/10 breaks all installers and apps trying to associate on demand (when the user intentionally wants to make that app default using the *app provided UI*). Many times, the developer chooses to not register his program in Default Programs and there is no easy way for the average user to add it there without Registry fiddling.

    2. Entegy says:

      If you really are xpclient, then I know you don’t use Windows 10 or you already would know the answer to this.

      If multiple programs register for a file type correctly, then Windows 10 does pop up a message asking if you want to use the new app or keep your current settings when you try to open a file of that type. Firefox triggered this for a little while after every update before it was fixed.

      1. xpclient says:

        Yes I don’t use Windows 10 because my slow internet cannot handle 350 MB updates of zero value to me almost every week. Even with Unified Update Platform, they couldn’t keep the update size below 50 MB per month. This rules out Windows 10 for the next 20-25 years until the area where I live has faster internet connection available.

        But I’ve observed how it behaves in case of file associations. It shows that dialog when the user opens the file. It should notify the user as soon as the offending app steals the association that “Program X has made itself the default. Click here to undo this change.” The system’s job is to inform, not play middleman. Or it may not be even that hard to add an additional option “Don’t notify about file associations for this app again.” They could make this setting encoded in the Registry so apps can’t fool around with it.

        1. Chris says:

          So, you basically want Windows to slow itself down by constantly polling two entire registry trees for each user logged in, just in case some program somewhere starts digging around where it shouldn’t? Because, without doing that, the system has know way of knowing when one of those keys has changed until it actually tries to use them.

          1. xpclient says:

            Have you heard of Event logs?

  16. Jason says:

    Can you please make file associations not go through this for user accounts created before Sysprep? File associations reset for these accounts after Sysprep even if they were set before Sysprep in the Windows 10-aporoved way.

    We need pre-created user profiles for all our kiosks and public-facing computers.

    1. Richard says:

      Except the behavior of SysPrep requires that ALL (except for the Administrator’s) user profiles be removed prior to SysPrep. Somewhere back (I forgot when), Microsoft said that if multiple profiles exist when SysPrep is ran, then SysPrep may “pick” the wrong one. Although maybe this requriement is for using “CopyProfile”.

  17. Igor Levicki says:

    I think that Windows went too far in “protecting” users from hostile programs messing with file associations.

    My biggest grief is that ever since Vista setting custom and complex associations with multiple action verbs for programs and command line tools has progressed from mildly annoying over royal pain in the butt to almost impossible.

    And dont even get me started about Windows Media Player which if removed breaks programs which embed it but if left installed associates everything to itself and clutters context menu.

    Why not just let advanced users edit associations directly is beyond me, but I guess the company which took it upon themselves to decide how long we may use our PC without reboot doesn’t know better than to annoy people with artificial restrictions.

Comments are closed.

Skip to main content