Why doesn’t searching my Start menu with Cortana find Internet shortcuts in my All Programs list?

A customer had a program that installed a number of shortcuts to the Start menu. Among them were some Internet shortcut files, like "View Contoso User Guide" and "Get Online Support from Contoso". In Windows 7 and 8, if the user searched the Start menu for "Contoso", these shortcuts would appear in the search results. But in Windows 10, they do not. Why not, and what can they do to get them to show up?

The Cortana team explained that they intentionally filter out URLs from search results. They ran an A/B test, and the results showed that leaving URLs in the search results was worse for users.

To get the shortcuts to appear in the Cortana search results, you can create a shortcut to a regular program. For example, you can create a shortcut that points directly to the Web browser executable, with the URL on the command line. Or you can create a shortcut that runs a helper program bundled with your application, and the helper program calls Shell­Execute to open the URL in the user's preferred Web browser.

Comments (53)
  1. skSdnW says:

    But not allowing users to disable internet results in the start menu is not bad for the user? Cortana even ignores the group policy for it on purpose.

    1. laonianren says:

      I’m running the latest consumer Windows 10 (not any preview build) and I don’t see internet results in the start menu. I didn’t do anything unusual. I just turned off all the relevant looking settings.

  2. morlamweb says:

    How exactly was it “worse” for the users to leave the URLs out of the search results?

    1. The MAZZTer says:

      I’m guessing because there really is no need for urls in the Start Menu to begin with; it’s just filler some app is putting there because they want to. Most users probably don’t care or want to see them.

      IIRC the Microsoft UX guidelines state the only thing an app should be putting in the Start Menu are shortcuts to actual apps. No documentation (the app itself should open any documentation), no uninstallers (the uninstaller should be made accessible in the Programs and Features dialog). URLs may make sense depending on their usage I suppose (for example, accessing an online service that the app utilizes). But most URLs I’ve seen are shortcuts to the developer’s website which is just clutter that could go in the app itself.

      1. Karellen says:

        Sounds like a pointless game of whack-a-mole.

        The guidelines already say not to do that, so the devs (or “brand marketers”, or whatever “B”-ark asshats are in charge of such decisions) have already decided they don’t care about making life pleasant for the user, but just want to get in their face as much as possible.

        If URLs stop showing up as much as possible, Contoso will just make them calls to the web browser in the next version (or, more likely, the next patch) and the user is in as worse a state as they were in before Cortana stopped showing URLs. So the next version of Cortana will have to make links to the web browser not show up in search results, at which point Contoso will just implement the “helper program” workaround instead.

        At which the user is back where they started *again*, no better off than before, but now there are these weird special cases where URLs and links to the web browser don’t show up in search results, for reasons that the user will never understand.

    2. The Cortana team didn’t tell me, but my guess is that when they included URLs in the search results, the URLs received negligible click-through, which strongly indicated that people weren’t searching for URLs and they were just cluttering the results.

      1. Alex Cohn says:

        Or they found that people started search for something like “com” and were overwhelmed with all the URLs that showed up

      2. morlamweb says:

        Thank you. That was unclear to me after reading the post. Thanks for clearing it up.

  3. ChDF T says:

    “Or you can create a shortcut that runs a helper program[…]”
    Doesn’t that kind of defeat the purpose of filtering out URLs? Sure that is a neat workaround for users and sys-admins, but I don’t understand how forcing your shortcut into the search results is different from force-pinning your application to the Start menu – it is just something an application should not do.

  4. Stefan Kanthak says:

    0. on standard installations of Windows only one web browser is present: “%ProgramFiles%\Internet Explorer\iexplore.exe”
    1. since you don’t know the user’s preferred web browser (just in case that more than one of them are installed) you should not call YOUR preferred web browser.
    2. nobody needs to write a helper application, Windows fortunately provides one for you already: just call “%SystemRoot%\System32\rundll32.exe” “%SystemRoot%\System32\url.dll,,FileProtocolHandler

    1. Yay, let’s take a dependency on an undocumented interface!

      1. Stefan Kanthak says:

        I’d rather ask why M$FT still does not comply to court orders and their own commitment to document ALL the interfaces they use in Windows, for example the ones shown by “CMD.exe /K FType”

        1. I think you’re misinterpreting what the order says. But this is not a legal blog.

          1. Stefan Kanthak says:

            Please read the part AFTER the “and” too, then tell me (for example) where URL.dll’s TelnetProtocolHandler or SHDOCVW.dll’s OpenURL are documented.

      2. Pavel Kostromitinov says:

        Indeed, “cmd.exe /c start http://contoso.com/” would do it just as well

      3. Stefan Kanthak says:

        Unless this helper application is installed in a secure location, or its developer used an UNDOCUMENTED interface, calling ShellExecute() is unsafe: see DLL hijacking, see MSRC case 32250
        RunDll32.exe .dll does not show this vulnerability.

        1. Harry Johnston says:

          Why in heaven’s name would you install the helper application in an insecure location?

          1. Stefan Kanthak says:

            I won’t; I also won’t write one in the first place.
            There exist but quite some applications out there which 1. call ShellExecute(), 2. are not coded in a safe and secure way, 3. are not installed in safe locations, or 4. are run from unsafe locations.

          2. Harry Johnston says:

            So? There are applications out there that do all sorts of stupid things. (Like taking an unnecessary dependency on an undocumented interface, for example.)

          3. Harry Johnston says:

            OK, that was unnecessarily snarky of me. Apologies. Still, in Raymond’s original scenario, the helper program was bundled with an application, and would naturally be located in the same directory tree as the main application, which had better blimmin’ well be secure. So I really don’t think this is an issue.

          4. Stefan Kanthak says:

            The problem lies with “which had better blimmin’ well be secure”
            Just 2 (of MANY) counter examples:
            1. fetch Windows10Upgrade.exe and run it: it creates a directory %SystemDrive%\Windows10Upgrade\ where it unpacks the real application to, then creates a shortcut to this real application in the start menu. All but the latest version of Windows10Upgrade.exe allow unprivileged users to write into %SystemDrive%\Windows10Upgrade\
            2. Mozilla’s uninstallhelper is installed into a secure location, but extracts some DLLs to a subdirectory of %TEMP% and executes them.

          5. Harry Johnston says:

            Well … OK, the Windows10Upgrade thing might well introduce a genuine EoP vulnerability, but it doesn’t have much to do with helper applications and the Start Menu. Putting DLLs in %TEMP% isn’t a major problem, though, as far as I can see. Loading a DLL doesn’t add the directory to the search path for dependencies, and any way of getting a malicious file into %TEMP% would constitute a vulnerability in itself.

            (Nonetheless, it is probably sensible to avoid using the root of %TEMP% directly as a defense-in-depth measure.)

    2. GL says:

      You could have used cmd to start a URL. Why use rundll32 corruptedly?

    3. Chris says:

      He said “ShellExecute”, which allows you to pass just a filename/URL and have the shell open it using the user’s default program, without needing to specify what that program is.

      If you don’t want to include a helper program, you can have the shortcut pass the URL/filename as a command-line argument to explorer.exe, which appears to do the same thing as ShellExecute on that URL/filename. (Though I don’t know for certain if that’s a Microsoft documented interface)

      1. No, please don’t pass files to explorer.exe. Explorer is for opening folders, not files.

        1. Chris says:

          Gotcha. Good to know, thanks!

      2. Stefan Kanthak says:

        No, Raymond wrote “helper program [which] calls ShellExecute”.
        This helper program already exists.
        If you don’t like RunDLL32.exe URL.dll,FileProtocolHandler: see ASSOC .URL and FTYPE InternetShortcut

        1. ErikF says:

          @Stefan: Why use undocumented interfaces when start.exe does exactly what you’re wanting? (It’s even less typing!)

          Regarding rundll32.exe, Raymond has talked about it several times: https://blogs.msdn.microsoft.com/oldnewthing/20130104-00/?p=5643/ and https://blogs.msdn.microsoft.com/oldnewthing/20040115-00/?p=41043 (amongst others). That what you’re doing happens to work is pure luck; it probably will continue to do so because everyone seems to rely on it, but that doesn’t negate that fact that you’re relying on non-contractual behaviour that Microsoft is within its rights to change (say, by tightening up on what rundll32 accepts, or by getting rid of rundll32 altogether.)

          1. skSdnW says:

            I believe this is one of the functions actually designed for use by rundll32. It is also recommended as a ShellExecute workaround @ https://web.archive.org/web/20080204185822/http://msdn.microsoft.com/msdnmag/issues/05/03/CATWork/default.aspx but it can still change/go away at any point.

          2. Stefan Kanthak says:

            I recommend to do your homework first!
            1. there is NO start.exe!
            2. the functions FileProtocolHandler, FileProtocolHandlerA, MailToProtocolHandler, MailToProtocolHandlerA, NewsProtocolHandler, NewsProtocolHandlerA, TelnetProtocolHandler, TelnetProtocolHandlerA, OpenURL and OpenURLA exported by URL.dll as well as OpenURL exported by SHDOCVW.dll are designed for calls by RunDll32.exe

          3. ErikF says:

            @Stefan: Mea culpa. Indeed start is not an executable, but you can still call it thusly: “cmd.exe /c start “.

          4. Stefan Kanthak says:

            This gives your users a nice flashing console window.
            JFTR: the difference between CMD.exe and RunDLL32.exe is: the latter is a Windows GUI program.

          5. ErikF says:

            I’m trying to figure out what use case you’re needing this for: programs can call ShellExecute() directly, shortcuts are handled by the shell, and scripts can use start/Invoke-Item/etc. Perhaps that will help to determine what supported methods would work best.

  5. xpclient says:

    Nice idea for Classic Shell’s search!

  6. xpclient says:

    What if the user is searching for URLs from his Bookmarks/Favorites?

    1. As noted, the A/B test shows that people didn’t do that.

  7. Harry Johnston says:

    The shortcut to the the web browser executable with the URL in the arguments won’t work, or won’t work for more than one URL, because the Windows 10 Start Menu only ever displays one shortcut to a particular executable, even if the arguments are different.

  8. kermi says:

    I wish the search would show my executable files which are in indexed locations, but do not have start menu item. Say like my sysinternals tool folder, or putty and other portable programs.

  9. Karlis says:

    The problem with A/B testing is that only the most popular features might be kept.
    Which has resulted in Start menu search becoming unusable in Windows 10.
    In Windows 7, I could find everything in the indexer’s database using Start menu search. In Windows 10, I cannot see any logic as to what I will and what I will not find. For example, on my desktop, I have a pdf file that includes the words “german economy contracts”. In Windows 7, I would type “german contracts” in the start menu and it would be the first result. In Windows 10, I have to open explorer, open my user folder (for how do I otherwise force Windows to search all of the indexer database?), and then search.
    3 steps where in Windows 7 there was one.

  10. cheong00 says:

    The next question would be: “Is there any verb that I can use to tell Cortana to get them show up?” ( https://blogs.msdn.microsoft.com/oldnewthing/20080321-00/?p=23043 )


  11. SimonRev says:

    I’d settle for Cortanna to actually work. For some reason I have to kill Cortanna in the task manager before I can get any searches in the start menu or Win+Q to work.

  12. DaveL says:

    I’m glad this decision has apparently been changed in the newer updates to Windows 10.
    My shell extensions installers included links to their documentation in the start menu. As there’s no “app” to run from the start menu, being able to search the start menu to discover my extension’s documentation was (and now is again) quite useful.

  13. Yukkuri says:

    Does “cortana” here include “search windows” that you get when AllowCortana is 0?

  14. outadoc says:

    So THAT’s why Windows 10 is usually at starting programs for me, I almost forgot all about the useless web links that get put in the start menu by installers. I’m glad it works this way, and I hope the workaround won’t be abused in the future. I don’t care about your website, program. Never clicked on it, never will.

  15. Stefan Kanthak says:

    1. what’s the difference between a helper application with its shortcut in the start menu, and the main application with its shortcut in the start menu? NONE, they both enable the same attack vector!
    2. a subdirectory, even with random name doesn’t help at all: the name can be determined by a trivial batch script.
    See for example my PoCs for several installers based on NSIS, the Intel Installation Framework, DISM.exe, RAR and 7-zip.

    1. Harry Johnston says:

      1. I have no idea what you’re talking about here, and don’t see how it can possibly be relevant.

      2. OK, with the help of a Google search I’ve figured out that this one is a UAC bypass vulnerability. I for one don’t care, since I always use a separate admin account, which has its own %TEMP% directory. If you do care, you just need to create a sub-directory with explicit permissions, but given that in the default configuration UAC is trivial to bypass anyway, seems like a big yawner to me.

      1. Stefan Kanthak says:

        1. You wrote “the helper program was bundled with an application, and would naturally be located in the same directory tree as the main application, which had better blimmin’ well be secure. So I really don’t think this is an issue.”
        I showed you a counter example. Is this still not an issue?

        2. the UAC bypass is not the point here, but the INSECURE helper application.

        RUNDLL32.exe URL.dll,OpenURL doesn’t show these vulnerabilities!

        1. Harry Johnston says:

          1. But you haven’t shown me a counter-example. All you’ve done is to assert that one exists, and that it has something to do with Start Menu shortcuts, but you didn’t say what. It also confuses me that you say the main application’s shortcut is vulnerable too; if that’s true, then what difference does the presence or absence of the helper application’s shortcut make? One vulnerable shortcut or two, the risk is no different.

          2. But in the scenario we were discussing (an installer or uninstalling unpacking itself to a subdirectory of %TEMP%) the helper application isn’t insecure, except insofar as there is a possible UAC bypass. So I don’t think you can say that the UAC bypass isn’t the point. Those examples have nothing in common with the scenario Raymond suggests anyway! In particular, the helper program in Raymond’s scenario wouldn’t be put in %TEMP% and wouldn’t run elevated, so no UAC bypass is possible, or at least I can’t imagine how one would arise.

          To summarize, as best I can tell at this point, you seem to be asserting that the observation that some sorts of helper applications sometimes have minor security flaws means that you should never use helper applications, even of unrelated sorts and even if the alternative is using an undocumented dependency. If that is indeed what you’re saying, I don’t think it is reasonable, but I suspect that I’ve misunderstood you somewhere.

          (Not that I particularly care; as mentioned above, I don’t think Raymond’s solution will work well anyway. I’m just baffled as to why you think this is such a big deal, and curious as to the technical details of the vulnerabilities you alluded to.)

          1. Stefan Kanthak says:

            Is “MSRC case 32550” so hard to find?
            See http://seclists.org/fulldisclosure/2016/Mar/64

            The proposed helper application calls ShellExecute() and thus loads some DLLs from its application directory, as shown by the minimum implementation of the POC; real world implementations (like Microsoft’s “Windows 10 Upgrade Assistent” or Mozilla’s uninstallhelper.exe) use the MSVCRT, call more Win32 functions or even their own crap they write to %TEMP% and show therefore MORE vulnerabilities.
            Are you sure that your self-implemented helper application behaves better and doesn’t show these vulnerabilities?

            Now compare this to RUNDLL32.exe:
            – the application directory of RUNDLL32.exe is %SystemRoot%\System32\, so RUNDLL32.exe doesn’t show the vulnerability of the POC;
            – RUNDLL32.exe doesn’t extract some crap to %TEMP% and runs it there, so it doesn’t show the vulnerability of NSIS and other REAL WORLD implementations of helper applications.
            Is this SOOOO hard to understand?

          2. Harry Johnston says:

            Did you seriously expect me to find the one particular vulnerability report you were thinking of, out of hundreds of thousands, having given me no relevant information? As for “MSRC case 32550”, Google returns no results, and the number doesn’t appear in your link, so I still don’t know what you’re talking about. (I considered the possibility that it was a typo for 32250, but that one isn’t relevant.)

            Nor is there any mention in your link of “start menu”, “shortcut”, or any reference to the temporary directory or to a helper application, so none of it has any relevance to either the thread of conversation so far or to the original post. I’m giving up; I no longer believe you’re arguing in good faith.

          3. Harry Johnston says:

            Oh, I see you did mean 32250; you referenced it upthread, as evidence that calling ShellExecute is unsafe if your application has been run from an untrusted directory. Everybody already knows that. It isn’t relevant to this scenario.

Comments are closed.

Skip to main content